เมื่อใดที่ฉันควรใช้ git pull --rebase

ฉันรู้ว่าบางคนที่ใช้เป็นgit pull --rebaseค่าเริ่มต้นและคนอื่น ๆ ที่ยืนยันว่าจะไม่ใช้มัน ฉันเชื่อว่าฉันเข้าใจความแตกต่างระหว่างการควบรวมกิจการและ rebasing git pullแต่ฉันพยายามที่จะวางนี้ในบริบทของ มันเป็นเรื่องเกี่ยวกับที่ไม่ต้องการเห็นข้อความที่รวมเข้ามาจำนวนมากหรือมีปัญหาอื่น ๆ อีกหรือไม่?

คุณควรใช้git pull --rebaseเมื่อ

• การเปลี่ยนแปลงของคุณไม่ควรแยกสาขา

แน่นอน - ทำไมไม่เป็นเช่นนั้น? ชัดเจนยิ่งขึ้นและไม่ได้กำหนดการจัดกลุ่มแบบลอจิคัลในการกระทำของคุณ

ตกลงฉันคิดว่ามันต้องมีการชี้แจง ใน Git อย่างที่คุณรู้คุณได้รับการสนับสนุนให้แยกสาขาและผสาน สาขาในพื้นที่ของคุณที่คุณดึงการเปลี่ยนแปลงและสาขาที่อยู่ห่างไกลนั้นจริง ๆ แล้วเป็นสาขาที่แตกต่างกันและgit pullกำลังจะรวมสาขาเหล่านั้น มันสมเหตุสมผลเนื่องจากคุณกดไม่บ่อยนักและมักจะมีการเปลี่ยนแปลงจำนวนมากก่อนที่จะเป็นคุณลักษณะที่สมบูรณ์

แต่บางครั้ง - โดยเหตุผลใด - คุณคิดว่าจริง ๆ แล้วมันจะดีกว่าถ้าสองคนนี้ - ระยะไกลและท้องถิ่น - เป็นหนึ่งในสาขา เช่นเดียวกับใน SVN มันอยู่ที่นี่ที่git pull --rebaseเข้ามาเล่น คุณผสานไม่ - คุณจริงกระทำที่ด้านบนของสาขาที่ห่างไกล นั่นคือสิ่งที่เป็นจริงเกี่ยวกับ

ไม่ว่าจะเป็นอันตรายหรือไม่เป็นคำถามว่าคุณกำลังรักษาสาขาในพื้นที่และห่างไกลเป็นสิ่งที่แยกกันไม่ออก บางครั้งก็สมเหตุสมผล (เมื่อการเปลี่ยนแปลงของคุณมีขนาดเล็กหรือหากคุณอยู่ในช่วงเริ่มต้นของการพัฒนาที่แข็งแกร่งเมื่อมีการเปลี่ยนแปลงเล็ก ๆ น้อย ๆ ที่สำคัญ) บางครั้งมันก็ไม่ได้ (เมื่อคุณสร้างสาขาอื่นตามปกติ แต่คุณขี้เกียจเกินไปที่จะทำ) แต่นั่นเป็นคำถามที่แตกต่าง

ฉันต้องการให้มุมมองที่แตกต่างกันเกี่ยวกับความหมายของ "git pull --rebase" จริง ๆ เพราะดูเหมือนว่าจะหายไปในบางครั้ง

หากคุณเคยใช้ Subversion (หรือ CVS) คุณอาจคุ้นเคยกับพฤติกรรมของ "svn update" หากคุณมีการเปลี่ยนแปลงที่จะคอมมิทและการคอมมิทล้มเหลวเนื่องจากมีการทำการอัปเดตอัปสตรีมคุณ "svn update" การโค่นล้มได้มาจากการรวมการเปลี่ยนแปลงต้นน้ำกับคุณซึ่งอาจทำให้เกิดความขัดแย้ง

สิ่งที่การโค่นล้มเพียงแค่ทำคือ "pull --rebase" เป็นหลัก การกำหนดรูปแบบการเปลี่ยนแปลงในท้องถิ่นของคุณให้สัมพันธ์กับเวอร์ชันที่ใหม่กว่าคือส่วน "การรีบูต" ของมัน หากคุณทำ "svn diff" ก่อนที่จะพยายามส่งข้อมูลที่ล้มเหลวและเปรียบเทียบผลต่างกับผลลัพธ์ของ "svn diff" หลังจากนั้นความแตกต่างระหว่างทั้งสอง diffs คือการดำเนินการรีบูต

ความแตกต่างที่สำคัญระหว่าง Git และการโค่นล้มในกรณีนี้คือในการโค่นล้มการเปลี่ยนแปลง "ของคุณ" มีอยู่เป็นการเปลี่ยนแปลงที่ไม่ได้ทำในสำเนาการทำงานของคุณในขณะที่ Git คุณมีการกระทำจริงในท้องถิ่น กล่าวอีกนัยหนึ่งใน Git คุณได้แยกประวัติศาสตร์ ประวัติและประวัติต้นน้ำของคุณแตกต่างกันไป แต่คุณมีบรรพบุรุษร่วมกัน

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

หากคุณรู้สึกว่าจำเป็นต้องมีบางสิ่งบางอย่างเพื่อเป็นสาขาไม่ว่าด้วยเหตุผลใดก็ตามนั่นเป็นข้อกังวลที่แตกต่างกันในความเห็นของฉัน แต่ถ้าคุณไม่มีความปรารถนาที่เฉพาะเจาะจงและกระตือรือร้นที่จะแสดงการเปลี่ยนแปลงของคุณในรูปแบบของการผสานพฤติกรรมเริ่มต้นควรจะเป็น "git pull --rebase"

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

บางทีวิธีที่ดีที่สุดในการอธิบายคือตัวอย่าง:

1. อลิซสร้างหัวข้อย่อย A และใช้งานได้
2. Bob สร้างสาขาหัวข้อที่ไม่เกี่ยวข้อง B และทำงานในหัวข้อนั้น
3. git checkout master && git pullอลิซไม่ อาจารย์เป็นปัจจุบันแล้ว
4. git checkout master && git pullบ๊อบไม่ อาจารย์เป็นปัจจุบันแล้ว
5. อลิซทำ git merge topic-branch-A
6. บ๊อบทำ git merge topic-branch-B
7. บ๊อบทำgit push origin masterก่อนอลิซ
8. อลิซทำgit push origin masterซึ่งถูกปฏิเสธเพราะไม่ใช่การผสานที่รวดเร็ว
9. อลิซมองไปที่บันทึกการกำเนิด / ปรมาจารย์และเห็นว่าการกระทำนั้นไม่เกี่ยวข้องกับเธอ
10. อลิซทำ git pull --rebase origin master
11. การรวมของอลิซนั้นไม่ได้ผูกไว้การกระทำของบ๊อบก็ถูกดึงออกมาและการกระทำของอลิซก็ถูกนำไปใช้หลังจากการกระทำของบ๊อบ
12. อลิซทำได้git push origin masterและทุกคนมีความสุขที่พวกเขาไม่จำเป็นต้องอ่านการรวมที่ไร้ประโยชน์เมื่อพวกเขาดูบันทึกในอนาคต

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

ฉันคิดว่าคุณควรใช้git pull --rebaseเมื่อร่วมมือกับผู้อื่นในสาขาเดียวกัน คุณอยู่ในการทำงาน→ส่งมอบ→ทำงาน→กระทำรอบและเมื่อคุณตัดสินใจที่จะผลักดันงานของคุณผลักดันของคุณถูกปฏิเสธเพราะมีงานขนานในสาขาเดียวกัน ณ จุดนี้ผมมักจะpull --rebaseทำ ฉันไม่ได้ใช้สควอช (เพื่อทำให้คอมมิทแบน) แต่ฉันรีบูตเพื่อหลีกเลี่ยงการคอมมิชชันพิเศษ

เมื่อความรู้ Git ของคุณเพิ่มขึ้นคุณจะพบว่าตัวเองดูประวัติมากขึ้นกว่าระบบควบคุมรุ่นอื่น ๆ ที่ฉันเคยใช้ หากคุณมีการรวมขนาดเล็กจำนวนมากมันง่ายที่จะเสียสมาธิไปกับภาพใหญ่ที่เกิดขึ้นในประวัติศาสตร์ของคุณ

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

(*) ในขณะที่สอนหลักสูตร Git ฉันมีนักเรียนจับกุมฉันเกี่ยวกับเรื่องนี้เนื่องจากฉันยังสนับสนุนสาขาการลดคุณสมบัติในบางกรณี และเขาได้อ่านคำตอบนี้;) การรีบูตเป็นไปได้เช่นกัน แต่มันจะต้องเป็นไปตามระบบที่จัดไว้ล่วงหน้า / ตกลงกันไว้เสมอและไม่ควรใช้ "เสมอ" และในเวลานั้นฉันมักจะไม่ทำpull --rebaseเช่นนั้นซึ่งเป็นคำถามที่เกี่ยวกับ;)

ฉันไม่คิดว่าจะมีเหตุผลอะไรที่จะไม่ใช้pull --rebase- ฉันเพิ่มโค้ดลงใน Git โดยเฉพาะเพื่อให้git pullคำสั่งของฉันรีบูทกับการคอมมิทอัพสตรีมเสมอ

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

แค่จำไว้:

• pull = fetch + merge
• pull --rebase = fetch + rebase

ดังนั้นเลือกวิธีที่คุณต้องการจัดการสาขาของคุณ

คุณควรทราบถึงความแตกต่างระหว่างการผสานและการลดใหม่ :)

ฉันคิดว่ามันทำให้ความชอบส่วนตัวลดลง

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

ฉันเองก็ไม่รังเกียจที่จะเผยแพร่ความผิดพลาดที่โง่ ๆ ของฉันดังนั้นฉันจึงมักจะรวมเข้าด้วยกันแทนที่จะเป็น rebase

git pull --rebasegit push --forceอาจซ่อนประวัติศาสตร์ที่เขียนจากการทำงานร่วมกัน ฉันแนะนำให้ใช้git pull --rebase เฉพาะเมื่อคุณรู้ว่าคุณลืมที่จะผลักดันการกระทำของคุณก่อนที่คนอื่นทำเช่นเดียวกัน

หากคุณไม่ได้กระทำอะไร แต่พื้นที่ทำงานของคุณไม่ได้ทำความสะอาดเพียงก่อนที่จะgit stash git pullวิธีนี้คุณจะไม่เขียนประวัติของคุณแบบเงียบ ๆ (ซึ่งอาจทำให้งานของคุณเงียบลง)