ນີ້ແມ່ນຄໍາສັ່ງ git-commit ທີ່ສາມາດດໍາເນີນການໄດ້ໃນ OnWorks ຜູ້ໃຫ້ບໍລິການໂຮດຕິ້ງຟຣີໂດຍໃຊ້ຫນຶ່ງໃນຫຼາຍໆບ່ອນເຮັດວຽກອອນໄລນ໌ຂອງພວກເຮົາເຊັ່ນ Ubuntu Online, Fedora Online, Windows online emulator ຫຼື MAC OS online emulator
ໂຄງການ:
NAME
git-commit - ບັນທຶກການປ່ຽນແປງກັບ repository
ສະຫຼຸບສັງລວມ
ໄປ ຄໍາຫມັ້ນສັນຍາ [-a | --ໂຕ້ຕອບ | --patch] [-s] [-v] [-u ] [--ດັດແກ້]
[--dry-run] [(-c | -C | --fixup | --squash) ]
[-ຟ | - ມ ] [--reset-author] [--allow-empty]
[--allow-empty-message] [--no-verify] [-e] [--author= ]
[--date= ] [--cleanup= ] [--[ບໍ່-]ສະຖານະ]
[-i | -o] [-S[ ]] [--] [ ...]
ລາຍລະອຽດ
ເກັບຮັກສາເນື້ອໃນປະຈຸບັນຂອງດັດຊະນີໃນຄໍາຫມັ້ນສັນຍາໃຫມ່ພ້ອມກັບຂໍ້ຄວາມບັນທຶກຈາກ
ຜູ້ໃຊ້ອະທິບາຍການປ່ຽນແປງ.
ເນື້ອໃນທີ່ຈະເພີ່ມສາມາດໄດ້ຮັບການລະບຸໄວ້ໃນຫຼາຍວິທີ:
1. ໂດຍການນໍາໃຊ້ ໄປ ເພີ່ມ ເພື່ອ incrementally "ເພີ່ມ" ການປ່ຽນແປງໃນດັດຊະນີກ່ອນທີ່ຈະນໍາໃຊ້ ຄໍາຫມັ້ນສັນຍາ
ຄໍາສັ່ງ (ຫມາຍເຫດ: ເຖິງແມ່ນວ່າໄຟລ໌ດັດແກ້ຕ້ອງໄດ້ຮັບການ "ເພີ່ມ");
2. ໂດຍການນໍາໃຊ້ ໄປ rm ເພື່ອເອົາໄຟລ໌ອອກຈາກຕົ້ນໄມ້ທີ່ເຮັດວຽກແລະດັດສະນີ, ອີກເທື່ອຫນຶ່ງກ່ອນ
ການນໍາໃຊ້ ຄໍາຫມັ້ນສັນຍາ ຄໍາສັ່ງ;
3. ໂດຍລາຍຊື່ໄຟລ໌ເປັນການໂຕ້ຖຽງກັບ ຄໍາຫມັ້ນສັນຍາ ຄໍາສັ່ງ, ໃນກໍລະນີນີ້ຄໍາຫມັ້ນສັນຍາຈະ
ບໍ່ສົນໃຈການປ່ຽນແປງຂັ້ນຕອນໃນດັດຊະນີ, ແລະແທນທີ່ຈະບັນທຶກເນື້ອຫາໃນປະຈຸບັນຂອງ
ໄຟລ໌ທີ່ມີລາຍຊື່ (ເຊິ່ງຈະຕ້ອງຮູ້ຈັກກັບ Git ແລ້ວ);
4. ໂດຍການນໍາໃຊ້ສະຫຼັບ -a ກັບ ຄໍາຫມັ້ນສັນຍາ ຄໍາສັ່ງທີ່ຈະອັດຕະໂນມັດ "ເພີ່ມ" ການປ່ຽນແປງຈາກທັງຫມົດ
ໄຟລ໌ທີ່ຮູ້ຈັກ (ເຊັ່ນວ່າໄຟລ໌ທັງຫມົດທີ່ມີຢູ່ແລ້ວໃນດັດຊະນີ) ແລະອັດຕະໂນມັດ
ໄຟລ໌ "rm" ໃນດັດຊະນີທີ່ຖືກລຶບອອກຈາກຕົ້ນໄມ້ທີ່ເຮັດວຽກ, ແລະຫຼັງຈາກນັ້ນປະຕິບັດ
ຄໍາຫມັ້ນສັນຍາຕົວຈິງ;
5. ໂດຍການນໍາໃຊ້ --interactive ຫຼື --patch ສະຫຼັບກັບ ຄໍາຫມັ້ນສັນຍາ ຄໍາສັ່ງເພື່ອຕັດສິນໃຈຫນຶ່ງ
ໂດຍຫນຶ່ງທີ່ໄຟລ໌ຫຼື hunks ຄວນເປັນສ່ວນຫນຶ່ງຂອງຄໍາຫມັ້ນສັນຍາ, ກ່ອນທີ່ຈະສໍາເລັດການ
ການດໍາເນີນງານ. ເບິ່ງພາກ "ຮູບແບບການໂຕ້ຕອບ" ຂອງ git-add(1) ເພື່ອຮຽນຮູ້ວິທີການປະຕິບັດງານ
ຮູບແບບເຫຼົ່ານີ້.
ທາງເລືອກ --dry-run ສາມາດຖືກນໍາມາໃຊ້ເພື່ອໃຫ້ໄດ້ບົດສະຫຼຸບຂອງສິ່ງທີ່ລວມຢູ່ໃນອັນໃດນຶ່ງ
ຂ້າງເທິງສໍາລັບຄໍາຫມັ້ນສັນຍາຕໍ່ໄປໂດຍການໃຫ້ຊຸດດຽວກັນຂອງພາລາມິເຕີ (ທາງເລືອກແລະເສັ້ນທາງ).
ຖ້າຫາກວ່າທ່ານເຮັດໃຫ້ຄໍາຫມັ້ນສັນຍາແລະຫຼັງຈາກນັ້ນຊອກຫາຄວາມຜິດພາດທັນທີຫຼັງຈາກນັ້ນ, ທ່ານສາມາດຟື້ນຕົວຈາກ
ມັນກັບ ໄປ reset.
OPTIONS
-a, --ທັງໝົດ
ບອກຄໍາສັ່ງທີ່ຈະອັດຕະໂນມັດຂັ້ນຕອນຂອງໄຟລ໌ທີ່ຖືກດັດແກ້ແລະລຶບ, ແຕ່
ໄຟລ໌ໃຫມ່ທີ່ທ່ານບໍ່ໄດ້ບອກ Git ແມ່ນບໍ່ໄດ້ຮັບຜົນກະທົບ.
-p, --patch
ໃຊ້ການໂຕ້ຕອບການເລືອກ patch ແບບໂຕ້ຕອບເພື່ອເລືອກການປ່ຽນແປງທີ່ຈະເຮັດ. ເບິ່ງ
git-add(1) ສໍາລັບລາຍລະອຽດ.
-ຄ , --reuse-message=
ເອົາວັດຖຸຄໍາຫມັ້ນສັນຍາທີ່ມີຢູ່ແລ້ວ, ແລະນໍາໃຊ້ຂໍ້ຄວາມບັນທຶກແລະການປະພັນຄືນ
ຂໍ້ມູນ (ລວມທັງເວລາ) ໃນເວລາສ້າງຄໍາຫມັ້ນສັນຍາ.
-ຄ , --reedit-message=
ຄື -C, ແຕ່ວ່າມີ -c ບັນນາທິການໄດ້ຖືກຮຽກຮ້ອງ, ດັ່ງນັ້ນຜູ້ໃຊ້ສາມາດແກ້ໄຂເພີ່ມເຕີມໄດ້
ຄໍາຫມັ້ນສັນຍາຂໍ້ຄວາມ.
--fixup=
ກໍ່ສ້າງຂໍ້ຄວາມຄໍາຫມັ້ນສັນຍາສໍາລັບການນໍາໃຊ້ກັບ rebase --autosquash. ຂໍ້ຄວາມສັນຍາຈະ
ເປັນຫົວຂໍ້ຈາກຄໍາຫມັ້ນສັນຍາທີ່ລະບຸໄວ້ກັບຄໍານໍາຫນ້າຂອງ "fixup!". ເບິ່ງ git-
ປະຕິເສດ(1) ສໍາລັບລາຍລະອຽດ.
--squash=
ກໍ່ສ້າງຂໍ້ຄວາມຄໍາຫມັ້ນສັນຍາສໍາລັບການນໍາໃຊ້ກັບ rebase --autosquash. ຂໍ້ຄວາມສັນຍາ
ເສັ້ນຫົວຂໍ້ແມ່ນເອົາມາຈາກຄໍາຫມັ້ນສັນຍາທີ່ລະບຸໄວ້ດ້ວຍຄໍານໍາຫນ້າຂອງ "squash!". ສາມາດເປັນ
ນຳໃຊ້ກັບຕົວເລືອກຂໍ້ຄວາມຄຳໝັ້ນສັນຍາເພີ່ມເຕີມ (-m/-c/-C/-F). ເບິ່ງ git-rebase(1) ສໍາລັບ
ລາຍລະອຽດ.
--reset-ຜູ້ຂຽນ
ເມື່ອໃຊ້ກັບ -C/-c/-- ແກ້ໄຂທາງເລືອກ, ຫຼືເມື່ອປະຕິບັດຫຼັງຈາກ aa ຂັດກັນ
cherry-pick, ປະກາດວ່າ authorship ຂອງຄໍາຫມັ້ນສັນຍາຜົນໄດ້ຮັບໃນປັດຈຸບັນເປັນຂອງ
ກຳມະການ. ອັນນີ້ຍັງຕໍ່ອາຍຸເວລາຂອງຜູ້ຂຽນ.
--ສັ້ນ
ໃນເວລາທີ່ດໍາເນີນການແຫ້ງ, ໃຫ້ຜົນຜະລິດໃນຮູບແບບສັ້ນ. ເບິ່ງ git-ສະຖານະ(1) ສໍາລັບ
ລາຍລະອຽດ. ຫມາຍເຖິງ --dry-run.
--ສາຂາ
ສະແດງສາຂາ ແລະຂໍ້ມູນການຕິດຕາມເຖິງແມ່ນວ່າໃນຮູບແບບສັ້ນ.
-- porcelain
ເມື່ອດໍາເນີນການແຫ້ງ, ໃຫ້ຜົນຜະລິດໃນຮູບແບບທີ່ກຽມພ້ອມ porcelain. ເບິ່ງ git-ສະຖານະ(1)
ສໍາລັບລາຍລະອຽດ. ຫມາຍເຖິງ --dry-run.
-- ຍາວ
ໃນເວລາທີ່ດໍາເນີນການແຫ້ງ, ໃຫ້ຜົນຜະລິດໃນຮູບແບບຍາວ. ຫມາຍເຖິງ --dry-run.
-z, --null
ເມື່ອສະແດງຜົນອອກສະຖານະສັ້ນ ຫຼື porcelain, ໃຫ້ຢຸດການປ້ອນຂໍ້ມູນໃນສະຖານະຜົນຜະລິດ
ກັບ NUL, ແທນ LF. ຖ້າຫາກວ່າບໍ່ມີຮູບແບບແມ່ນໄດ້ຮັບການ, ຫມາຍຄວາມວ່າຮູບແບບການຜະລິດໄດ້ --porcelain.
-F , --file=
ເອົາຂໍ້ຄວາມຄໍາຫມັ້ນສັນຍາຈາກໄຟລ໌ທີ່ໃຫ້. ໃຊ້ - ເພື່ອອ່ານຂໍ້ຄວາມຈາກ
ວັດສະດຸປ້ອນມາດຕະຖານ.
--ຜູ້ຂຽນ=
ລົບລ້າງຜູ້ຂຽນທີ່ໝັ້ນໝາຍ. ລະບຸຜູ້ຂຽນທີ່ຊັດເຈນໂດຍໃຊ້ມາດຕະຖານ AU Thor
<[email protected]> ຮູບແບບ. ຖ້າບໍ່ດັ່ງນັ້ນ ແມ່ນສົມມຸດວ່າເປັນຮູບແບບແລະຖືກນໍາໃຊ້
ເພື່ອຊອກຫາຄໍາຫມັ້ນສັນຍາທີ່ມີຢູ່ແລ້ວໂດຍຜູ້ຂຽນນັ້ນ (ເຊັ່ນ: rev-list --all -i
--ຜູ້ຂຽນ= ); ຫຼັງຈາກນັ້ນ, ຜູ້ຂຽນຄໍາຫມັ້ນສັນຍາໄດ້ຖືກຄັດລອກຈາກຄໍາຫມັ້ນສັນຍາທໍາອິດທີ່ພົບເຫັນ.
--date=
ລົບລ້າງວັນທີຜູ້ຂຽນທີ່ໃຊ້ໃນຄໍາຫມັ້ນສັນຍາ.
- ມ , --message=
ໃຊ້ໃຫ້ ເປັນຂໍ້ຄວາມຄໍາຫມັ້ນສັນຍາ. ຖ້າຕົວເລືອກຫຼາຍ -m ຖືກໃຫ້, ຂອງພວກເຂົາ
ຄ່າແມ່ນ concatenated ເປັນວັກແຍກຕ່າງຫາກ.
-t , --ແມ່ແບບ=
ເມື່ອແກ້ໄຂຂໍ້ຄວາມສັນຍາ, ເລີ່ມຕົ້ນບັນນາທິການດ້ວຍເນື້ອຫາໃນໄຟລ໌ທີ່ໃຫ້.
ຕົວແປການຕັ້ງຄ່າ commit.template ມັກຈະຖືກໃຊ້ເພື່ອໃຫ້ທາງເລືອກນີ້
implicitly ກັບຄໍາສັ່ງ. ກົນໄກນີ້ສາມາດຖືກນໍາໃຊ້ໂດຍໂຄງການທີ່ຕ້ອງການແນະນໍາ
ຜູ້ເຂົ້າຮ່ວມມີຄໍາແນະນໍາບາງຢ່າງກ່ຽວກັບສິ່ງທີ່ຈະຂຽນໃນຂໍ້ຄວາມໃນຄໍາສັ່ງໃດ. ຖ້າ
ຜູ້ໃຊ້ອອກຈາກບັນນາທິການໂດຍບໍ່ມີການແກ້ໄຂຂໍ້ຄວາມ, ຄໍາຫມັ້ນສັນຍາຖືກຍົກເລີກ. ນີ້ບໍ່ມີ
ມີຜົນກະທົບໃນເວລາທີ່ຂໍ້ຄວາມແມ່ນໄດ້ຮັບໂດຍວິທີການອື່ນໆ, ເຊັ່ນ: ມີທາງເລືອກ -m ຫຼື -F.
-s, --signoff
ຕື່ມການລົງລາຍເຊັນ-ປິດ-ໂດຍແຖວໂດຍ committer ໃນຕອນທ້າຍຂອງຂໍ້ຄວາມບັນທຶກຄໍາຫມັ້ນສັນຍາ. ໄດ້
ຄວາມຫມາຍຂອງການລົງນາມແມ່ນຂຶ້ນກັບໂຄງການ, ແຕ່ໂດຍທົ່ວໄປແລ້ວມັນຢັ້ງຢືນວ່າ committer
ມີສິດທີ່ຈະສົ່ງວຽກງານນີ້ພາຍໃຕ້ໃບອະນຸຍາດດຽວກັນແລະຕົກລົງເຫັນດີກັບນັກພັດທະນາ
ໃບຢັ້ງຢືນຕົ້ນກໍາເນີດ (ເບິ່ງ http://developercertificate.org/ ສຳ ລັບຂໍ້ມູນເພີ່ມເຕີມ).
-n, --no-verify
ຕົວເລືອກນີ້ຂ້າມການຕັ້ງຂໍ້ຜູກມັດກ່ອນ ແລະຄຳໝັ້ນສັນຍາຂໍ້ຄວາມ. ເບິ່ງນຳ Githooks(5).
--allow-ເປົ່າ
ປົກກະຕິແລ້ວການບັນທຶກຄໍາຫມັ້ນສັນຍາທີ່ມີຕົ້ນໄມ້ດຽວກັນຄືກັນອ້ອຍຕ້ອຍເປັນຄໍາຫມັ້ນສັນຍາພໍ່ແມ່ sole ຂອງຕົນເປັນ
ຜິດພາດ, ແລະຄໍາສັ່ງປ້ອງກັນບໍ່ໃຫ້ທ່ານເຮັດຄໍາຫມັ້ນສັນຍາດັ່ງກ່າວ. ທາງເລືອກນີ້ຂ້າມ
ຄວາມປອດໄພ, ແລະຕົ້ນຕໍແມ່ນສໍາລັບການນໍາໃຊ້ໂດຍສະຄິບການໂຕ້ຕອບ SCM ຕ່າງປະເທດ.
--allow-empty-message
ເຊັ່ນດຽວກັນກັບ --allow-empty ຄໍາສັ່ງນີ້ແມ່ນຕົ້ນຕໍສໍາລັບການນໍາໃຊ້ໂດຍສະຄິບການໂຕ້ຕອບ SCM ຕ່າງປະເທດ.
ມັນອະນຸຍາດໃຫ້ທ່ານສ້າງຄໍາຫມັ້ນສັນຍາທີ່ມີຂໍ້ຄວາມຄໍາຫມັ້ນສັນຍາຫວ່າງເປົ່າໂດຍບໍ່ຕ້ອງໃຊ້ທໍ່
ຄໍາສັ່ງເຊັ່ນ git-commit-tree(1).
--ອະນາໄມ=
ຕົວເລືອກນີ້ກໍານົດວິທີການທີ່ຂໍ້ຄວາມຄໍາຫມັ້ນສັນຍາທີ່ສະຫນອງໃຫ້ຄວນຈະຖືກອະນາໄມກ່ອນ
ຄໍາຫມັ້ນສັນຍາ. ໄດ້ ສາມາດເປັນເສັ້ນດ່າງ, ຊ່ອງຫວ່າງ, verbatim, ມີດຕັດ ຫຼືຄ່າເລີ່ມຕົ້ນ.
ອອກ
ລອກເອົາເສັ້ນທີ່ນໍາໜ້າ ແລະຕິດຕາມເສັ້ນຫວ່າງເປົ່າ, ຕິດຕາມຊ່ອງຫວ່າງ, ຄຳເຫັນ ແລະ
ຫຍໍ້ແຖວຫວ່າງເປົ່າຕິດຕໍ່ກັນ.
ຍະຫວ່າງ
ຄືກັນກັບແຖບຍົກເວັ້ນ # ຄໍາຄິດເຫັນບໍ່ໄດ້ຖືກໂຍກຍ້າຍ.
ຄຳ ຕໍ່ເນື່ອງ
ຢ່າປ່ຽນຂໍ້ຄວາມເລີຍ.
scissors
ຄືກັນກັບຊ່ອງຫວ່າງ, ຍົກເວັ້ນທຸກສິ່ງທຸກຢ່າງຈາກ (ແລະລວມທັງ) ເສັ້ນ "#
----------------------->8 ----------------------- " ຖືກຕັດອອກຖ້າຂໍ້ຄວາມ
ແມ່ນຈະໄດ້ຮັບການແກ້ໄຂ. "#" ສາມາດປັບແຕ່ງໄດ້ດ້ວຍ core.commentChar.
Default
ຄືກັນກັບແຖບຖ້າຂໍ້ຄວາມຈະຖືກແກ້ໄຂ. ຖ້າບໍ່ດັ່ງນັ້ນຊ່ອງຫວ່າງ.
ຄ່າເລີ່ມຕົ້ນສາມາດປ່ຽນແປງໄດ້ໂດຍ commit.cleanup ຕົວແປການຕັ້ງຄ່າ (ເບິ່ງ git-
config(1)).
-e, -ແກ້ໄຂ
ຂໍ້ຄວາມທີ່ເອົາມາຈາກໄຟລ໌ທີ່ມີ -F, ເສັ້ນຄໍາສັ່ງທີ່ມີ -m, ແລະຈາກ commit object ກັບ
-C ປົກກະຕິແລ້ວຖືກໃຊ້ເປັນຂໍ້ຄວາມບັນທຶກທີ່ບໍ່ໄດ້ດັດແກ້. ທາງເລືອກນີ້ຊ່ວຍໃຫ້ທ່ານເພີ່ມເຕີມ
ແກ້ໄຂຂໍ້ຄວາມທີ່ມາຈາກແຫຼ່ງເຫຼົ່ານີ້.
--no-edit
ໃຊ້ຂໍ້ຄວາມສັນຍາທີ່ເລືອກໂດຍບໍ່ໄດ້ເປີດຕົວແກ້ໄຂ. ຕົວຢ່າງ, git commit
--amend --no-edit ແກ້ໄຂຄໍາຫມັ້ນສັນຍາໂດຍບໍ່ມີການປ່ຽນຂໍ້ຄວາມຄໍາຫມັ້ນສັນຍາຂອງຕົນ.
--ປັບປຸງ
ແທນທີ່ປາຍຂອງສາຂາປະຈຸບັນໂດຍການສ້າງຄໍາຫມັ້ນສັນຍາໃຫມ່. ຕົ້ນໄມ້ທີ່ບັນທຶກໄວ້ແມ່ນ
ກະກຽມຕາມປົກກະຕິ (ລວມທັງຜົນກະທົບຂອງຕົວເລືອກ -i ແລະ -o ແລະຊັດເຈນ
pathspec), ແລະຂໍ້ຄວາມຈາກຄໍາຫມັ້ນສັນຍາຕົ້ນສະບັບຖືກນໍາໃຊ້ເປັນຈຸດເລີ່ມຕົ້ນ,
ແທນທີ່ຈະເປັນຂໍ້ຄວາມຫວ່າງເປົ່າ, ໃນເວລາທີ່ບໍ່ມີຂໍ້ຄວາມອື່ນຖືກລະບຸໄວ້ຈາກບັນຊີຄໍາສັ່ງ
ໂດຍຜ່ານທາງເລືອກເຊັ່ນ -m, -F, -c, ແລະອື່ນໆ. ຄໍາຫມັ້ນສັນຍາໃຫມ່ມີພໍ່ແມ່ດຽວກັນແລະຜູ້ຂຽນເປັນ
ປະຈຸບັນ (ທາງເລືອກ --reset-author ສາມາດຕ້ານການນີ້).
ມັນເປັນການທຽບເທົ່າຫຍາບຄາຍສໍາລັບການ:
$ git reset --soft HEAD^
$ ... ເຮັດອັນອື່ນເພື່ອມາກັບຕົ້ນໄມ້ທີ່ຖືກຕ້ອງ ...
$ git commit -c ORIG_HEAD
ແຕ່ສາມາດຖືກໃຊ້ເພື່ອແກ້ໄຂຄໍາຫມັ້ນສັນຍາລວມ.
ທ່ານຄວນເຂົ້າໃຈຜົນສະທ້ອນຂອງການຂຽນຄືນປະຫວັດສາດຖ້າທ່ານແກ້ໄຂຄໍາຫມັ້ນສັນຍານັ້ນ
ໄດ້ຖືກເຜີຍແຜ່ແລ້ວ. (ເບິ່ງ "ການຟື້ນຕົວຈາກ UPSTREAM REBASE" ໃນພາກ git-
ປະຕິເສດ(1).
--no-post-rewrite
ຂ້າມ hook ຫລັງການຂຽນຄືນໃຫມ່.
-i, --ລວມ
ກ່ອນທີ່ຈະເຮັດໃຫ້ຄໍາຫມັ້ນສັນຍາອອກຈາກເນື້ອໃນ staged ມາເຖິງຕອນນັ້ນ, ຂັ້ນຕອນຂອງເນື້ອໃນຂອງເສັ້ນທາງໄດ້
ໃຫ້ຢູ່ໃນເສັ້ນຄໍາສັ່ງເຊັ່ນດຽວກັນ. ນີ້ປົກກະຕິແລ້ວບໍ່ແມ່ນສິ່ງທີ່ທ່ານຕ້ອງການເວັ້ນເສຍແຕ່ວ່າທ່ານເປັນ
ສະຫຼຸບການລວມຕົວທີ່ຂັດແຍ້ງກັນ.
-o, -- ເທົ່ານັ້ນ
ເຮັດສັນຍາໂດຍການເອົາເນື້ອໃນຕົ້ນໄມ້ທີ່ປັບປຸງໃຫມ່ຂອງເສັ້ນທາງທີ່ລະບຸໄວ້ໃນ
ເສັ້ນຄໍາສັ່ງ, ການບໍ່ສົນໃຈເນື້ອຫາໃດໆທີ່ໄດ້ດໍາເນີນການສໍາລັບເສັ້ນທາງອື່ນ.
ນີ້ແມ່ນຮູບແບບການເລີ່ມຕົ້ນຂອງການດໍາເນີນງານຂອງ ໄປ ຄໍາຫມັ້ນສັນຍາ ຖ້າ ຫາກ ວ່າ ເສັ້ນ ທາງ ໃດ ຫນຶ່ງ ແມ່ນ ໄດ້ ຮັບ ການ
ເສັ້ນຄໍາສັ່ງ, ໃນກໍລະນີນີ້ທາງເລືອກນີ້ສາມາດຖືກຍົກເລີກ. ຖ້າຕົວເລືອກນີ້ຖືກລະບຸ
ພ້ອມດ້ວຍ --ປັບປຸງ, ຫຼັງຈາກນັ້ນບໍ່ມີເສັ້ນທາງທີ່ຕ້ອງການທີ່ຈະຖືກກໍານົດ, ເຊິ່ງສາມາດຖືກນໍາໃຊ້ເພື່ອແກ້ໄຂ
ຄໍາຫມັ້ນສັນຍາສຸດທ້າຍໂດຍບໍ່ມີການ committing ການປ່ຽນແປງທີ່ໄດ້ staged ແລ້ວ.
-u[ ], --untracked-files[= ]
ສະແດງໄຟລ໌ທີ່ບໍ່ໄດ້ຕິດຕາມ.
ພາລາມິເຕີຂອງໂຫມດເປັນທາງເລືອກ (ຄ່າເລີ່ມຕົ້ນເປັນ ທັງຫມົດ), ແລະຖືກນໍາໃຊ້ເພື່ອກໍານົດການຈັດການ
ຂອງໄຟລ໌ untracked; ເມື່ອ -u ບໍ່ໄດ້ໃຊ້, ຄ່າເລີ່ມຕົ້ນແມ່ນ ປົກກະຕິ, ie ສະແດງໃຫ້ເຫັນ untracked
ໄຟລ໌ແລະໄດເລກະທໍລີ.
ທາງເລືອກທີ່ເປັນໄປໄດ້ແມ່ນ:
· no - ສະແດງໃຫ້ເຫັນບໍ່ມີໄຟລ໌ untracked
· ປົກກະຕິ - ສະແດງໄຟລ໌ untracked ແລະລາຍການ
· ທັງຫມົດ - ນອກຈາກນີ້ຍັງສະແດງໄຟລ໌ສ່ວນບຸກຄົນໃນໄດເລກະທໍລີ untracked.
ຄ່າເລີ່ມຕົ້ນສາມາດປ່ຽນແປງໄດ້ໂດຍໃຊ້ການຕັ້ງຄ່າ status.showUntrackedFiles
ຕົວແປທີ່ບັນທຶກໄວ້ໃນ git-config(1).
-v, --verbose
ສະແດງຄວາມແຕກຕ່າງທີ່ເປັນເອກະພາບລະຫວ່າງ HEAD commit ແລະສິ່ງທີ່ຈະມຸ່ງຫມັ້ນຢູ່ລຸ່ມສຸດຂອງ
ແມ່ແບບຂໍ້ຄວາມ commit ເພື່ອຊ່ວຍໃຫ້ຜູ້ໃຊ້ອະທິບາຍຄໍາຫມັ້ນສັນຍາໂດຍການເຕືອນສິ່ງທີ່
ການປ່ຽນແປງຄໍາຫມັ້ນສັນຍາມີ. ໃຫ້ສັງເກດວ່າຜົນຜະລິດທີ່ແຕກຕ່າງນີ້ບໍ່ມີສາຍຂອງມັນນໍາຫນ້າ
ກັບ #. ຄວາມແຕກຕ່າງນີ້ຈະບໍ່ເປັນສ່ວນຫນຶ່ງຂອງຂໍ້ຄວາມສັນຍາ.
ຖ້າລະບຸສອງເທື່ອ, ໃຫ້ສະແດງຄວາມແຕກຕ່າງທີ່ເປັນເອກະພາບລະຫວ່າງສິ່ງທີ່ຈະເຮັດ
ແລະໄຟລ໌ worktree, ie ການປ່ຽນແປງ unstaged ກັບໄຟລ໌ຕິດຕາມ.
-q, --ງຽບ
ສະກັດກັ້ນຂໍ້ຄວາມສັງລວມ.
-- ແລ່ນແຫ້ງ
ຢ່າສ້າງຄໍາຫມັ້ນສັນຍາ, ແຕ່ສະແດງໃຫ້ເຫັນບັນຊີລາຍຊື່ຂອງເສັ້ນທາງທີ່ຈະມຸ່ງຫມັ້ນ, ເສັ້ນທາງທີ່ມີ
ການປ່ຽນແປງໃນທ້ອງຖິ່ນທີ່ຈະຖືກປະໄວ້ໂດຍບໍ່ຕັ້ງໃຈແລະເສັ້ນທາງທີ່ບໍ່ໄດ້ຮັບການຕິດຕາມ.
--ສະຖານະ
ລວມເອົາຜົນຜະລິດຂອງ git-ສະຖານະ(1) ໃນແມ່ແບບຂໍ້ຄວາມຄໍາຫມັ້ນສັນຍາໃນເວລາທີ່ການນໍາໃຊ້ an
ບັນນາທິການເພື່ອກະກຽມຂໍ້ຄວາມຄໍາຫມັ້ນສັນຍາ. ຄ່າເລີ່ມຕົ້ນເປັນເປີດ, ແຕ່ສາມາດໃຊ້ເພື່ອລົບລ້າງໄດ້
ການຕັ້ງຄ່າຕົວແປ commit.status.
--ບໍ່ມີສະຖານະ
ບໍ່ລວມເອົາຜົນຜະລິດຂອງ git-ສະຖານະ(1) ໃນແມ່ແບບຂໍ້ຄວາມຄໍາຫມັ້ນສັນຍາໃນເວລາທີ່ການນໍາໃຊ້
ບັນນາທິການເພື່ອກະກຽມຂໍ້ຄວາມສັນຍາເລີ່ມຕົ້ນ.
-S[ ], --gpg-sign[= ]
GPG-ເຊັນສັນຍາ. ການໂຕ້ຖຽງ keyid ແມ່ນທາງເລືອກແລະເປັນຄ່າເລີ່ມຕົ້ນຂອງ committer
ຕົວຕົນ; ຖ້າລະບຸ, ມັນຕ້ອງຕິດຢູ່ກັບທາງເລືອກທີ່ບໍ່ມີຊ່ອງຫວ່າງ.
--no-gpg-sign
ຕົວແປການຕັ້ງຄ່າ Countermand commit.gpgSign ທີ່ຕັ້ງເພື່ອບັງຄັບໃຫ້ແຕ່ລະອັນ.
ຄໍາຫມັ້ນສັນຍາທີ່ຈະໄດ້ຮັບການລົງນາມ.
--
ຢ່າຕີຄວາມຫມາຍການໂຕ້ຖຽງເພີ່ມເຕີມເປັນທາງເລືອກ.
...
ເມື່ອໄຟລ໌ຖືກມອບໃຫ້ຢູ່ໃນເສັ້ນຄໍາສັ່ງ, ຄໍາສັ່ງ commits ເນື້ອໃນຂອງ
ໄຟລ໌ທີ່ມີຊື່, ໂດຍບໍ່ມີການບັນທຶກການປ່ຽນແປງທີ່ດໍາເນີນແລ້ວ. ເນື້ອໃນຂອງໄຟລ໌ເຫຼົ່ານີ້
ແມ່ນຍັງ staged ສໍາລັບຄໍາຫມັ້ນສັນຍາຕໍ່ໄປເທິງຂອງສິ່ງທີ່ໄດ້ staged ກ່ອນ.
DATE ຮູບແບບ
ຕົວແປສະພາບແວດລ້ອມ GIT_AUTHOR_DATE, GIT_COMMITTER_DATE ແລະທາງເລືອກ --date
ສະຫນັບສະຫນູນຮູບແບບວັນທີດັ່ງຕໍ່ໄປນີ້:
Git ຮູບແບບພາຍໃນ
ມັນແມ່ນ , ຢູ່ໃສ ແມ່ນຈໍານວນຂອງ
ວິນາທີນັບຕັ້ງແຕ່ຍຸກ UNIX. ເປັນການຊົດເຊີຍທາງບວກ ຫຼືທາງລົບ
ຈາກ UTC. ຕົວຢ່າງ CET (ເຊິ່ງແມ່ນ 2 ຊົ່ວໂມງກ່ອນ UTC) ແມ່ນ +0200.
RFC 2822
ຮູບແບບອີເມວມາດຕະຖານຕາມທີ່ອະທິບາຍໂດຍ RFC 2822, ຕົວຢ່າງ: Thu, 07 Apr 2005
22:13:13 +0200.
ISO 8601
ເວລາ ແລະວັນທີທີ່ກຳນົດໄວ້ໂດຍມາດຕະຖານ ISO 8601, ຕົວຢ່າງ 2005-04-07T22:13:13. ໄດ້
parser ຍອມຮັບຊ່ອງຫວ່າງແທນຕົວອັກສອນ T ເຊັ່ນກັນ.
ຫມາຍເຫດ
ນອກຈາກນັ້ນ, ສ່ວນວັນທີແມ່ນໄດ້ຮັບການຍອມຮັບໃນຮູບແບບດັ່ງຕໍ່ໄປນີ້: YYYY.MM.DD,
MM/DD/YYYY ແລະ DD.MM.YYYY.
ຕົວຢ່າງ
ໃນເວລາທີ່ບັນທຶກການເຮັດວຽກຂອງທ່ານເອງ, ເນື້ອໃນຂອງໄຟລ໌ດັດແກ້ໃນຕົ້ນໄມ້ເຮັດວຽກຂອງທ່ານແມ່ນ
ເກັບຮັກສາໄວ້ຊົ່ວຄາວກັບພື້ນທີ່ຂັ້ນຕອນທີ່ເອີ້ນວ່າ "ດັດສະນີ" ກັບ ໄປ ເພີ່ມ. ໄຟລ໌ສາມາດເປັນ
reverted ກັບຄືນໄປບ່ອນ, ພຽງແຕ່ຢູ່ໃນດັດຊະນີແຕ່ບໍ່ແມ່ນຢູ່ໃນຕົ້ນໄມ້ເຮັດວຽກ, ກັບຄໍາຫມັ້ນສັນຍາທີ່ຜ່ານມາ
ດ້ວຍ git reset HEAD -- , ເຊິ່ງປະສິດທິຜົນກັບຄືນມາ ໄປ ເພີ່ມ ແລະປ້ອງກັນການປ່ຽນແປງ
ກັບໄຟລ໌ນີ້ຈາກການເຂົ້າຮ່ວມໃນຄໍາຫມັ້ນສັນຍາຕໍ່ໄປ. ຫຼັງຈາກການສ້າງລັດເປັນ
ຄໍາຫມັ້ນສັນຍາເພີ່ມຂຶ້ນດ້ວຍຄໍາສັ່ງເຫຼົ່ານີ້, git commit (ໂດຍບໍ່ມີພາລາມິເຕີຊື່ເສັ້ນທາງ)
ຖືກນໍາໃຊ້ເພື່ອບັນທຶກສິ່ງທີ່ໄດ້ດໍາເນີນມາເຖິງຕອນນັ້ນ. ນີ້ແມ່ນຮູບແບບພື້ນຖານທີ່ສຸດຂອງຄໍາສັ່ງ.
ຕົວຢ່າງ:
$ ແກ້ໄຂ hello.c
$ git rm goodbye.c
$ git ເພີ່ມ hello.c
$ git ຄໍາຫມັ້ນສັນຍາ
ແທນທີ່ຈະເປັນໄຟລ໌ staging ຫຼັງຈາກການປ່ຽນແປງແຕ່ລະຄົນ, ທ່ານສາມາດບອກ git ຄໍາຫມັ້ນສັນຍາທີ່ຈະສັງເກດເຫັນ
ການປ່ຽນແປງໄຟລ໌ທີ່ມີເນື້ອໃນແມ່ນຕິດຕາມໃນຕົ້ນໄມ້ທີ່ເຮັດວຽກຂອງທ່ານແລະເຮັດໄດ້
git add ແລະ git rm ທີ່ສອດຄ້ອງກັນສໍາລັບທ່ານ. ນັ້ນແມ່ນ, ຕົວຢ່າງນີ້ເຮັດເຊັ່ນດຽວກັນກັບ
ຕົວຢ່າງກ່ອນຫນ້ານີ້ຖ້າບໍ່ມີການປ່ຽນແປງອື່ນໃນຕົ້ນໄມ້ທີ່ເຮັດວຽກຂອງເຈົ້າ:
$ ແກ້ໄຂ hello.c
$ rm goodbye.c
$ git commit -a
ຄໍາສັ່ງ git commit -a ທໍາອິດເບິ່ງຕົ້ນໄມ້ທີ່ເຮັດວຽກຂອງເຈົ້າ, ສັງເກດເຫັນວ່າທ່ານໄດ້ດັດແປງ
hello.c ແລະເອົາ goodbye.c ອອກ, ແລະປະຕິບັດການເພີ່ມ git ແລະ git rm ທີ່ຈໍາເປັນສໍາລັບທ່ານ.
ຫຼັງຈາກການປ່ຽນແປງຂັ້ນຕອນຂອງໄຟລ໌ຈໍານວນຫຼາຍ, ທ່ານສາມາດແກ້ໄຂຄໍາສັ່ງການປ່ຽນແປງໄດ້ຖືກບັນທຶກໄວ້ໃນ,
ໂດຍການໃຫ້ຊື່ເສັ້ນທາງໃຫ້ກັບ git commit. ເມື່ອຊື່ເສັ້ນທາງຖືກມອບໃຫ້, ຄໍາສັ່ງເຮັດໃຫ້ຄໍາຫມັ້ນສັນຍາ
ທີ່ບັນທຶກພຽງແຕ່ການປ່ຽນແປງທີ່ເຮັດກັບເສັ້ນທາງທີ່ມີຊື່:
$ ແກ້ໄຂ hello.c hello.h
$ git ເພີ່ມ hello.c hello.h
$ ແກ້ໄຂ Makefile
$ git commit Makefile
ນີ້ເຮັດໃຫ້ຄໍາຫມັ້ນສັນຍາທີ່ບັນທຶກການດັດແປງ Makefile. ການປ່ຽນແປງຂັ້ນຕອນສໍາລັບ
hello.c ແລະ hello.h ບໍ່ໄດ້ລວມຢູ່ໃນຄໍາຫມັ້ນສັນຍາຜົນໄດ້ຮັບ. ຢ່າງໃດກໍຕາມ, ການປ່ຽນແປງຂອງພວກເຂົາແມ່ນ
ບໍ່ໄດ້ສູນເສຍ — ພວກເຂົາເຈົ້າຍັງໄດ້ຮັບການ staged ແລະພຽງແຕ່ໄດ້ກັບຄືນໄປບ່ອນ. ຫຼັງຈາກລໍາດັບຂ້າງເທິງ, ຖ້າທ່ານ
ເຮັດ:
$ git ຄໍາຫມັ້ນສັນຍາ
ສັນຍາທີສອງນີ້ຈະບັນທຶກການປ່ຽນແປງໄປຫາ hello.c ແລະ hello.h ຕາມທີ່ຄາດໄວ້.
ຫຼັງຈາກການລວມຕົວ (ລິເລີ່ມໂດຍ ໄປ ລວມ or ໄປ ດຶງ) ຢຸດເຊົາຍ້ອນການຂັດແຍ້ງ, ສະອາດ
ເສັ້ນທາງທີ່ຖືກລວມເຂົ້າກັນແມ່ນໄດ້ຖືກວາງແຜນໄວ້ແລ້ວທີ່ຈະມຸ່ງຫມັ້ນສໍາລັບທ່ານ, ແລະເສັ້ນທາງທີ່ຂັດແຍ້ງກັນ
ປະໄວ້ຢູ່ໃນສະຖານະບໍ່ໄດ້ລວມເຂົ້າກັນ. ກ່ອນອື່ນ ໝົດ ເຈົ້າຕ້ອງກວດເບິ່ງວ່າເສັ້ນທາງໃດທີ່ຂັດແຍ້ງກັນ ໄປ
ສະຖານະພາບ ແລະ ຫຼັງ ຈາກ ການ ແກ້ ໄຂ ໃຫ້ ເຂົາ ເຈົ້າ ຄູ່ ມື ໃນ ຕົ້ນ ໄມ້ ທີ່ ເຮັດ ວຽກ ຂອງ ທ່ານ, ທ່ານ ຈະ ຂັ້ນ ຕອນ ຂອງ ຜົນ ໄດ້ ຮັບ
ປົກກະຕິກັບ ໄປ ເພີ່ມ:
$ git ສະຖານະພາບ | grep ບໍ່ລວມເຂົ້າກັນ
ບໍ່ໄດ້ລວມເຂົ້າກັນ: hello.c
$ ແກ້ໄຂ hello.c
$ git ເພີ່ມ hello.c
ຫຼັງຈາກການແກ້ໄຂຂໍ້ຂັດແຍ່ງແລະຈັດລໍາດັບຜົນໄດ້ຮັບ, git ls-files -u ຈະຢຸດເຊົາການກ່າວເຖິງ
ເສັ້ນທາງທີ່ຂັດແຍ້ງກັນ. ເມື່ອທ່ານເຮັດແລ້ວ, ດໍາເນີນການ git commit ເພື່ອສຸດທ້າຍບັນທຶກການລວມ:
$ git ຄໍາຫມັ້ນສັນຍາ
ເຊັ່ນດຽວກັນກັບກໍລະນີທີ່ຈະບັນທຶກການປ່ຽນແປງຂອງທ່ານເອງ, ທ່ານສາມາດນໍາໃຊ້ -a ທາງເລືອກທີ່ຈະບັນທຶກການພິມ. ຫນຶ່ງ
ຄວາມແຕກຕ່າງແມ່ນວ່າໃນລະຫວ່າງການແກ້ໄຂການລວມກັນ, ທ່ານບໍ່ສາມາດໃຊ້ git commit ກັບ pathnames
ການປ່ຽນແປງຄໍາສັ່ງການປ່ຽນແປງແມ່ນຄໍາຫມັ້ນສັນຍາ, ເນື່ອງຈາກວ່າການລວມຄວນໄດ້ຮັບການບັນທຶກເປັນ
ຄໍາຫມັ້ນສັນຍາດຽວ. ໃນຄວາມເປັນຈິງ, ຄໍາສັ່ງປະຕິເສດທີ່ຈະດໍາເນີນການໃນເວລາທີ່ໃຫ້ຊື່ເສັ້ນທາງ (ແຕ່ເບິ່ງ -i
ທາງເລືອກ).
ການສົນທະນາ
ເຖິງແມ່ນວ່າບໍ່ຈໍາເປັນຕ້ອງ, ມັນເປັນຄວາມຄິດທີ່ດີທີ່ຈະເລີ່ມຕົ້ນຂໍ້ຄວາມຄໍາຫມັ້ນສັນຍາທີ່ມີສັ້ນດຽວ
(ໜ້ອຍກວ່າ 50 ຕົວອັກສອນ) ເສັ້ນສະຫຼຸບການປ່ຽນແປງ, ຕິດຕາມດ້ວຍເສັ້ນເປົ່າ ແລະ ຈາກນັ້ນ a
ລາຍລະອຽດເພີ່ມເຕີມ. ຂໍ້ຄວາມເຖິງແຖວທໍາອິດທີ່ຫວ່າງຢູ່ໃນຂໍ້ຄວາມຄໍາຫມັ້ນສັນຍາແມ່ນ
ຖືກປະຕິບັດເປັນຫົວຂໍ້ຄໍາຫມັ້ນສັນຍາ, ແລະຫົວຂໍ້ນັ້ນຖືກນໍາໃຊ້ໃນທົ່ວ Git. ຍົກຕົວຢ່າງ, git-
format-patch(1) turns ຄໍາຫມັ້ນສັນຍາເປັນອີເມລ໌, ແລະມັນນໍາໃຊ້ຫົວຂໍ້ກ່ຽວກັບເສັ້ນຫົວຂໍ້ແລະ
ສ່ວນທີ່ເຫຼືອຂອງຄໍາຫມັ້ນສັນຍາຢູ່ໃນຮ່າງກາຍ.
Git ແມ່ນການເຂົ້າລະຫັດຕົວລະຄອນທີ່ບໍ່ເຊື່ອໃນຂອບເຂດໃດນຶ່ງ.
· ເນື້ອໃນຂອງວັດຖຸ blob ແມ່ນລໍາດັບຂອງ bytes ທີ່ບໍ່ໄດ້ແປ. ບໍ່ມີ
ການແປພາສາເຂົ້າລະຫັດຢູ່ໃນລະດັບຫຼັກ.
· ຊື່ເສັ້ນທາງຖືກເຂົ້າລະຫັດໃນຮູບແບບ UTF-8 normalization C. ນີ້ໃຊ້ກັບວັດຖຸຕົ້ນໄມ້,
ໄຟລ໌ດັດສະນີ, ຊື່ອ້າງອີງ, ເຊັ່ນດຽວກັນກັບຊື່ເສັ້ນທາງໃນການໂຕ້ຖຽງແຖວຄໍາສັ່ງ,
ຕົວແປສະພາບແວດລ້ອມ ແລະໄຟລ໌ config (.git/config (ເບິ່ງ git-config(1)), gitignore(5)
gitattributes(5) ແລະ gitmodules(5)).
ໃຫ້ສັງເກດວ່າ Git ຢູ່ໃນລະດັບຫຼັກປະຕິບັດຊື່ເສັ້ນທາງພຽງແຕ່ເປັນລໍາດັບຂອງທີ່ບໍ່ແມ່ນ NUL
bytes, ບໍ່ມີຊື່ເສັ້ນທາງການເຂົ້າລະຫັດການແປງ (ຍົກເວັ້ນໃນ Mac ແລະ Windows).
ດັ່ງນັ້ນ, ການນໍາໃຊ້ຊື່ເສັ້ນທາງທີ່ບໍ່ແມ່ນ ASCII ສ່ວນໃຫຍ່ຈະເຮັດວຽກແມ້ແຕ່ຢູ່ໃນເວທີແລະໄຟລ໌
ລະບົບທີ່ໃຊ້ການເຂົ້າລະຫັດ ASCII ແບບເກົ່າແກ່. ຢ່າງໃດກໍຕາມ, repositories ສ້າງຂຶ້ນໃນ
ລະບົບດັ່ງກ່າວຈະບໍ່ເຮັດວຽກຢ່າງຖືກຕ້ອງໃນລະບົບທີ່ໃຊ້ UTF-8 (ເຊັ່ນ Linux, Mac, Windows)
ແລະໃນທາງກັບກັນ. ນອກຈາກນັ້ນ, ເຄື່ອງມືທີ່ອີງໃສ່ Git ຫຼາຍພຽງແຕ່ສົມມຸດຊື່ເສັ້ນທາງທີ່ຈະເປັນ
UTF-8 ແລະຈະບໍ່ສະແດງການເຂົ້າລະຫັດອື່ນຢ່າງຖືກຕ້ອງ.
· ຂໍ້ຄວາມບັນທຶກຄໍາຫມັ້ນສັນຍາໂດຍປົກກະຕິແມ່ນເຂົ້າລະຫັດໃນ UTF-8, ແຕ່ການເຂົ້າລະຫັດ ASCII ຂະຫຍາຍອື່ນໆ
ຍັງໄດ້ຮັບການສະຫນັບສະຫນູນ. ນີ້ປະກອບມີ ISO-8859-x, CP125x ແລະອື່ນໆຈໍານວນຫຼາຍ, ແຕ່ ບໍ່
UTF-16/32, EBCDIC ແລະ CJK ການເຂົ້າລະຫັດຫຼາຍໄບຕ໌ (GBK, Shift-JIS, Big5, EUC-x, CP9xx
ແລະອື່ນໆ).
ເຖິງແມ່ນວ່າພວກເຮົາຊຸກຍູ້ໃຫ້ຂໍ້ຄວາມບັນທຶກຄໍາຫມັ້ນສັນຍາຖືກເຂົ້າລະຫັດໃນ UTF-8, ທັງຫຼັກແລະ
Git Porcelain ຖືກອອກແບບມາບໍ່ໃຫ້ບັງຄັບ UTF-8 ໃນໂຄງການ. ຖ້າຜູ້ເຂົ້າຮ່ວມທັງໝົດຂອງ ກ
ໂຄງການໂດຍສະເພາະພົບວ່າມັນສະດວກກວ່າທີ່ຈະໃຊ້ການເຂົ້າລະຫັດແບບເກົ່າ, Git ບໍ່ໄດ້ຫ້າມ
ມັນ. ຢ່າງໃດກໍຕາມ, ມີບາງສິ່ງທີ່ຕ້ອງຢູ່ໃນໃຈ.
1. ໄປ ຄໍາຫມັ້ນສັນຍາ ແລະ ໄປ commit-ຕົ້ນໄມ້ ອອກຄໍາເຕືອນຖ້າຫາກວ່າຂໍ້ຄວາມບັນທຶກທີ່ມອບໃຫ້ມັນ
ບໍ່ຄືກັບສະຕຣິງ UTF-8 ທີ່ຖືກຕ້ອງ, ເວັ້ນເສຍແຕ່ວ່າທ່ານເວົ້າຢ່າງຈະແຈ້ງວ່າໂຄງການຂອງທ່ານໃຊ້ a
ການເຂົ້າລະຫັດເດີມ. ວິທີການເວົ້ານີ້ແມ່ນມີ i18n.commitencoding ໃນ .git/config
ໄຟລ໌ເຊັ່ນນີ້:
[i18n]
commitencoding = ISO-8859-1
ສັນຍາວັດຖຸທີ່ສ້າງຂຶ້ນດ້ວຍການຕັ້ງຄ່າຂ້າງເທິງບັນທຶກມູນຄ່າຂອງ i18n.commitencoding
ໃນຫົວການເຂົ້າລະຫັດຂອງມັນ. ນີ້ແມ່ນເພື່ອຊ່ວຍຄົນອື່ນທີ່ເບິ່ງພວກເຂົາຕໍ່ມາ. ຂາດ
ສ່ວນຫົວນີ້ໝາຍຄວາມວ່າຂໍ້ຄວາມບັນທຶກການກະທຳຈະຖືກເຂົ້າລະຫັດໃນ UTF-8.
2. ໄປ log, ໄປ ສະແດງໃຫ້ເຫັນ, ໄປ ໂທດ ແລະຫມູ່ເພື່ອນເບິ່ງຢູ່ໃນຫົວການເຂົ້າລະຫັດຂອງຄໍາຫມັ້ນສັນຍາ
ວັດຖຸ, ແລະພະຍາຍາມ re-code ຂໍ້ຄວາມບັນທຶກເຂົ້າໄປໃນ UTF-8 ເວັ້ນເສຍແຕ່ໄດ້ລະບຸໄວ້ເປັນຢ່າງອື່ນ. ເຈົ້າ
ສາມາດລະບຸການເຂົ້າລະຫັດຜົນໄດ້ຮັບທີ່ຕ້ອງການດ້ວຍ i18n.logoutputencoding ໃນ .git/config
ໄຟລ໌ເຊັ່ນນີ້:
[i18n]
logoutputencoding = ISO-8859-1
ຖ້າທ່ານບໍ່ມີຕົວແປການຕັ້ງຄ່ານີ້, ມູນຄ່າຂອງ i18n.commitencoding ແມ່ນ
ໃຊ້ແທນ.
ຈົ່ງຈື່ໄວ້ວ່າພວກເຮົາເຈດຕະນາເລືອກທີ່ຈະບໍ່ລະຫັດຂໍ້ຄວາມບັນທຶກຄໍາຫມັ້ນສັນຍາຄືນໃຫມ່ເມື່ອຄໍາຫມັ້ນສັນຍາແມ່ນ
ສ້າງຂຶ້ນເພື່ອບັງຄັບ UTF-8 ໃນລະດັບວັດຖຸຄໍາຫມັ້ນສັນຍາ, ເນື່ອງຈາກວ່າ re-coding ກັບ UTF-8 ບໍ່ແມ່ນ
ຈໍາເປັນຕ້ອງມີການດໍາເນີນການປີ້ນກັບກັນ.
ENVIRONMENT ແລະ CONFIGURATION ຄວາມຮັບຜິດຊອບ
ຕົວແກ້ໄຂທີ່ໃຊ້ເພື່ອແກ້ໄຂຂໍ້ຄວາມບັນທຶກການກະທຳຈະຖືກເລືອກຈາກ GIT_EDITOR
ຕົວແປສະພາບແວດລ້ອມ, ຕົວແປການຕັ້ງຄ່າ core.editor, ສະພາບແວດລ້ອມ VISUAL
ຕົວແປ, ຫຼືຕົວແປສະພາບແວດລ້ອມ EDITOR (ຕາມລໍາດັບນັ້ນ). ເບິ່ງ git-var(1) ສໍາລັບລາຍລະອຽດ.
ກອກ
ຄໍາສັ່ງນີ້ສາມາດດໍາເນີນການ commit-msg, ກະກຽມ-commit-msg, pre-commit, ແລະ hooks ຫລັງຄໍາຫມັ້ນສັນຍາ.
ເບິ່ງ Githooks(5) ສໍາລັບຂໍ້ມູນເພີ່ມເຕີມ.
ໃຊ້ git-commit ອອນໄລນ໌ໂດຍໃຊ້ບໍລິການ onworks.net
