git-commit - Online sa Cloud

PROGRAMA:

NAME

git-commit - Magtala ng mga pagbabago sa repositoryo

SINOPSIS

pumunta gumawa [-a | --interactive | --patch] [-s] [-v] [-u ] [--amend]
[--dry-run] [(-c | -C | --fixup | --squash) ]
[-F | -m ] [--reset-author] [--allow-empty]
[--allow-empty-message] [--no-verify] [-e] [--author= ]
[--date= ] [--paglilinis= ] [--[walang estado]
[-i | -o] [-S[ ]] [--] [ ...]

DESCRIPTION

Iniimbak ang kasalukuyang mga nilalaman ng index sa isang bagong commit kasama ng isang mensahe ng log mula sa
user na naglalarawan ng mga pagbabago.

Ang nilalaman na idaragdag ay maaaring tukuyin sa maraming paraan:

1. sa pamamagitan ng paggamit pumunta idagdag upang unti-unting "magdagdag" ng mga pagbabago sa index bago gamitin ang gumawa
command (Tandaan: kahit na ang mga binagong file ay dapat na "idagdag");

2. sa pamamagitan ng paggamit pumunta rm upang alisin ang mga file mula sa gumaganang puno at ang index, muli bago
gamit ang gumawa utos;

3. sa pamamagitan ng paglilista ng mga file bilang mga argumento sa gumawa utos, kung saan gagawin ng commit
huwag pansinin ang mga pagbabagong itinanghal sa index, at sa halip ay itala ang kasalukuyang nilalaman ng
nakalistang mga file (na dapat na kilala sa Git);

4. sa pamamagitan ng paggamit ng -a switch na may gumawa command na awtomatikong "magdagdag" ng mga pagbabago mula sa lahat
mga kilalang file (ibig sabihin, lahat ng mga file na nakalista na sa index) at awtomatikong
"rm" na mga file sa index na inalis mula sa working tree, at pagkatapos ay gumanap
ang aktwal na pangako;

5. sa pamamagitan ng paggamit ng --interactive o --patch switch na may gumawa utos na magpasya ng isa
ng isa kung aling mga file o hunks ang dapat maging bahagi ng commit, bago i-finalize ang
operasyon. Tingnan ang seksyong "Interactive Mode" ng git-add(1) upang malaman kung paano gumana
mga mode na ito.

Ang --dry-run na opsyon ay maaaring gamitin upang makakuha ng buod ng kung ano ang kasama ng alinman sa
sa itaas para sa susunod na commit sa pamamagitan ng pagbibigay ng parehong hanay ng mga parameter (mga opsyon at landas).

Kung gumawa ka ng isang commit at pagkatapos ay makahanap ng isang pagkakamali kaagad pagkatapos nito, maaari kang makabawi mula sa
ito sa pumunta i-reset ang.

Opsyon

-a, --lahat
Sabihin sa command na awtomatikong i-stage ang mga file na binago at tinanggal, ngunit
hindi apektado ang mga bagong file na hindi mo sinabi kay Git.

-p, --tagpi
Gamitin ang interactive na interface ng pagpili ng patch para piliin kung aling mga pagbabago ang gagawin. Tingnan mo
git-add(1) para sa mga detalye.

-C , --reuse-message=
Kumuha ng isang umiiral na object ng commit, at muling gamitin ang log message at ang authorship
impormasyon (kabilang ang timestamp) kapag gumagawa ng commit.

-c , --reedit-message=
katulad -C, pero may -c ang editor ay hinihimok, upang ang user ay makapag-edit pa ng
gumawa ng mensahe.

--fixup=
Bumuo ng commit message para gamitin sa rebase --autosquash. Ang commit message ay
maging linya ng paksa mula sa tinukoy na commit na may prefix na "fixup! ". Tingnan mo git-
pagbagsak(1) para sa mga detalye.

--kalabasa=
Bumuo ng commit message para gamitin sa rebase --autosquash. Ang commit message
Ang linya ng paksa ay kinuha mula sa tinukoy na commit na may prefix na "squash! ". Ay maaaring maging
ginamit sa mga karagdagang opsyon sa commit message (-m/-c/-C/-F). Tingnan mo git-rebase(1) para sa
mga detalye.

--reset-author
Kapag ginamit sa -C/-c/--amend na mga opsyon, o kapag nag-commit pagkatapos ng aa conflict
cherry-pick, ideklara na ang may-akda ng resultang commit ay pagmamay-ari na ngayon ng
committer. Nire-renew din nito ang timestamp ng may-akda.

--maikli
Kapag gumagawa ng dry-run, ibigay ang output sa short-format. Tingnan mo git-status(1) para sa
mga detalye. Nagpapahiwatig --dry-run.

--sangay
Ipakita ang sangay at impormasyon sa pagsubaybay kahit sa maikling format.

--porselana
Kapag gumagawa ng dry-run, ibigay ang output sa isang porselana-ready na format. Tingnan mo git-status(1)
para sa mga detalye. Nagpapahiwatig --dry-run.

--mahaba
Kapag gumagawa ng isang dry-run, ibigay ang output sa isang long-format. Nagpapahiwatig --dry-run.

-z, --null
Kapag nagpapakita ng maikli o porselana na status output, wakasan ang mga entry sa status output
may NUL, sa halip na LF. Kung walang ibinigay na format, ipinapahiwatig ang --porcelain na format ng output.

-F , --file=
Kunin ang commit message mula sa ibinigay na file. Gamitin - para basahin ang mensahe mula sa
karaniwang input.

--may-akda=
I-override ang commit author. Tumukoy ng tahasang may-akda gamit ang karaniwang AU Thor
<[protektado ng email]> format. Kung hindi ay ipinapalagay na isang pattern at ginagamit
upang maghanap ng umiiral nang commit ng may-akda na iyon (ibig sabihin, rev-list --all -i
--may-akda= ); ang commit author ay kinokopya mula sa unang nakitang commit.

--petsa=
I-override ang petsa ng may-akda na ginamit sa commit.

-m , --message=
Gamitin ang ibinigay bilang commit message. Kung maramihang -m na opsyon ang ibinigay, ang kanilang
ang mga halaga ay pinagsama-sama bilang hiwalay na mga talata.

-t , --template=
Kapag nag-e-edit ng commit message, simulan ang editor gamit ang mga nilalaman sa ibinigay na file.
Ang commit.template configuration variable ay kadalasang ginagamit upang ibigay ang opsyong ito
pahiwatig sa utos. Ang mekanismong ito ay maaaring gamitin ng mga proyektong gustong gumabay
mga kalahok na may ilang mga pahiwatig kung ano ang isusulat sa mensahe sa anong pagkakasunud-sunod. Kung ang
ang user ay lumabas sa editor nang hindi nag-e-edit ng mensahe, ang commit ay naabort. Ito ay walang
epekto kapag ang isang mensahe ay ibinigay sa pamamagitan ng iba pang paraan, hal sa mga -m o -F na opsyon.

-s, --signoff
Magdagdag ng Signed-off-by na linya ng committer sa dulo ng commit log message. Ang
Ang kahulugan ng isang signoff ay depende sa proyekto, ngunit karaniwan nitong pinatutunayan ang committer na iyon
ay may mga karapatang isumite ang gawaing ito sa ilalim ng parehong lisensya at sumasang-ayon sa isang Developer
Sertipiko ng Pinagmulan (tingnan http://developercertificate.org/ para sa karagdagang impormasyon).

-n, --no-verify
Nilalampasan ng opsyong ito ang pre-commit at commit-msg hooks. Tingnan din githooksNa (5).

--payagan-walang laman
Karaniwan ang pagre-record ng commit na may eksaktong kaparehong puno tulad ng commit ng nag-iisang magulang nito ay a
pagkakamali, at pinipigilan ka ng utos na gumawa ng ganoong pangako. Ang pagpipiliang ito ay lumalampas
kaligtasan, at pangunahing ginagamit ng mga dayuhang script ng interface ng SCM.

--allow-empty-message
Tulad ng --allow-empty ang command na ito ay pangunahing ginagamit ng mga dayuhang script ng interface ng SCM.
Binibigyang-daan ka nitong gumawa ng commit na may walang laman na commit message nang hindi gumagamit ng plumbing
mga utos tulad ng git-commit-treeNa (1).

--paglilinis=
Tinutukoy ng opsyong ito kung paano dapat linisin bago ang ibinigay na mensahe ng commit
nangangako. Ang maaaring strip, whitespace, verbatim, gunting o default.

alisan ng
I-strip ang leading at trailing na walang laman na linya, trailing whitespace, komentaryo at
i-collapse ang magkakasunod na walang laman na linya.

whitespace
Kapareho ng strip maliban sa #commentary ay hindi inalis.

walang kulang ang pangungusap
Huwag baguhin ang mensahe.

gunting
Pareho sa whitespace, maliban sa lahat ng bagay mula sa (at kasama) ang linyang "#
------------------------- >8 ----------------------- " ay pinutol kung ang mensahe
ay dapat i-edit. Maaaring i-customize ang "#" gamit ang core.commentChar.

default
Kapareho ng strip kung ie-edit ang mensahe. Kung hindi, whitespace.

Ang default ay maaaring baguhin ng mangako.paglilinis variable ng pagsasaayos (tingnan git-
config(1)).

-e, --edit
Ang mensaheng kinuha mula sa file na may -F, command line na may -m, at mula sa commit object na may
-C ay karaniwang ginagamit bilang ang commit log message na hindi binago. Hinahayaan ka ng opsyong ito
i-edit ang mensaheng kinuha mula sa mga mapagkukunang ito.

--walang-edit
Gamitin ang napiling commit message nang hindi naglulunsad ng editor. Halimbawa, ang git commit
--amend --no-edit ay nagsususog sa isang commit nang hindi binabago ang commit na mensahe nito.

--amyendahan
Palitan ang dulo ng kasalukuyang branch sa pamamagitan ng paggawa ng bagong commit. Ang naitalang puno ay
inihanda gaya ng dati (kabilang ang epekto ng -i at -o na mga opsyon at tahasang
pathspec), at ang mensahe mula sa orihinal na commit ay ginagamit bilang panimulang punto,
sa halip na isang walang laman na mensahe, kapag walang ibang mensahe ang tinukoy mula sa command line
sa pamamagitan ng mga opsyon gaya ng -m, -F, -c, atbp. Ang bagong commit ay may parehong mga magulang at may-akda bilang
ang kasalukuyang isa (ang --reset-author na opsyon ay maaaring kontrahin ito).

Ito ay isang magaspang na katumbas para sa:

$ git reset --soft HEAD^
$ ... gumawa ng ibang bagay upang makabuo ng tamang puno ...
$ git commit -c ORIG_HEAD

ngunit maaaring gamitin upang baguhin ang isang merge commit.

Dapat mong maunawaan ang mga implikasyon ng muling pagsusulat ng kasaysayan kung susugan mo ang isang ginawa iyon
ay nai-publish na. (Tingnan ang seksyong "PAG-RECOVER MULA SA UPSTREAM REBASE" sa git-
pagbagsak(1).)

--walang-post-rewrite
I-bypass ang post-rewrite hook.

-i, --isama
Bago gumawa ng commit sa mga nakaplanong nilalaman sa ngayon, isagawa ang mga nilalaman ng mga landas
ibinigay din sa command line. Karaniwang hindi ito ang gusto mo maliban kung ikaw
pagwawakas ng magkasalungat na pagsasanib.

-o, --lamang
Gumawa ng commit sa pamamagitan ng pagkuha ng na-update na working tree na nilalaman ng mga path na tinukoy sa
ang command line, na binabalewala ang anumang mga nilalaman na itinanghal para sa iba pang mga landas.
Ito ang default na mode ng pagpapatakbo ng pumunta gumawa kung anumang mga landas ang ibinigay sa
command line, kung saan ang pagpipiliang ito ay maaaring tanggalin. Kung ang pagpipiliang ito ay tinukoy
Kasama --amyendahan, pagkatapos ay walang mga path na kailangang tukuyin, na maaaring magamit upang baguhin
ang huling commit nang hindi gumagawa ng mga pagbabago na naisagawa na.

-u[ ], --untracked-files[= ]
Ipakita ang mga hindi sinusubaybayang file.

Ang parameter ng mode ay opsyonal (naka-default sa lahat), at ginagamit upang tukuyin ang paghawak
ng mga hindi sinusubaybayang file; kapag -u ay hindi ginagamit, ang default ay normal, ibig sabihin, hindi sinusubaybayan ang palabas
mga file at direktoryo.

Ang mga posibleng opsyon ay:

· hindi - Magpakita ng walang hindi sinusubaybayang mga file

· normal - Nagpapakita ng hindi sinusubaybayang mga file at direktoryo

· lahat - Nagpapakita din ng mga indibidwal na file sa mga hindi sinusubaybayang direktoryo.

Maaaring baguhin ang default gamit ang configuration ng status.showUntrackedFiles
variable na nakadokumento sa git-configNa (1).

-v, --verbose
Ipakita ang pinag-isang diff sa pagitan ng HEAD commit at kung ano ang gagawin sa ibaba ng
ang template ng commit message upang matulungan ang user na ilarawan ang commit sa pamamagitan ng pagpapaalala kung ano
mga pagbabago na mayroon ang commit. Tandaan na ang diff output na ito ay walang mga linya nito na prefix
sa #. Ang diff na ito ay hindi magiging bahagi ng commit message.

Kung tinukoy nang dalawang beses, ipakita bilang karagdagan ang pinag-isang pagkakaiba sa pagitan ng kung ano ang gagawin
at ang mga worktree file, ibig sabihin, ang mga hindi naka-stage na pagbabago sa mga sinusubaybayang file.

-q, --tahimik
Pigilan ang commit summary message.

--dry-run
Huwag gumawa ng commit, ngunit magpakita ng listahan ng mga path na dapat gawin, mga path na kasama
mga lokal na pagbabago na iiwan na hindi naka-commit at mga landas na hindi nasusubaybayan.

--katayuan
Isama ang output ng git-status(1) sa template ng commit message kapag gumagamit ng isang
editor upang ihanda ang commit message. Ang mga default ay naka-on, ngunit maaaring gamitin upang i-override
configuration variable commit.status.

--walang estado
Huwag isama ang output ng git-status(1) sa template ng commit message kapag ginagamit
isang editor para ihanda ang default na commit message.

-S[ ], --gpg-sign[= ]
GPG-sign commit. Ang keyid argument ay opsyonal at default sa committer
pagkakakilanlan; kung tinukoy, dapat itong nakadikit sa opsyon nang walang puwang.

--walang-gpg-sign
Countermand commit.gpgSign configuration variable na nakatakdang pilitin ang bawat isa
mangako na mapirmahan.

--
Huwag bigyang-kahulugan ang anumang mga argumento bilang mga pagpipilian.

...
Kapag ang mga file ay ibinigay sa command line, ang utos ay gumagawa ng mga nilalaman ng
pinangalanang mga file, nang hindi naitala ang mga pagbabagong naisagawa na. Ang mga nilalaman ng mga file na ito
ay itinanghal din para sa susunod na commit sa itaas ng kung ano ang itinanghal dati.

DATE FORMATS

Ang GIT_AUTHOR_DATE, GIT_COMMITTER_DATE na mga variable sa kapaligiran at ang --date na opsyon
suportahan ang mga sumusunod na format ng petsa:

Git panloob na format
Ito ay , saan ay ang bilang ng
segundo mula noong panahon ng UNIX. ay isang positibo o negatibong offset
mula sa UTC. Halimbawa ang CET (na 2 oras bago ang UTC) ay +0200.

RFC 2822
Ang karaniwang format ng email gaya ng inilarawan ng RFC 2822, halimbawa Thu, 07 Abr 2005
22:13:13 +0200.

ISO 8601
Oras at petsa na tinukoy ng pamantayang ISO 8601, halimbawa 2005-04-07T22:13:13. Ang
tumatanggap din ang parser ng puwang sa halip na T character.

nota
Bilang karagdagan, ang bahagi ng petsa ay tinatanggap sa mga sumusunod na format: YYYY.MM.DD,
MM/DD/YYYY at DD.MM.YYYY.

HALIMBAWA

Kapag nagre-record ng iyong sariling gawa, ang mga nilalaman ng binagong mga file sa iyong working tree ay
pansamantalang nakaimbak sa isang staging area na tinatawag na "index" na may pumunta idagdag. Ang isang file ay maaaring
ibinalik, sa index lamang ngunit hindi sa working tree, sa huling commit
gamit ang git reset HEAD -- , na epektibong bumabalik pumunta idagdag at pinipigilan ang mga pagbabago
sa file na ito mula sa paglahok sa susunod na commit. Matapos mabuo ang magiging estado
unti-unting ginawa ang mga utos na ito, git commit (nang walang anumang parameter ng pathname)
ay ginagamit upang itala kung ano ang itinanghal sa ngayon. Ito ang pinakapangunahing anyo ng utos.
Isang halimbawa:

$ edit hello.c
$ git rm paalam.c
$ git add hello.c
$ git commit

Sa halip na mag-staging ng mga file pagkatapos ng bawat indibidwal na pagbabago, maaari mong sabihin sa git commit na mapansin
ang mga pagbabago sa mga file na ang mga nilalaman ay sinusubaybayan sa iyong gumaganang puno at ginagawa
kaukulang git add at git rm para sa iyo. Ibig sabihin, ginagawa ng halimbawang ito ang katulad ng
naunang halimbawa kung walang ibang pagbabago sa iyong working tree:

$ edit hello.c
$ rm paalam.c
$ git commit -a

Ang utos na git commit -a unang tumingin sa iyong gumaganang puno, napansin na binago mo
hello.c at inalis ang goodbye.c, at nagsasagawa ng kinakailangang git add at git rm para sa iyo.

Pagkatapos magsagawa ng mga pagbabago sa maraming file, maaari mong baguhin ang pagkakasunud-sunod kung saan naitala ang mga pagbabago,
sa pamamagitan ng pagbibigay ng mga pathname sa git commit. Kapag ang mga pathname ay ibinigay, ang command ay gumagawa ng isang commit
na nagtatala lamang ng mga pagbabagong ginawa sa mga pinangalanang landas:

$ edit hello.c hello.h
$ git add hello.c hello.h
$ i-edit ang Makefile
$ git commit Makefile

Gumagawa ito ng commit na nagtatala ng pagbabago sa Makefile. Ang mga pagbabago ay itinanghal para sa
hello.c at hello.h ay hindi kasama sa resultang commit. Gayunpaman, ang kanilang mga pagbabago ay
hindi nawala — sila ay itinanghal pa rin at pinipigilan lamang. Pagkatapos ng pagkakasunod-sunod sa itaas, kung ikaw
gawin:

$ git commit

ang pangalawang commit na ito ay magtatala ng mga pagbabago sa hello.c at hello.h gaya ng inaasahan.

Pagkatapos ng isang pagsasanib (pinasimulan ni pumunta pagsamahin or pumunta paghila) humihinto dahil sa mga salungatan, malinis
ang mga pinagsanib na landas ay nakatakdang gawin para sa iyo, at ang mga landas na magkasalungat ay
naiwan sa unmerged state. Kailangan mo munang suriin kung aling mga landas ang sumasalungat pumunta
katayuan at pagkatapos ayusin ang mga ito nang manu-mano sa iyong gumaganang puno, gagawin mo ang resulta bilang
karaniwan sa pumunta idagdag:

$ git status | hindi pinagsama ang grep
hindi pinagsama: hello.c
$ edit hello.c
$ git add hello.c

Matapos malutas ang mga salungatan at isagawa ang resulta, ang git ls-files -u ay titigil sa pagbanggit
ang magkasalungat na landas. Kapag tapos ka na, patakbuhin ang git commit upang sa wakas ay maitala ang pagsasanib:

$ git commit

Tulad ng kaso upang itala ang iyong sariling mga pagbabago, maaari mong gamitin ang -isang opsyon upang i-save ang pagta-type. Isa
Ang pagkakaiba ay sa panahon ng isang pagsasanib na resolusyon, hindi mo magagamit ang git commit na may mga pathname sa
baguhin ang pagkakasunud-sunod na ginawa ang mga pagbabago, dahil ang pagsasanib ay dapat itala bilang a
single commit. Sa katunayan, ang utos ay tumangging tumakbo kapag binigyan ng mga pathname (ngunit tingnan ang -i
pagpipilian).

Pagtalakay

Bagama't hindi kinakailangan, magandang ideya na simulan ang commit message sa isang maikling
(mas mababa sa 50 character) na linyang nagbubuod ng pagbabago, na sinusundan ng isang blangkong linya at pagkatapos ay a
mas masusing paglalarawan. Ang text hanggang sa unang blangko na linya sa isang commit message ay
itinuturing bilang pamagat ng commit, at ang pamagat na iyon ay ginagamit sa buong Git. Halimbawa, git-
format-patch(1) ginagawang email ang isang commit, at ginagamit nito ang pamagat sa linya ng Paksa at
ang natitirang bahagi ng commit sa katawan.

Ang Git ay medyo agnostic ang pag-encode ng character.

· Ang mga nilalaman ng mga blob na bagay ay hindi naiintindihan na mga pagkakasunud-sunod ng mga byte. Walang
pag-encode ng pagsasalin sa pangunahing antas.

· Ang mga pangalan ng path ay naka-encode sa UTF-8 normalization form C. Nalalapat ito sa mga tree object,
ang index file, mga pangalan ng ref, pati na rin ang mga pangalan ng path sa mga argumento ng command line,
mga variable ng kapaligiran at mga config file (.git/config (tingnan ang git-config(1)), gitignoreNa (5),
gitattributes(5) at gitmodules(5)).

Tandaan na ang Git sa core level ay tinatrato ang mga pangalan ng path bilang mga sequence ng non-NUL
bytes, walang path name encoding conversions (maliban sa Mac at Windows).
Samakatuwid, ang paggamit ng mga pangalan ng path na hindi ASCII ay kadalasang gagana kahit sa mga platform at file
mga system na gumagamit ng legacy extended ASCII encodings. Gayunpaman, ginawa ang mga repository sa
hindi gagana nang maayos ang mga naturang system sa mga UTF-8-based na system (hal. Linux, Mac, Windows)
at vice versa. Bukod pa rito, maraming mga tool na nakabatay sa Git ang ipinapalagay lamang na ang mga pangalan ng landas
UTF-8 at mabibigo na maipakita nang tama ang iba pang mga pag-encode.

· Ang mga mensahe ng commit log ay karaniwang naka-encode sa UTF-8, ngunit iba pang pinahabang ASCII encoding
ay sinusuportahan din. Kabilang dito ang ISO-8859-x, CP125x at marami pang iba, ngunit hindi
Mga multi-byte na encoding ng UTF-16/32, EBCDIC at CJK (GBK, Shift-JIS, Big5, EUC-x, CP9xx
atbp).

Bagama't hinihikayat namin na ang mga mensahe ng commit log ay naka-encode sa UTF-8, parehong core at
Ang Git Porcelain ay idinisenyo upang hindi pilitin ang UTF-8 sa mga proyekto. Kung lahat ng kalahok ng a
Ang partikular na proyekto ay mas madaling gumamit ng mga legacy encoding, hindi ipinagbabawal ng Git
ito. Gayunpaman, may ilang mga bagay na dapat tandaan.

1. pumunta gumawa at pumunta commit-tree nagbibigay ng babala kung ang commit log message ay ibinigay dito
ay hindi mukhang isang wastong string ng UTF-8, maliban kung tahasan mong sabihin na ang iyong proyekto ay gumagamit ng a
legacy encoding. Ang paraan para sabihin ito ay ang pagkakaroon ng i18n.commitencoding sa .git/config
file, tulad nito:

[i18n]
commitencoding = ISO-8859-1

Ang mga commit na bagay na ginawa gamit ang setting sa itaas ay nagtala ng halaga ng i18n.commitencoding
sa header ng pag-encode nito. Ito ay para makatulong sa ibang tao na titingin sa kanila mamaya. Kakulangan ng
ang header na ito ay nagpapahiwatig na ang commit log message ay naka-encode sa UTF-8.

2. pumunta mag-log, pumunta Ipakita, pumunta magbigay-sala at tinitingnan ng mga kaibigan ang encoding header ng isang commit
object, at subukang muling i-code ang log message sa UTF-8 maliban kung tinukoy. Ikaw
maaaring tukuyin ang nais na pag-encode ng output gamit ang i18n.logoutputencoding sa .git/config
file, tulad nito:

[i18n]
logoutputencoding = ISO-8859-1

Kung wala kang configuration variable na ito, ang value ng i18n.commitencoding ay
ginamit na naman.

Tandaan na sadyang pinili naming huwag muling i-code ang commit log message kapag may commit
ginawa para pilitin ang UTF-8 sa commit object level, dahil hindi ang re-coding sa UTF-8
kinakailangang isang nababaligtad na operasyon.

Kapaligiran AT Configuration MGA VARIABLE

Ang editor na ginamit upang i-edit ang commit log message ay pipiliin mula sa GIT_EDITOR
environment variable, ang core.editor configuration variable, ang VISUAL environment
variable, o ang EDITOR environment variable (sa ayos na iyon). Tingnan mo git-var(1) para sa mga detalye.

PAKIKITA

Ang command na ito ay maaaring magpatakbo ng commit-msg, prepare-commit-msg, pre-commit, at post-commit hooks.
Tingnan githooks(5) para sa karagdagang impormasyon.

Gumamit ng git-commit online gamit ang mga serbisyo ng onworks.net