ทำไมไม่ยอมรับการเปลี่ยนแปลงที่ไม่ได้แก้ไข?

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

แต่ฉันคิดว่าที่เก็บของคุณควรถูกล็อคจากการผลักและดึงแต่ไม่ได้กระทำ

ความสามารถในการส่งมอบระหว่างกระบวนการผสานมีข้อดีหลายประการ (ดังที่ฉันเห็น):

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

คุณอาจจะมีชุดของเซ็ตการแก้ไขทำหน้าที่เป็นผสานแทนที่จะเป็นชุดเดียว git rerereนี้จะช่วยให้คุณยังคงใช้เครื่องมือเช่น

เหตุใดจึงมีการส่งไฟล์ที่ไม่ได้รับการแก้ไข / ป้องกัน? มีเหตุผลอื่นนอกเหนือจากประเพณีหรือไม่?

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

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

ฉันคุ้นเคยกับ Git มากที่สุดดังนั้นฉันจะตอบรับมุมมองนั้น

ฉันไม่เห็นสาเหตุที่คุณหรือ VCS ที่ดีต้องการอนุญาตให้ส่งไฟล์ที่ยังไม่ได้ทำการฝังโดยเฉพาะอย่างยิ่งถ้าเป็นรหัส คุณต้องเก็บที่เก็บไว้ในสถานะที่สอดคล้องกันและสิ่งที่คุณกำลังแนะนำจะเป็นการละเมิดการกระทำแบบอะตอมมิกซิตี้ VCS หลายคนเปลี่ยนแปลงไฟล์เพื่อแสดงว่าข้อขัดแย้งอยู่ที่ใด - Git, SVN และ CVS ใช้เครื่องหมายประเภท >>>> <<<< ใน VCS ที่มีระดับการเก็บข้อมูลระดับอะตอมกระทำและผสานคุณจะต้องสร้างโหนดที่ไม่เหมาะสมกับใครนอกจากคุณ ในการพัฒนาซอฟต์แวร์โครงการของคุณไม่สามารถสร้างได้ ในเอกสารของกลุ่มไม่มีใครรู้ว่าการเปลี่ยนแปลงใดถูกต้อง

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

ข้อกังวลเฉพาะเกี่ยวกับรายการผลประโยชน์ของคุณ:

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

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

ประสบการณ์หลักของฉันอยู่กับ Mercurial แม้ว่าฉันจะใช้คอมไพล์เป็นระยะ

Mercurial ไม่อนุญาตให้คุณส่งไฟล์ที่ไม่ได้รับการแก้ไข แต่จะทำให้คุณท้อแท้ ข้อตกลงเดียวกันกับการกดก่อนดึงการเปลี่ยนแปลงที่คุณไม่มี

สิ่งที่คุณต้องทำใน Mercurial คือเมื่อคุณมีไฟล์ในแบบที่คุณต้องการ:

hg resolve --mark --all
hg commit -m "I'm such a rebel"

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

หากคุณต้องการที่จะผลักดันโดยไม่ต้องดึง (และดังนั้นจึงต้องรวมการเปลี่ยนแปลงของผู้อื่น) ทำเหมือนเจได :

hg push --force

คนต่อไปที่ดึงจะได้รับ +1 หัว (ไม่มีปุนตั้งใจ)

ฉันแน่ใจว่ามีวิธีการทำสิ่งเดียวกันกับ Git (แม้ว่ามันอาจจะซับซ้อนกว่า)

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

สุจริตฉันไม่เข้าใจว่าทำไมคนอื่นไม่ทำแบบนี้หรือคอมไพล์ไม่บังคับใช้

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

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

เวิร์กโฟลว์ของฉันที่อธิบายไว้ข้างต้นหลีกเลี่ยงปัญหาการคัดลอกภายในเครื่องนี้และยังช่วยให้ผู้ตรวจสอบโค้ดตรวจสอบรายละเอียดการแก้ปัญหาการผสานของคุณในคอมมิทคอมมิชชันที่มีลักษณะเหมือนกับการคอมมิทมาตรฐาน

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

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

ฉันเดาจากมุมมองของฉันเก็บของครึ่งตัวไว้ในเครื่องส่งของดีๆ

อย่าเป็นทาสของเครื่องมือของคุณ

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

อย่างไรก็ตามคุณไม่ควรกดรหัสที่ใช้ไม่ได้

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

ฉันเห็นว่าในกรณีของการผสานขนาดใหญ่ / ซับซ้อนคุณอาจต้องการบันทึกงานที่กำลังดำเนินการและสร้างจุดอ้างอิง แต่คุณยังคงต้องออกจากระบบในสถานะที่ยุ่งเหยิงซึ่งต้องแก้ไข

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

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