ควรคอมไพล์ทุกคนออกจากโครงการในสถานะการทำงานหรือไม่

ฉันอยากรู้ว่าการปฏิบัติที่ดีที่สุดคืออะไร ควรคอมไพล์คอมมิชชันบังคับใช้เพื่อให้โครงการอยู่ในสถานะใช้งาน (สร้างอย่างถูกต้องการทดสอบทั้งหมดผ่าน ฯลฯ ) หรือยอมรับรหัสที่ใช้งานไม่ได้?

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

ฉันมักจะปฏิบัติตามกฎนี้

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

ใช้โคลนพื้นที่เก็บข้อมูลของคุณสำหรับสิ่งที่ทำให้คุณสะดวกสบายในขณะที่การพัฒนา

ฉันส่งรหัสที่ใช้งานไม่ได้เป็นประจำและเมื่อฉันพร้อมที่จะให้ผู้พัฒนารายอื่น ๆ พร้อมใช้งานรหัสฉันใช้คุณสมบัติที่ยอดเยี่ยม:

git rebase -i HEAD~4

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

จากนั้นฉันสามารถผลักดันให้หนึ่งอะตอมกระทำหรือในความเป็นจริงสิ่งที่ฉันทำถ้าคุณสมบัติใหม่ของฉันพร้อมจริงๆใช้ 'git cvsexportcommit' เพื่อให้งานของฉันเป็น repo CVS ที่มีอยู่

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

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

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

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

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

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

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

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

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

ในที่สุดมันก็ขึ้นอยู่กับคุณและคนที่คุณทำงานด้วยหรือเพราะคอมไพล์ไม่ได้กำหนดกฎใด ๆ

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

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

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

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

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

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