ทำไม Github ที่ร้ายแรงทุกคนที่ฉันสั่งซื้อซ้ำทำให้อยากให้ฉันสควอชให้คำมั่นสัญญาของฉัน?

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

สิ่งนี้ก็ดูเหมือนว่าจะไปกับ "กระทำเร็วและกระทำบ่อย" มนต์

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

ตัวอย่างเช่นบันทึกการคอมไพล์ 'unsquashed' สำหรับฉันอาจมีลักษณะดังต่อไปนี้:

7hgf8978g9... Added new slideshow feature, JIRA # 848394839
85493g2458... Fixed slideshow display issue in ie
gh354354gh... wip, done for the week
789fdfffdf... minor alignment issue
787g8fgf78... hotfix for #5849564648
9080gf6567... implemented feature # 65896859
gh34839843... minor fix (typo) for 3rd test

ช่างเป็นระเบียบ!

ในขณะที่บันทึกการคอมไพล์ที่ได้รับการจัดการและผสานอย่างรอบคอบยิ่งขึ้นโดยมุ่งเน้นเพิ่มเติมเล็กน้อยในข้อความนี้อาจมีลักษณะดังนี้:

7hgf8978g9... 8483948393 Added new slideshow feature
787g8fgf78... 5849564648 Hotfix for android display issue
9080gf6567... 6589685988 Implemented pop-up to select language

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

คุณต้องการที่จะกระทำเร็วและบ่อยครั้ง เป็นการปฏิบัติที่ดีที่สุดด้วยเหตุผลหลายประการ ฉันพบว่าสิ่งนี้ทำให้ฉันมีความมุ่งมั่นที่ "wip" (กำลังดำเนินการอยู่) หรือ "part A done" หรือ "typo, minor fix" ซึ่งฉันใช้ git เพื่อช่วยฉันทำงานและให้คะแนนการทำงานที่ ฉันสามารถย้อนกลับไปที่รหัสต่อไปนี้ไม่ได้ผลเพราะฉันก้าวหน้าเพื่อให้สิ่งต่าง ๆ ทำงานได้ อย่างไรก็ตามฉันไม่ต้องการหรือต้องการประวัตินั้นเป็นส่วนหนึ่งของประวัติศาสตร์คอมไพล์ขั้นสุดท้ายดังนั้นฉันอาจสควอชคอมมิชชันของฉัน - แต่ดูหมายเหตุด้านล่างว่าสิ่งนี้มีความหมายอย่างไรกับสาขาพัฒนาเทียบกับปรมาจารย์

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

8754390gf87... Implement feature switches

ดูเหมือนว่า "งาน 1 ชิ้น" อาจมีหรือไม่มี! ดูเหมือนจะไม่สมเหตุสมผลที่จะแยกออก อย่างไรก็ตามประสบการณ์ได้แสดงให้ฉันเห็นว่า (ขึ้นอยู่กับขนาดองค์กรและความซับซ้อน) เส้นทางที่ละเอียดยิ่งขึ้นอาจเป็น:

fgfd7897899... Add field to database, add indexes and a trigger for the dw group
9458947548g... Add 'backend' code in controller for when id is passed in url.
6256ac24426... Add 'backend' code to make field available for views.
402c476edf6... Add feature to UI

ชิ้นส่วนขนาดเล็กหมายถึงการตรวจสอบโค้ดที่ง่ายขึ้นการทดสอบหน่วยง่ายขึ้นโอกาสในการ qa ที่ดีขึ้นการจัดตำแหน่งให้สอดคล้องกับหลักการความรับผิดชอบเดี่ยว ฯลฯ

สำหรับการใช้งานจริงของเวลาที่จะทำสควอชจริง ๆ นั้นมีสองขั้นตอนที่แตกต่างกันที่มีเวิร์กโฟลว์ของตัวเอง

• การพัฒนาของคุณเช่นการร้องขอการดึง
• เพิ่มงานของคุณในสาขาการฉีดเช่นปริญญาโท

ในระหว่างการพัฒนาของคุณคุณยอมรับ 'เร็วและบ่อย' และพร้อมกับข้อความ 'ทิ้ง' อย่างรวดเร็ว คุณอาจต้องการสควอชที่นี่ในบางครั้งเช่นการสควอชในข้อความ wip และ todo ภายในสาขาเพื่อรักษาความมุ่งมั่นหลายอย่างที่แสดงขั้นตอนที่แตกต่างที่คุณทำในการพัฒนา สควอชส่วนใหญ่ที่คุณเลือกทำควรอยู่ในฟีเจอร์กิ่งไม้เหล่านี้ในขณะที่สควอชกำลังได้รับการพัฒนาและก่อนที่จะผสานเข้ากับต้นแบบ
เมื่อเพิ่มไปยังสาขาการฉีดคุณต้องการให้การกระทำกระชับและจัดรูปแบบอย่างถูกต้องตามประวัติการฉีดที่มีอยู่ ซึ่งอาจรวมถึง ID ระบบตัวติดตามตั๋วเช่น JIRA ดังที่แสดงในตัวอย่าง การสควอชไม่ได้มีผลกับที่นี่จริงๆเว้นแต่คุณจะต้องการ 'โรลอัพ' ความมุ่งมั่นที่แตกต่างกันหลายอย่างในมาสเตอร์ ปกติคุณทำไม่ได้

การใช้--no-ffเมื่อผสานกับหลักจะใช้การคอมมิทหนึ่งสำหรับการผสานและยังเก็บประวัติ (ในสาขา) บางองค์กรคิดว่านี่เป็นแนวทางปฏิบัติที่ดีที่สุด ดูเพิ่มเติมได้ที่https://stackoverflow.com/q/9069061/631619นอกจากนี้คุณยังจะเห็นผลการปฏิบัติgit logที่การ--no-ffกระทำจะกระทำล่าสุดที่ด้านบนของหัว (เมื่อเพิ่งทำ) ในขณะที่ไม่มี--no-ffมัน เพิ่มเติมลงในประวัติศาสตร์ขึ้นอยู่กับวันที่และความมุ่งมั่นอื่น ๆ

เพราะบ่อยครั้งที่คนดึง PR ให้ความสำคัญกับผลกระทบสุทธิของคอมมิท "เพิ่มฟีเจอร์ X" ไม่เกี่ยวกับ "เท็มเพลตฐานฟังก์ชันการแก้ไขข้อผิดพลาด X เพิ่มฟังก์ชั่น Y แก้ไขความผิดพลาดในคอมเม้นท์ รายการ "... ระดับรายละเอียด

หากคุณคิดว่า 16 คอมมิชชันของคุณจะถูกนำเสนอโดย 2 คอมมิทแทนที่จะเป็น 1 "เพิ่มฟีเจอร์ X ให้ทำการแฟ็กซ์ Z เพื่อใช้ X อีกครั้ง" ซึ่งอาจเป็นเรื่องดีที่จะเสนอราคาด้วย 2 คอมมิต 2 แยก pr ในกรณีนั้น (ถ้า repo ยังคงยืนยันในการกระทำเดียวของ pr)

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

เหตุผลหลักจากสิ่งที่ฉันเห็นมีดังนี้:

• GitHub UI สำหรับการรวมคำขอดึงในขณะนี้ (ตุลาคม 2015) ไม่อนุญาตให้คุณแก้ไขบรรทัดแรกของข้อความส่งข้อความบังคับให้เป็น Merge pull request #123 from joebloggs/fix-snafoo
• GitHub UI สำหรับการสืบค้นประวัติการส่งมอบในปัจจุบันไม่อนุญาตให้คุณดูประวัติของสาขาจาก--first-parentมุมมอง
• GitHub UI สำหรับการดูตำหนิบนไฟล์ในขณะนี้ไม่อนุญาตให้คุณดูตำหนิของไฟล์พร้อม--first-parentมุมมอง (โปรดทราบว่านี่ถูกแก้ไขใน Git 2.6.2 เท่านั้นดังนั้นเราสามารถให้อภัย GitHub ที่ไม่มี สามารถใช้ได้)

ดังนั้นเมื่อคุณรวมทั้งสามสถานการณ์ข้างต้นเข้าด้วยกันคุณจะได้รับสถานการณ์ที่ไม่ได้ถูกยืนยันว่าคอมมิทที่ถูกรวมเข้าด้วยกันดูน่าเกลียดจาก GitHub UI

ประวัติของคุณที่มีการกระทำที่ถูกแบนจะดูเหมือนว่า

1256556316... Merge pull request #423 from jrandom/add-slideshows
7hgf8978g9... Added new slideshow feature
56556316ad... Merge pull request #324 from ahacker/fix-android-display
787g8fgf78... Hotfix for android display issue
f56556316e... Merge pull request #28 from somwhere/select-lang-popup
9080gf6567... Implemented pop-up to select language

ในขณะที่ไม่มีการแบนประวัติศาสตร์จะดูเหมือน

1256556316... Merge pull request #423 from jrandom/add-slideshows
7hgf8978g9... Added new slideshow feature, JIRA # 848394839
85493g2458... Fixed slideshow display issue in ie
gh354354gh... wip, done for the week
789fdfffdf... minor alignment issue
56556316ad... Merge pull request #324 from ahacker/fix-android-display
787g8fgf78... hotfix for #5849564648
f56556316e... Merge pull request #28 from somwhere/select-lang-popup
9080gf6567... implemented feature # 65896859
gh34839843... minor fix (typo) for 3rd test

เมื่อคุณมีจำนวนมากของการกระทำในการประชาสัมพันธ์การติดตามที่มีการเปลี่ยนแปลงมาจะกลายเป็นบิตของฝันร้ายที่ถ้าคุณ จำกัด ตัวเองให้ใช้ UI

ตัวอย่างเช่นคุณพบว่าตัวชี้โมฆะถูกยกเลิกการอ้างอิงบางแห่งในไฟล์ ... ดังนั้นคุณจึงพูดว่า "ใครทำสิ่งนี้และเมื่อใด จากนั้นคุณเดินไปที่มุมมองการตำหนิใน GitHub UI และคุณเห็นว่าบรรทัดนั้นเปลี่ยนไป789fdfffdf... "โอ้เดี๋ยวก่อนเดี๋ยวก่อนบรรทัดนั้นเพิ่งเปลี่ยนการเยื้องเข้าไปเพื่อให้พอดีกับส่วนที่เหลือของรหัส" ดังนั้นตอนนี้คุณต้องไปยังสถานะต้นไม้สำหรับไฟล์นั้นในพาเรนต์ที่คอมมิทและกลับมาใหม่ หน้าตำหนิ ... ในที่สุดคุณก็พบว่ามีการกระทำ ... มันเป็นการกระทำจาก 6 เดือนที่ผ่านมา ... "โอ้ **** สิ่งนี้อาจส่งผลกระทบต่อผู้ใช้เป็นเวลา 6 เดือน" คุณพูด ... อา แต่เดี๋ยวก่อน เป็นจริงในคำขอดึงและถูกรวมเข้าด้วยกันเมื่อวานนี้และยังไม่มีใครตัดการเปิดตัว ... "คุณคนที่รวมการกระทำโดยไม่ต้องบีบประวัติ" เป็นเสียงร้องที่มักจะได้ยินหลังจากการสำรวจโบราณคดีรหัสประมาณ 2 หรือ 3 ผ่าน GitHub UI

ตอนนี้ให้เราพิจารณาว่ามันใช้งานได้อย่างไรถ้าคุณใช้บรรทัดคำสั่ง Git (และสุดยอด 2.6.2 ซึ่งมีการแก้ไขgit blame --first-parent)

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

ดังนั้นประวัติความเป็นมาของเราก็จะดูเหมือน

$ git log
1256556316... #423 Added new slideshow feature
7hgf8978g9... Added new slideshow feature, JIRA # 848394839
85493g2458... Fixed slideshow display issue in ie
gh354354gh... wip, done for the week
789fdfffdf... minor alignment issue
56556316ad... #324 Hotfix for android display issue
787g8fgf78... hotfix for #5849564648
f56556316e... #28 Implemented pop-up to select language
9080gf6567... implemented feature # 65896859
gh34839843... minor fix (typo) for 3rd test

แต่เราก็สามารถทำได้

$ git log --first-parent
1256556316... #423 Added new slideshow feature
56556316ad... #324 Hotfix for android display issue
f56556316e... #28 Implemented pop-up to select language

(ในคำอื่น ๆ : Git CLI ช่วยให้คุณมีเค้กของคุณและกินมันเกินไป)

ตอนนี้เมื่อเราพบปัญหาตัวชี้โมฆะ ... เราเพิ่งใช้git blame --first-parent -w dodgy-file.cและเราจะได้รับการยอมรับทันทีที่การอ้างอิงตัวชี้โมฆะถูกนำมาใช้กับสาขาหลักโดยไม่สนใจการเปลี่ยนแปลงช่องว่างอย่างง่าย

แน่นอนถ้าคุณทำการผสานโดยใช้ GitHub UI แล้วgit log --first-parentก็ต้องขอบคุณมากสำหรับ GitHub ที่บังคับให้บรรทัดแรกของข้อความยืนยันการรวม:

1256556316... Merge pull request #423 from jrandom/add-slideshows
56556316ad... Merge pull request #324 from ahacker/fix-android-display
f56556316e... Merge pull request #28 from somwhere/select-lang-popup

ดังนั้นการตัดเรื่องสั้นให้สั้น:

GitHub UI (ต.ค. 2558) มีข้อบกพร่องหลายประการเกี่ยวกับวิธีการรวมคำขอดึงวิธีแสดงประวัติการกระทำและวิธีการที่ข้อมูลการตำหนิ วิธีที่ดีที่สุดในปัจจุบันในการแฮ็กข้อบกพร่องเหล่านี้ใน GitHub UI คือการขอให้ผู้คนสควอชกระทำของพวกเขาก่อนที่จะรวม

Git CLI ไม่มีปัญหาเหล่านี้และคุณสามารถเลือกมุมมองที่คุณต้องการดูได้อย่างง่ายดายเพื่อให้คุณสามารถค้นพบสาเหตุที่ทำให้มีการเปลี่ยนแปลงโดยเฉพาะอย่างยิ่ง (โดยดูที่ประวัติความเป็นมาของคำสั่งที่ยังไม่ผ่านการคัด) และ เห็นความมุ่งมั่นบีบได้อย่างมีประสิทธิภาพ

โพสต์สคริปต์

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

ถ้าคุณกำลังดูประวัติคอมไพล์ด้วยgit log --first-parentคุณก็สามารถเลือกการรวมเชอร์รี่ได้ คนส่วนใหญ่สับสนกับการเก็บเชอร์รี่เพราะคุณต้องระบุ-m Nตัวเลือกแต่ถ้าคุณได้รับการยอมรับจากgit log --first-parentนั้นคุณก็รู้ว่ามันเป็นผู้ปกครองคนแรกที่คุณต้องการติดตามดังนั้นมันจะเป็นgit cherry-pick -m 1 ...

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

เนื่องจากมุมมอง ... แนวทางปฏิบัติที่ดีที่สุดคือการมีความมุ่งมั่นต่อ<<issue-management-system>>ปัญหาเดียวถ้าเป็นไปได้

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

ดังนั้นเมื่อใดก็ตามที่คุณต้องการคอมมิชชันการแก้ไขบั๊กหรือฟีเจอร์ให้กับ repo ทั่วไป (ตัวอย่างนี้มีสาขาพัฒนา) สิ่งที่คุณสามารถทำได้ดังนี้:

วิธีการ rebase สาขาคุณลักษณะของคุณในการพัฒนาอย่างรวดเร็ว

    # set your current branch , make a backup of it , caveat minute precision
    curr_branch=$(git rev-parse --abbrev-ref HEAD); git branch "$curr_branch"--$(date "+%Y%m%d_%H%M"); git branch -a | grep $curr_branch | sort -nr

    # squash all your changes at once 
    git reset $(git merge-base develop $curr_branch)

    # check the modified files to add 
    git status

    # add the modified files dir by dir, or file by file or all as shown
    git add --all 

    # check once again 
    git log --format='%h %ai %an %m%m %s'  | less

    # add the single message of your commit for the stuff you did 
    git commit -m "<<MY-ISSUE-ID>>: add my very important feature"

    # check once again 
    git log --format='%h %ai %an %m%m %s'  | less

    # make a backup once again , use seconds precision if you were too fast ... 
    curr_branch=$(git rev-parse --abbrev-ref HEAD); git branch "$curr_branch"--$(date "+%Y%m%d_%H%M"); git branch -a | grep $curr_branch | sort -nr

    # compare the old backup with the new backup , should not have any differences 
    git diff <<old-backup>>..<<new-backup-branch>>


    # you would have to git push force to your feature branch 
    git push --force 

ฉันจะดูว่ารหัสเป็นสาธารณะหรือไม่

เมื่อโครงการมีความเป็นส่วนตัว:

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

เมื่อโครงการเปิดสู่สาธารณะ:

ลบล้างทุกอย่างเพราะการกระทำบางอย่างอาจมีการรั่วไหลของความปลอดภัย ตัวอย่างเช่นรหัสผ่านที่ได้รับการยอมรับและลบอีกครั้ง