git-commit - ออนไลน์ในคลาวด์

โครงการ:

ชื่อ

git-commit - บันทึกการเปลี่ยนแปลงที่เก็บ

เรื่องย่อ

คอมไพล์ ผูกมัด [-a | --โต้ตอบ | --patch] [-s] [-v] [-u ] [--แก้ไข]
[--แห้ง-วิ่ง] [(-c | -C | --fixup | --squash) ]
[-NS | -NS ] [--รีเซ็ตผู้เขียน] [--allow-empty]
[--allow-empty-message] [--no-verify] [-e] [--author= ]
[--วันที่= ] [--ล้าง= ] [--[ไม่มีสถานะ]
[-ฉัน | -o] [-ส[ ]] [--] [ ...]

DESCRIPTION

เก็บเนื้อหาปัจจุบันของดัชนีในการคอมมิตใหม่พร้อมกับข้อความบันทึกจาก
ผู้ใช้อธิบายการเปลี่ยนแปลง

เนื้อหาที่จะเพิ่มสามารถระบุได้หลายวิธี:

1. โดยใช้ คอมไพล์ เพิ่ม เพื่อ "เพิ่ม" แบบค่อยเป็นค่อยไปการเปลี่ยนแปลงดัชนีก่อนที่จะใช้ ผูกมัด
คำสั่ง (หมายเหตุ: แม้แต่ไฟล์ที่แก้ไขจะต้อง "เพิ่ม");

2. โดยใช้ คอมไพล์ rm เพื่อลบไฟล์ออกจากแผนผังการทำงานและดัชนีอีกครั้งก่อน
โดยใช้โปรแกรม ผูกมัด สั่งการ;

3. โดยแสดงรายการไฟล์เป็นอาร์กิวเมนต์ของ ผูกมัด คำสั่งซึ่งในกรณีนี้จะกระทำการ
ละเว้นการเปลี่ยนแปลงที่แสดงในดัชนี และบันทึกเนื้อหาปัจจุบันของ . แทน
ไฟล์ที่อยู่ในรายการ (ซึ่ง Git ต้องรู้จักอยู่แล้ว);

4. โดยใช้สวิตช์ -a กับ ผูกมัด คำสั่งให้ "เพิ่ม" โดยอัตโนมัติเปลี่ยนจากทั้งหมด
ไฟล์ที่รู้จัก (เช่น ไฟล์ทั้งหมดที่อยู่ในดัชนีแล้ว) และโดยอัตโนมัติ
ไฟล์ "rm" ในดัชนีที่ถูกลบออกจากแผนผังการทำงานแล้วดำเนินการ
การกระทำจริง;

5. โดยใช้ --interactive หรือ --patch สวิตช์กับ ผูกมัด สั่งให้ตัดสินใจ
โดยไฟล์หรือไฟล์จำนวนมากควรเป็นส่วนหนึ่งของการคอมมิตก่อนที่จะเสร็จสิ้น
การดำเนินการ. ดูส่วน "โหมดโต้ตอบ" ของ คอมไพล์เพิ่ม(1) เพื่อเรียนรู้วิธีการใช้งาน
โหมดเหล่านี้

ตัวเลือก --dry-run สามารถใช้เพื่อรับข้อมูลสรุปของสิ่งที่รวมโดย
ด้านบนสำหรับการคอมมิตครั้งต่อไปโดยให้พารามิเตอร์ชุดเดียวกัน (ตัวเลือกและเส้นทาง)

หากคุณกระทำการแล้วพบข้อผิดพลาดทันทีหลังจากนั้น คุณสามารถกู้คืนจาก
มันด้วย คอมไพล์ ตั้งใหม่.

OPTIONS

-a, --ทั้งหมด
บอกคำสั่งให้สเตจไฟล์ที่แก้ไขและลบโดยอัตโนมัติ แต่
ไฟล์ใหม่ที่คุณยังไม่ได้บอกกับ Git จะไม่ได้รับผลกระทบ

-p, --แพทช์
ใช้อินเทอร์เฟซการเลือกแพตช์แบบโต้ตอบเพื่อเลือกการเปลี่ยนแปลงที่จะคอมมิต ดู
คอมไพล์เพิ่ม(1) สำหรับรายละเอียด

-ค , --reuse-ข้อความ=
นำอ็อบเจ็กต์การคอมมิตที่มีอยู่มาใช้ และนำข้อความบันทึกและการเขียนกลับมาใช้ใหม่
ข้อมูล (รวมถึงการประทับเวลา) เมื่อสร้างการคอมมิต

-ค , --reedit-ข้อความ=
Like -C, แต่ด้วย -c ตัวแก้ไขถูกเรียกใช้เพื่อให้ผู้ใช้สามารถแก้ไข
คอมมิตข้อความ

--fixup=
สร้างข้อความยืนยันเพื่อใช้กับ rebase --autosquash ข้อความยืนยันจะ
เป็นหัวเรื่องจากคอมมิตที่ระบุโดยมีคำนำหน้า "fixup!" ดู คอมไพล์-
รีเบส(1) สำหรับรายละเอียด

--สควอช=
สร้างข้อความยืนยันเพื่อใช้กับ rebase --autosquash ข้อความยืนยัน
หัวเรื่องนำมาจากคอมมิตที่ระบุโดยมีคำนำหน้า "สควอช!" เป็นไปได้
ใช้กับตัวเลือกข้อความยืนยันเพิ่มเติม (-m/-c/-C/-F) ดู คอมไพล์รีเบส(1) สำหรับ
รายละเอียด

--รีเซ็ตผู้เขียน
เมื่อใช้กับ -C/-c/--amend options หรือเมื่อคอมมิตหลังจาก aa ขัดแย้ง
cherry-pick ประกาศว่าผลงานของการกระทำที่เป็นผลลัพธ์ตอนนี้เป็นของ
ผู้มอบอำนาจ นอกจากนี้ยังต่ออายุการประทับเวลาของผู้เขียน

--สั้น
เมื่อดำเนินการแบบแห้ง ให้ผลลัพธ์ในรูปแบบสั้น ดู git-สถานะ(1) สำหรับ
รายละเอียด. หมายถึง --dry-run

--สาขา
แสดงข้อมูลสาขาและข้อมูลการติดตามแม้ในรูปแบบสั้น

--พอร์ซเลน
เมื่อทำแห้งรัน ให้ผลลัพธ์ในรูปแบบพอร์ซเลนพร้อม ดู git-สถานะ(1)
เพื่อดูรายละเอียด หมายถึง --dry-run

--ยาว
เมื่อทำแบบแห้ง ให้ผลลัพธ์ในรูปแบบยาว หมายถึง --dry-run

-z, --null
เมื่อแสดงเอาต์พุตสถานะสั้นหรือพอร์ซเลน ยุติรายการในเอาต์พุตสถานะ
ด้วย NUL แทนที่จะเป็น LF หากไม่มีการกำหนดรูปแบบ แสดงว่า --porcelain รูปแบบเอาต์พุต

-NS , --file=
รับข้อความยืนยันจากไฟล์ที่กำหนด ใช้ - เพื่ออ่านข้อความจาก
อินพุตมาตรฐาน

--ผู้เขียน=
แทนที่ผู้เขียนคอมมิต ระบุผู้เขียนอย่างชัดเจนโดยใช้มาตรฐาน AU Thor
<[ป้องกันอีเมล]> รูปแบบ มิฉะนั้น ถือว่าเป็นแบบแผนและถูกใช้
เพื่อค้นหาการคอมมิตที่มีอยู่โดยผู้เขียนคนนั้น (เช่น rev-list --all -i
--ผู้เขียน= ); ผู้เขียนคอมมิตจะถูกคัดลอกจากคอมมิตแรกที่พบ

--วันที่=
แทนที่วันที่ผู้เขียนที่ใช้ในการคอมมิต

-NS , --ข้อความ=
ใช้ที่ให้มา เป็นข้อความยืนยัน หากมีตัวเลือก -m หลายตัว แสดงว่า
ค่าจะถูกต่อกันเป็นย่อหน้าที่แยกจากกัน

-NS , --template=
เมื่อแก้ไขข้อความยืนยัน ให้เริ่มเอดิเตอร์ด้วยเนื้อหาในไฟล์ที่กำหนด
มักใช้ตัวแปรการกำหนดค่า commit.template เพื่อให้ตัวเลือกนี้
โดยปริยายต่อคำสั่ง กลไกนี้ใช้ได้กับโครงการที่ต้องการนำทาง
ผู้เข้าร่วมพร้อมคำแนะนำว่าจะเขียนอะไรในข้อความในลำดับใด ถ้า
ผู้ใช้ออกจากเอดิเตอร์โดยไม่แก้ไขข้อความ การคอมมิตจะถูกยกเลิก นี้ไม่มี
มีผลเมื่อได้รับข้อความด้วยวิธีอื่น เช่น ด้วยตัวเลือก -m หรือ -F

-s, --signoff
เพิ่มบรรทัด Signed-off-by โดยคอมมิตเตอร์ที่ส่วนท้ายของข้อความบันทึกการคอมมิต NS
ความหมายของ signoff ขึ้นอยู่กับโครงการ แต่โดยทั่วไปแล้วจะรับรองว่าผู้มอบอำนาจ
มีสิทธิ์ส่งงานนี้ภายใต้ใบอนุญาตเดียวกันและตกลงกับผู้พัฒนา
หนังสือรับรองแหล่งกำเนิดสินค้า (ดู http://developercertificate.org/ สำหรับข้อมูลเพิ่มเติม).

-n, --ไม่ยืนยัน
อ็อพชันนี้ข้ามตะขอ pre-commit และ commit-msg ดูสิ่งนี้ด้วย gitooks(5)

--allow-ว่างเปล่า
โดยปกติการบันทึกการคอมมิตที่มีทรีเดียวกันกับการคอมมิตพาเรนต์เพียงอย่างเดียวคือ a
ผิดพลาดและคำสั่งป้องกันไม่ให้คุณกระทำการดังกล่าว ตัวเลือกนี้ข้าม
ความปลอดภัย และเป็นหลักสำหรับการใช้งานโดยสคริปต์อินเทอร์เฟซ SCM ต่างประเทศ

--allow-empty-ข้อความ
เช่นเดียวกับ --allow-empty คำสั่งนี้มีไว้สำหรับใช้โดยสคริปต์อินเทอร์เฟซ SCM ต่างประเทศเป็นหลัก
ช่วยให้คุณสร้างการคอมมิตด้วยข้อความยืนยันที่ว่างเปล่าโดยไม่ต้องใช้ระบบประปา
คำสั่งเช่น git-กระทำ-tree(1)

--cleanup=
ตัวเลือกนี้กำหนดวิธีการล้างข้อความยืนยันที่ให้มาก่อน
มุ่งมั่น NS สามารถเป็นแถบ ช่องว่าง ต่อคำ กรรไกร หรือค่าเริ่มต้น

เพิก
ตัดบรรทัดว่างที่นำหน้าและต่อท้าย ช่องว่างต่อท้าย คำอธิบาย และ
ยุบบรรทัดว่างที่ต่อเนื่องกัน

ช่องว่าง
เช่นเดียวกับแถบยกเว้น #commentary จะไม่ถูกลบ

คำต่อคำ
ห้ามเปลี่ยนข้อความเด็ดขาด

กรรไกร
เหมือนกับช่องว่าง ยกเว้นว่าทุกอย่างจาก (และรวมถึง) บรรทัด "#
------------------------ >8 ------------------------ " จะถูกตัดทอนหากข้อความ
คือต้องแก้ไข "#" สามารถปรับแต่งได้ด้วย core.commentChar

ผิดนัด
เช่นเดียวกับแถบหากต้องแก้ไขข้อความ มิฉะนั้นช่องว่าง

ค่าเริ่มต้นสามารถเปลี่ยนได้โดย คอมมิชชัน.cleanup ตัวแปรการกำหนดค่า (ดู คอมไพล์-
การตั้งค่า(พ.ศ. 1)).

-e, --edit
ข้อความที่นำมาจากไฟล์ด้วย -F, บรรทัดคำสั่งด้วย -m และจากอ็อบเจกต์คอมมิต with
-C มักใช้เป็นข้อความบันทึกการคอมมิตที่ไม่ได้แก้ไข ตัวเลือกนี้ช่วยให้คุณทำต่อไปได้
แก้ไขข้อความที่นำมาจากแหล่งที่มาเหล่านี้

--ไม่มีการแก้ไข
ใช้ข้อความยืนยันที่เลือกโดยไม่เรียกใช้เอดิเตอร์ ตัวอย่างเช่น git commit
--amend --no-edit แก้ไขการคอมมิตโดยไม่เปลี่ยนข้อความยืนยัน

--แก้ไข
แทนที่ส่วนปลายของสาขาปัจจุบันด้วยการสร้างคอมมิตใหม่ ต้นไม้ที่บันทึกไว้คือ
เตรียมไว้ตามปกติ (รวมถึงผลกระทบของตัวเลือก -i และ -o และอย่างชัดเจน
pathspec) และข้อความจากคอมมิตดั้งเดิมถูกใช้เป็นจุดเริ่มต้น
แทนที่จะเป็นข้อความว่าง เมื่อไม่ได้ระบุข้อความอื่นจากบรรทัดคำสั่ง
ผ่านตัวเลือกต่างๆ เช่น -m, -F, -c เป็นต้น การคอมมิตใหม่มีพาเรนต์และผู้แต่งคนเดียวกันเป็น
อันปัจจุบัน (ตัวเลือก --reset-author สามารถตอบโต้ได้)

เทียบเท่าอย่างคร่าวๆ สำหรับ:

$ รีเซ็ต git --soft HEAD^
$ ... ทำอย่างอื่นเพื่อให้ได้ต้นไม้ที่ถูกต้อง ...
$ git คอมมิท -c ORIG_HEAD

แต่สามารถใช้เพื่อแก้ไขการรวมคอมมิตได้

คุณควรเข้าใจความหมายของการเขียนประวัติศาสตร์ใหม่หากคุณแก้ไขข้อผูกมัดนั้น
ได้รับการเผยแพร่แล้ว (ดูส่วน "การกู้คืนจากแหล่งรีเบสของ UPSTREAM" ใน คอมไพล์-
รีเบส(1).)

--no-โพสต์-rewrite
ข้ามเบ็ดหลังการเขียนซ้ำ

-i, --รวม
ก่อนสร้างคอมมิชชันจากเนื้อหาที่จัดฉากให้สเตจเนื้อหาของเส้นทาง
กำหนดไว้ในบรรทัดคำสั่งเช่นกัน นี่ไม่ใช่สิ่งที่คุณต้องการเว้นแต่คุณจะเป็น
สรุปการรวมที่ขัดแย้งกัน

-o, --เท่านั้น
ทำการคอมมิตโดยใช้เนื้อหาแผนผังการทำงานที่อัปเดตของพาธที่ระบุใน
บรรทัดคำสั่ง โดยไม่คำนึงถึงเนื้อหาใด ๆ ที่ได้รับการจัดฉากสำหรับเส้นทางอื่น
นี่คือโหมดเริ่มต้นของการทำงานของ คอมไพล์ ผูกมัด หากมีการกำหนดเส้นทางใด ๆ บน
บรรทัดคำสั่ง ซึ่งในกรณีนี้สามารถละเว้นตัวเลือกนี้ได้ หากระบุตัวเลือกนี้
พร้อมด้วย --แก้ไขไม่จำเป็นต้องระบุพาธซึ่งสามารถใช้แก้ไขได้
การคอมมิทครั้งสุดท้ายโดยไม่มีการคอมมิตการเปลี่ยนแปลงที่ได้จัดเตรียมไว้แล้ว

-ยู[ ], --untracked-ไฟล์[= ]
แสดงไฟล์ที่ไม่ได้ติดตาม

พารามิเตอร์โหมดเป็นทางเลือก (ค่าเริ่มต้นเป็น ทั้งหมด) และใช้เพื่อระบุการจัดการ
ของไฟล์ที่ไม่ได้ติดตาม; เมื่อไม่ใช้ -u ค่าดีฟอลต์คือ ปกติ, คือแสดง untracked
ไฟล์และไดเร็กทอรี

ตัวเลือกที่เป็นไปได้คือ:

· ไม่ - ไม่แสดงไฟล์ที่ไม่ได้ติดตาม

· ปกติ - แสดงไฟล์และไดเรกทอรีที่ไม่ได้ติดตาม

· ทั้งหมด - ยังแสดงไฟล์แต่ละไฟล์ในไดเร็กทอรีที่ไม่ได้ติดตาม

ค่าเริ่มต้นสามารถเปลี่ยนแปลงได้โดยใช้ status.showUntrackedFiles configuration
เอกสารตัวแปรใน git-config.php(1)

-v, --เวอร์โบส
แสดงความแตกต่างแบบครบวงจรระหว่างการส่ง HEAD และสิ่งที่จะคอมมิตที่ด้านล่างของ
เทมเพลตข้อความยืนยันเพื่อช่วยให้ผู้ใช้อธิบายการคอมมิตโดยเตือนว่าอะไร
เปลี่ยนการกระทำที่มี โปรดทราบว่าเอาต์พุต diff นี้ไม่มีบรรทัดนำหน้า
กับ #. ส่วนต่างนี้จะไม่เป็นส่วนหนึ่งของข้อความยืนยัน

หากระบุไว้สองครั้ง ให้แสดงส่วนต่างแบบรวมเป็นหนึ่งระหว่างสิ่งที่จะถูกคอมมิตเพิ่มเติม
และไฟล์เวิร์กทรี เช่น การเปลี่ยนแปลงที่ไม่ได้จัดฉากในไฟล์ที่ติดตาม

-q, --เงียบ
ระงับข้อความสรุปการคอมมิต

--ดรายรัน
อย่าสร้างการคอมมิต แต่แสดงรายการเส้นทางที่จะคอมมิต เส้นทางด้วย
การเปลี่ยนแปลงในเครื่องที่จะไม่ถูกผูกมัดและเส้นทางที่ไม่ได้ติดตาม

--สถานะ
รวมผลลัพธ์ของ git-สถานะ(1) ในเทมเพลตข้อความยืนยันเมื่อใช้ an
บรรณาธิการเพื่อเตรียมข้อความยืนยัน ค่าเริ่มต้นเป็นเปิด แต่สามารถใช้เพื่อแทนที่
การกำหนดค่าตัวแปร commit.status

--ไม่มีสถานะ
ไม่รวมผลลัพธ์ของ git-สถานะ(1) ในเทมเพลตข้อความยืนยันเมื่อใช้
ตัวแก้ไขเพื่อเตรียมข้อความยืนยันเริ่มต้น

-NS[ ], --gpg-สัญญาณ[= ]
สัญญา GPG ตกลง อาร์กิวเมนต์ keyid เป็นทางเลือกและเป็นค่าเริ่มต้นของคอมมิทเตอร์
ตัวตน; หากระบุไว้จะต้องติดอยู่กับตัวเลือกโดยไม่มีช่องว่าง

--no-gpg-สัญญาณ
Countermand commit.gpgSign ตัวแปรการกำหนดค่าที่ตั้งค่าให้บังคับแต่ละและทุก ๆ
มุ่งมั่นที่จะลงนาม

--
อย่าตีความข้อโต้แย้งใด ๆ เพิ่มเติมว่าเป็นตัวเลือก

...
เมื่อให้ไฟล์บนบรรทัดคำสั่ง คำสั่งจะคอมมิตเนื้อหาของ
ไฟล์ที่มีชื่อโดยไม่บันทึกการเปลี่ยนแปลงที่จัดฉากไว้แล้ว เนื้อหาของไฟล์เหล่านี้
ยังถูกจัดฉากสำหรับการคอมมิตครั้งต่อไปนอกเหนือจากสิ่งที่เคยแสดงมาก่อน

วัน รูปแบบ

ตัวแปรสภาพแวดล้อม GIT_AUTHOR_DATE, GIT_COMMITTER_DATE และตัวเลือก --date
รองรับรูปแบบวันที่ดังต่อไปนี้:

รูปแบบภายในของ Git
มันคือ , ที่ไหน คือจำนวน
วินาทีนับตั้งแต่ยุค UNIX เป็นค่าชดเชยบวกหรือลบ
จาก UTC ตัวอย่างเช่น CET (ซึ่งเร็วกว่า UTC 2 ชั่วโมง) คือ +0200

RFC 2822
รูปแบบอีเมลมาตรฐานตามที่ RFC 2822 อธิบาย เช่น พฤ 07 เม.ย. 2005
22:13:13 +0200.

ISO.8601
เวลาและวันที่กำหนดโดยมาตรฐาน ISO 8601 เช่น 2005-04-07T22:13:13 NS
parser ยอมรับช่องว่างแทนอักขระ T เช่นกัน

หมายเหตุ
นอกจากนี้ ยอมรับส่วนของวันที่ในรูปแบบต่อไปนี้: YYYY.MM.DD,
ดด/วว/ปปปป และ วว.ดด/ปปปป

ตัวอย่าง

เมื่อบันทึกงานของคุณเอง เนื้อหาของไฟล์ที่แก้ไขในแผนผังการทำงานของคุณคือ
เก็บไว้ชั่วคราวไปยังพื้นที่การแสดงละครที่เรียกว่า "ดัชนี" with คอมไพล์ เพิ่ม. ไฟล์สามารถ
ย้อนกลับ เฉพาะในดัชนีแต่ไม่อยู่ในแผนผังการทำงาน กลับไปเป็นคำสั่งสุดท้าย
ด้วย git รีเซ็ต HEAD -- ซึ่งเปลี่ยนกลับได้อย่างมีประสิทธิภาพ คอมไพล์ เพิ่ม และป้องกันการเปลี่ยนแปลง
ไปยังไฟล์นี้จากการเข้าร่วมคอมมิตครั้งต่อไป หลังจากสร้างรัฐให้เป็น
คอมมิตเพิ่มขึ้นด้วยคำสั่งเหล่านี้ git commit (ไม่มีพารามิเตอร์ชื่อพาธใด ๆ )
ใช้สำหรับบันทึกสิ่งที่ได้แสดงไปแล้ว นี่เป็นรูปแบบพื้นฐานที่สุดของคำสั่ง
ตัวอย่าง:

$ แก้ไข hello.c
$ git rm ลาก่อน.c
$ git เพิ่ม hello.c
$ git กระทำ

แทนที่จะจัดเตรียมไฟล์หลังจากการเปลี่ยนแปลงแต่ละครั้ง คุณสามารถบอกให้ git กระทำการแจ้งให้ทราบได้
การเปลี่ยนแปลงไฟล์ที่มีการติดตามเนื้อหาในแผนผังการทำงานของคุณและดำเนินการ
git add ที่เกี่ยวข้องและ git rm สำหรับคุณ นั่นคือ ตัวอย่างนี้ทำเช่นเดียวกับ
ตัวอย่างก่อนหน้านี้ หากไม่มีการเปลี่ยนแปลงอื่นๆ ในแผนผังการทำงานของคุณ:

$ แก้ไข hello.c
$ rm ลาก่อน.c
$ git คอมมิท -a

คำสั่ง git commit -a จะดูที่แผนผังการทำงานของคุณก่อน โดยสังเกตว่าคุณได้แก้ไข
hello.c และลบอำลา.c และดำเนินการ git add และ git rm ที่จำเป็นสำหรับคุณ

หลังจากการเปลี่ยนแปลงในหลายๆ ไฟล์ คุณสามารถเปลี่ยนลำดับการบันทึกการเปลี่ยนแปลงได้
โดยให้ชื่อพาธแก่คอมไพล์คอมมิท เมื่อกำหนดชื่อพาธแล้ว คำสั่งจะทำการคอมมิต
ที่บันทึกเฉพาะการเปลี่ยนแปลงที่ทำกับเส้นทางที่มีชื่อ:

$ แก้ไข hello.c สวัสดี.h
$ git เพิ่ม hello.c สวัสดี.h
$ แก้ไข Makefile
$ git กระทำ Makefile

สิ่งนี้ทำให้เกิดการคอมมิตที่บันทึกการแก้ไขใน Makefile การเปลี่ยนแปลงที่เกิดขึ้นสำหรับ
hello.c และ hello.h ไม่รวมอยู่ในคอมมิตผลลัพธ์ อย่างไรก็ตามการเปลี่ยนแปลงของพวกเขาคือ
ไม่แพ้ — พวกมันยังถูกจัดฉากและรั้งไว้เท่านั้น หลังจากลำดับข้างต้น ถ้าคุณ
ทำ:

$ 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 กับชื่อพาธ to
เปลี่ยนลำดับการเปลี่ยนแปลงที่เกิดขึ้นเพราะการรวมควรถูกบันทึกเป็น
คอมมิชชันเดียว อันที่จริง คำสั่งปฏิเสธที่จะทำงานเมื่อได้รับชื่อพาธ (แต่ดู -i
ตัวเลือก)

อภิปราย

แม้ว่าจะไม่จำเป็น แต่ก็เป็นความคิดที่ดีที่จะเริ่มต้นข้อความคอมมิตด้วยคำสั่งสั้นเพียงตัวเดียว
(น้อยกว่า 50 ตัวอักษร) บรรทัดที่สรุปการเปลี่ยนแปลง ตามด้วยบรรทัดว่าง แล้วตามด้วย a
คำอธิบายที่ละเอียดยิ่งขึ้น ข้อความถึงบรรทัดแรกว่างในข้อความยืนยันคือ
ถือเป็นชื่อการคอมมิต และชื่อนั้นจะใช้ทั่วทั้ง Git ตัวอย่างเช่น, คอมไพล์-
รูปแบบแพทช์(1) เปลี่ยนการคอมมิตเป็นอีเมล และใช้ชื่อเรื่องในบรรทัดหัวเรื่องและ
ส่วนที่เหลือของการกระทำในร่างกาย

Git คือการเข้ารหัสอักขระที่ไม่เชื่อเรื่องพระเจ้าในระดับหนึ่ง

· เนื้อหาของวัตถุหยดเป็นลำดับของไบต์ที่ไม่ได้ตีความ ไม่มี
การเข้ารหัสการแปลในระดับแกนกลาง

· ชื่อพาธถูกเข้ารหัสในรูปแบบการทำให้เป็นมาตรฐาน UTF-8 C ซึ่งใช้กับวัตถุต้นไม้
ไฟล์ดัชนี ชื่อผู้อ้างอิง เช่นเดียวกับชื่อพาธในอาร์กิวเมนต์บรรทัดคำสั่ง
ตัวแปรสภาพแวดล้อมและไฟล์ปรับแต่ง (.git/config (ดู git-config.php(1)) gitignore(5)
แอตทริบิวต์(5) และ gitmodules(พ.ศ. 5)).

โปรดทราบว่า Git ที่ระดับแกนกลางถือว่าชื่อพาธเป็นลำดับของ non-NUL
ไบต์ ไม่มีการแปลงการเข้ารหัสชื่อพาธ (ยกเว้นใน Mac และ Windows)
ดังนั้น การใช้ชื่อพาธที่ไม่ใช่ ASCII ส่วนใหญ่จะใช้งานได้แม้บนแพลตฟอร์มและไฟล์
ระบบที่ใช้การเข้ารหัส ASCII แบบขยายแบบเดิม อย่างไรก็ตามที่เก็บที่สร้างขึ้นบน
ระบบดังกล่าวจะไม่ทำงานอย่างถูกต้องบนระบบที่ใช้ 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 กับโปรเจ็กต์ ถ้าผู้เข้าร่วมทั้งหมดของa
โครงการเฉพาะพบว่าสะดวกกว่าในการใช้การเข้ารหัสแบบเดิม Git ไม่ห้าม
มัน. อย่างไรก็ตาม มีบางสิ่งที่ต้องจำไว้

1. คอมไพล์ ผูกมัด และ คอมไพล์ สัญญาต้นไม้ ออกคำเตือนหากข้อความบันทึกการคอมมิตที่มอบให้
ดูไม่เหมือนสตริง UTF-8 ที่ถูกต้อง เว้นแต่คุณจะระบุอย่างชัดเจนว่าโปรเจ็กต์ของคุณใช้ a
การเข้ารหัสแบบเดิม วิธีพูดนี้คือต้องมี i18n.commitencoding ใน .git/config
ไฟล์เช่นนี้:

[i18n]
การเข้ารหัส = ISO-8859-1

ยอมรับวัตถุที่สร้างขึ้นด้วยการตั้งค่าข้างต้นบันทึกค่าของ i18n.commitencoding
ในส่วนหัวของการเข้ารหัส นี้เพื่อช่วยเหลือผู้อื่นที่มองพวกเขาในภายหลัง ขาด
ส่วนหัวนี้บอกเป็นนัยว่าข้อความบันทึกการคอมมิตถูกเข้ารหัสใน UTF-8

2. คอมไพล์ เข้าสู่ระบบ, คอมไพล์ โชว์, คอมไพล์ ตำหนิ และเพื่อนๆ ดูที่ส่วนหัวการเข้ารหัสของคอมมิชชัน
วัตถุ และพยายามเข้ารหัสข้อความบันทึกใหม่เป็น UTF-8 เว้นแต่จะระบุไว้เป็นอย่างอื่น คุณ
สามารถระบุการเข้ารหัสเอาต์พุตที่ต้องการด้วย i18n.logoutputencoding ใน .git/config
ไฟล์เช่นนี้:

[i18n]
ออกจากระบบเข้ารหัส = ISO-8859-1

หากคุณไม่มีตัวแปรคอนฟิกูเรชันนี้ ค่าของ i18n.commitencoding is
ใช้แทน

โปรดทราบว่าเราจงใจเลือกที่จะไม่เข้ารหัสข้อความบันทึกการคอมมิตใหม่เมื่อคอมมิตเป็น
ทำขึ้นเพื่อบังคับ UTF-8 ที่ระดับอ็อบเจ็กต์การคอมมิต เนื่องจากการเข้ารหัสซ้ำเป็น UTF-8 ไม่ใช่
จำเป็นต้องมีการดำเนินการย้อนกลับ

และพวกเรา AND การกำหนดค่า ตัวแปร

ตัวแก้ไขที่ใช้ในการแก้ไขข้อความบันทึกการคอมมิตจะถูกเลือกจาก GIT_EDITOR
ตัวแปรสภาพแวดล้อม, ตัวแปรการกำหนดค่า core.editor, สภาพแวดล้อม VISUAL
ตัวแปร หรือตัวแปรสภาพแวดล้อม EDITOR (ตามลำดับ) ดู git-var(1) สำหรับรายละเอียด

เบ็ด

คำสั่งนี้สามารถเรียกใช้ commit-msg, prepare-commit-msg, pre-commit และ post-commit hooks
ดู gitooks(5) สำหรับข้อมูลเพิ่มเติม

ใช้ git-commit ออนไลน์โดยใช้บริการ onworks.net