ทำงานในโครงการใช้คุณสมบัติอย่างหนักบางครั้งมี 3 devs สำหรับแอปพลิเคชันนี้

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

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

มีเวิร์กโฟลว์หรือขั้นตอนที่ลดความเสี่ยงของความขัดแย้งและเขียนทับหรือไม่

เบาะแสเกี่ยวกับคุณสมบัติยินดีต้อนรับ

ยินดีต้อนรับสู่ดินแดนแห่งF eatures C onfiguration M anagement อาคาFCM ! มันไม่ได้เกี่ยวกับคุณสมบัติเท่านั้น แต่ไม่เกี่ยวกับการจัดการการกำหนดค่า (ตามที่แนะนำใน Drupal เวอร์ชัน 8) แต่มันเป็นกรณีพิเศษของS oftware C onfiguration M anagementอาคาSCM ส่วนใหญ่เป็นเพราะคุณสมบัติถือได้ว่าเป็นตัวสร้างรหัสในขณะที่รหัสที่สร้างขึ้นจะต้องมีการโยกย้ายผ่านสภาพแวดล้อมที่หลากหลาย อ่านต่อเพื่อดูรายละเอียดเพิ่มเติม

1 - ข้อดีข้อเสียของการใช้คุณสมบัติ

ข้อดีของการใช้คุณสมบัติ

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

ข้อเสียของการใช้คุณสมบัติ

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

2 - เทคนิคสำหรับบรรจุภัณฑ์คุณลักษณะ

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

คุณสมบัติสุดยอดเยี่ยม

นี่เป็นเทคนิคการบรรจุหีบห่อที่เรียบง่าย: ทุกอย่างถูกรวมเข้าด้วยกันในฟีเจอร์เดียว (บางคนเรียกมันว่าคุณลักษณะ "พระเจ้า" ... ) ดูเหมือนง่ายไปข้างหน้า ฯลฯ แต่เทคนิคนี้ยังนำไปสู่ ​​"ความขัดแย้ง" (ตามที่อธิบายด้านล่าง) ไม่มากก็น้อย ...

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

ตามฟังก์ชั่นเว็บไซต์

เทคนิคการทำบรรจุภัณฑ์นี้สร้างคุณสมบัติแยกต่างหากสำหรับการใช้งานของแต่ละเว็บไซต์เช่น:

• คุณสมบัติ A = ใช้งาน " แกลลอรี่ * "
• คุณสมบัติ B = implementg " บล็อก * "
• คุณสมบัติ C = ใช้งาน " * ปฏิทินกิจกรรม "

ขึ้นอยู่กับส่วนของผู้ดูแลระบบ Drupal

เทคนิคการทำบรรจุภัณฑ์นี้สร้างคุณสมบัติแยกต่างหากสำหรับแต่ละส่วนของผู้ดูแลระบบ (หลัก) ของเว็บไซต์ Drupal ที่ใช้สร้างเว็บไซต์เช่น:

• โมดูลที่จำเป็นทั้งหมดมีอยู่ในคุณสมบัติ A
• นิยามฟิลด์ฐานทั้งหมดมีอยู่ในคุณสมบัติ B
• เนื้อหาทุกประเภทมีอยู่ในคุณสมบัติ C
• การอนุญาตทั้งหมดมีอยู่ในฟีเจอร์ D
• บทบาททั้งหมดมีอยู่ในคุณสมบัติ E
• ตัวแปรทั้งหมดมีอยู่ในคุณสมบัติ F
• ทั้งหมด (กำหนดเอง) เข้าชมที่มีอยู่ในคุณลักษณะ G,
• กฎทั้งหมด (กำหนดเอง) มีอยู่ในฟีเจอร์ H
• เป็นต้น

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

IMO เป็นวิธีที่แนะนำมากที่สุดสำหรับคุณสมบัติแพ็คเกจ

3 - ลดความน่าจะเป็นของความขัดแย้งในคุณลักษณะและ / หรือ GIT

อย่าใช้ฟิลด์ซ้ำ

ดูเหมือนว่ามีข้อขัดแย้งเล็กน้อยเกิดขึ้นเนื่องจากการใช้ฟิลด์ซ้ำระหว่างเนื้อหาหลายประเภท เช่นในประเภทเนื้อหา A คุณมีเขตข้อมูลที่มีชื่อเครื่องfield_somefieldซึ่งใช้เป็นเขตข้อมูลในชนิดเนื้อหา B ที่มีชื่อเครื่องเหมือนกันfield_somefieldแต่เป็นเขตข้อมูลประเภทอื่นและ / หรือการตั้งค่าฟิลด์อื่นที่แตกต่างกัน

โดยไม่นำฟิลด์กลับมาใช้ซ้ำระหว่างประเภทเนื้อหาคุณหลีกเลี่ยงการทำงานในปัญหานี้ ดูแบบแผนการตั้งชื่อที่น่าสนใจสำหรับชื่อเครื่องของประเภทเนื้อหาและฟิลด์ของคุณดังแสดงในตารางของWrapping Information Architecture และ Documentationซึ่งเป็นส่วนหนึ่งของบทความเกี่ยวกับ " Relativity Model for Drupal " สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับสิ่งนั้นโปรดอ้างถึงคำตอบของฉัน " ฉันจะจำลองเนื้อหา (ประเภท) จากมุมมองที่เป็นศูนย์กลางของฐานข้อมูลได้อย่างไร "

คุณสมบัติการแยกขึ้นอยู่กับว่าใครทำงานอะไร

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

• จำนวนการดูมีในคุณลักษณะ A
• กฎไปในฟีเจอร์ B
• ชาร์ตไปในฟีเจอร์ C
• อะไรก็ตามที่เกี่ยวกับชุดรูปแบบมีอยู่ในคุณสมบัติ D

4 - สภาพแวดล้อม Drupal ที่แนะนำ

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

• ผสานการทำงานโดยคุณสมบัติหลายอย่าง
• ทำนายและแก้ไขข้อขัดแย้ง
• การทดสอบผู้ใช้ปลายทางของคุณสมบัติที่รวมทั้งหมดซึ่งได้รับการรับรองว่าไม่มีข้อขัดแย้งใด ๆ

ในโลกอุดมคติเว็บไซต์ Drupal ที่เกี่ยวข้องกับเหตุผลควรได้รับการกำหนดค่าและใช้ดังนี้:

1. Personal Dev Site - นักพัฒนาเว็บไซต์แต่ละคนมีเว็บไซต์ dev แยกต่างหาก เมื่อส่วนหนึ่งของการพัฒนาพร้อมที่จะแบ่งปันกับคนอื่นคุณลักษณะที่เหมาะสมจะถูกสร้างขึ้นซึ่งถูกส่งไปยังสภาพแวดล้อมการจัดเตรียม
2. เว็บไซต์ Sandbox - นี่คือสภาพแวดล้อม Drupal ซึ่งมีแกน Drupal เท่านั้นที่ใช้ในการทดสอบความสมบูรณ์ของฟีเจอร์เดียว หากคุณสมบัติโดยบังเอิญมีการขึ้นต่อกันที่ไม่คาดคิด (เช่นโมดูลบางอย่างขึ้นอยู่กับคุณสมบัติซึ่งไม่ได้เปิดใช้งานใน Sandbox) ดังนั้นนี่คือที่ที่การพึ่งพานั้นจะชัดเจน
3. การแสดงละครไซต์ - ที่นี่เป็นสถานที่ส่งมอบฟีเจอร์อย่างน้อยหนึ่งรายการ (สร้างในไซต์ dev) อาจเป็นเพียงบางโปรแกรมแก้ไขด่วนสำหรับปัญหาการผลิตบางอย่างหรืออาจเป็นที่ที่การพัฒนาทั้งหมดสำหรับเว็บไซต์รุ่นใหม่ถูกรวมเข้าด้วยกัน หากมีข้อขัดแย้งระหว่างคุณลักษณะหลายอย่างอยู่นี่คือสภาพแวดล้อมที่พวกเขาจะปรากฏขึ้นครั้งแรก ... และต้องได้รับการแก้ไขอย่างใด
4. ไซต์ QA - หลังจากสภาพแวดล้อม Staging ถือว่ามีเสถียรภาพแล้วถึงเวลาที่ต้องดำเนินการต่อด้วยคุณสมบัติที่เกี่ยวข้องและทำให้พร้อมใช้งานในระดับที่สูงขึ้นซึ่งสามารถใช้สำหรับการทดสอบ QA การทดสอบการยอมรับการทดสอบระดับเสียง ฯลฯ ในระดับนี้ ควรระมัดระวังอย่างยิ่งในการอนุญาตการเปลี่ยนแปลงเพิ่มเติมใด ๆ (ถ้ามี) เนื่องจากการเปลี่ยนแปลงใด ๆ ดังกล่าวอาจทำให้การทดสอบก่อนหน้านี้ใช้ไม่ได้ในสภาพแวดล้อมนี้
5. ไซต์การผลิตเงา - เพื่อเตรียมการเปิดใช้งานในการผลิตจริงคุณอาจต้องการส่งเสริมคุณสมบัติที่เกี่ยวข้องกับสภาพแวดล้อมที่พิจารณาสำเนา (เงา) ของสภาพแวดล้อมการผลิตจริงของคุณก่อน หากมาถึงจุดนี้ในระหว่างกระบวนการโยกย้ายสิ่งใดก็ตามที่ยังคงหยุดพักแสดงว่าเป็นธงสีแดงเพื่อยกเลิกขั้นตอนก่อนหน้าของคุณบางส่วน แก้ไขให้ถูกต้องแล้วลองอีกครั้งจนกว่าทุกฝ่ายที่เกี่ยวข้องจะอนุมัติการเปลี่ยนแปลง
6. ไซต์การผลิต - ถ้าคุณทำตามขั้นตอนก่อนหน้าทั้งหมดแล้วขั้นตอนนี้ควรอธิบายด้วยตนเองและค่อนข้างง่าย ขึ้นอยู่กับความต้องการของคุณนี่อาจเป็นไซต์เดียวหรือบางสิ่งที่เทียบเท่ากับ Multi-sites ของ Drupal ในขณะที่เว็บไซต์ทั้งหมดที่เกี่ยวข้องกำลังเรียกใช้คุณสมบัติทั้งหมดในรุ่นเดียวกัน
7. ไซต์พื้นฐาน - จากประสบการณ์ของฉันมีการใช้งาน Drupal ไม่มาก (ถ้ามี) การใช้งานเว็บไซต์ประเภทนี้ (เช่นกัน) มันเป็นเพียงแค่สำเนาของไซต์การผลิต แต่พร้อมใช้งานสำหรับนักพัฒนา Drupal ผู้ทดสอบ ฯลฯ ที่สามารถใช้เพื่อตรวจสอบว่าไซต์การผลิตมีลักษณะอย่างไรหรือทำการฝึกอบรมผู้ใช้ ฯลฯ และทุกครั้งที่มีการพัฒนาใหม่ วงจรจะเริ่มต้นส่วนประกอบของเว็บไซต์ที่จะได้รับผลกระทบ (จำเป็นที่จะต้องมีการเปลี่ยนแปลง) ควรจะ "คัดลอกอย่างใด" โดยใช้พื้นฐานเว็บไซต์เป็น input ที่มีเป็นเป้าหมายการพัฒนาเว็บไซต์ส่วนตัว

เห็นได้ชัดว่ารายการสินค้าประเภทเว็บไซต์ Drupal ด้านบนนั้นเหมือนโลกในอุดมคติ ขึ้นอยู่กับขนาดของทีมพัฒนาของคุณและ / หรืองบประมาณที่มีอยู่เพื่อสร้างและบำรุงรักษาอาจไม่สามารถใช้งานได้ทั้งหมด (หรือราคาไม่แพง) สินค้าคงคลังนี้ได้รับการออกแบบตามหลักปฏิบัติที่ดีที่สุดในพื้นที่ของ SCM ซึ่งส่วนใหญ่ใช้ในองค์กรขนาดใหญ่ / ระดับโลกทั้งหมด (ธนาคารสายการบิน ฯลฯ )

5 - โมดูลที่เกี่ยวข้อง

แขนที่แข็งแรง

StrongArmโมดูลช่วยสำหรับการส่งออกตัวแปร (ของโมดูลซึ่งเก็บการตั้งค่าของพวกเขาในตัวแปร) ที่มีคุณสมบัติโมดูล

การส่งออกโหนด

ส่งออกโหนดโมดูลช่วยให้ผู้ใช้ไปยังต่อมน้ำการส่งออกและนำเข้ามันเข้าไปอีกการติดตั้ง Drupal

ส่งออกตามบทบาท

ส่งออกบทบาทโมดูลจะช่วยให้มีบทบาทสำคัญที่จะมี machine_names และสร้างรหัสบทบาทที่ไม่ซ้ำกัน (RID) ตามออกของ machine_name บทบาทสามารถส่งออกด้วยคุณลักษณะและรับการกำจัดที่แน่นอนหากนำเข้าบนเว็บไซต์อื่น

คุณสมบัติขับไล่

คุณสมบัติ Banishโมดูลช่วยให้สมบูรณ์ไม่รวมส่วนประกอบคุณลักษณะบุคคลจากองค์ประกอบ UI และคุณสมบัติการส่งออก นี่คือคำพูดเกี่ยวกับมันจากหน้าโครงการ:

 โมดูลนี้มีประโยชน์เมื่อมีองค์ประกอบของคุณสมบัติที่คุณต้องการให้แน่ใจว่าไม่เคยถูกส่งออก หากคุณกำลังใช้ฟีเจอร์สำหรับการสร้างเว็บไซต์หรือการใช้งานคุณอาจพบเจอกับคนที่ส่งออกตัวแปรเวลาประทับเช่น cron_last หรือ update_last_check โดยไม่ตั้งใจ คุณอาจต้องการขับไล่การอนุญาตสำหรับโมดูลผู้พัฒนาเพื่อไม่ให้ถูกต้องตามส่วนที่เหลือของการอนุญาตไซต์ที่คุณต้องการส่งออก รายการที่ถูกเนรเทศจะไม่แสดงในโมดูลคุณลักษณะของคุณหรือโมดูลคุณสมบัติอื่นใด ๆ ดังนั้นควรใช้ด้วยความระมัดระวัง สำหรับรายการคุณลักษณะกลางที่ไม่ควรส่งออกโปรดดูที่https://www.drupal.org/node/2400531

ถั่ว

Beanโมดูลทำให้บล็อกของคุณสามารถส่งออกได้ นี่คือคำพูดเกี่ยวกับมันจากหน้าโครงการ:

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

โมดูลนี้ยังใช้งานได้ดีร่วมกับUUIDและUUID คุณลักษณะการรวมโมดูล โมดูลนี้เริ่มต้นตั้งแต่ D7 แต่ได้รวมอยู่ใน Drupal 8 คอร์แล้ว วิดีโอสอนการใช้งานโมดูล Drupal Bean กวดวิชา - การใช้ Bean Admin UIให้การแนะนำที่ยอดเยี่ยมเพื่อทำความเข้าใจถึงพลังของโมดูลนี้และสิ่งต่าง ๆ ที่คุณสามารถทำได้ (โดยใช้เทคนิคการสร้างเว็บไซต์เท่านั้น

ที่อยู่อาศัย

ที่อยู่อาศัยโมดูลทำให้รู้สึกมากที่สุดในคุณสมบัติเวิร์กโฟลว์ชั่น นี่คือคำพูดเกี่ยวกับมันจากหน้าโครงการ:

ในการตั้งค่าหลายสภาพแวดล้อม (เช่น prod, ทดสอบ, dev, local) มีบางโมดูลที่คุณต้องการเปิดใช้งานหรือปิดการใช้งานในบางสภาพแวดล้อม ทุกครั้งที่คุณซิงค์ฐานข้อมูลลงแม้ว่าคุณจะต้องเปิดใช้งาน / ปิดการใช้งานโมดูลเดิมอีกครั้ง ที่แย่กว่านั้นคือคุณขี้เกียจและเปิดใช้งานโมดูลการพัฒนาต่อไปในการผลิต

ที่อยู่อาศัยให้การตั้งค่าเพื่อเปิดใช้งานหรือปิดใช้งานโมดูลบางอย่างในแต่ละสภาพแวดล้อม (ที่อยู่อาศัย) เพียงแค่ตั้งค่าตัวแปรด้วยเช่น $ conf ['habitat'] = 'local'; ในไฟล์ settings.php ของคุณ (ตัวแปรจริงที่ใช้มีการกำหนดค่าสำหรับเวิร์กโฟลว์ปัจจุบันของคุณ) โมดูลปิดการใช้งาน / เปิดใช้งานจะทำใน hook_init

6 - ทรัพยากรที่แนะนำ:

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

7 - ทางเลือกที่เป็นไปได้ในการใช้คุณสมบัติ

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

ส่งออก / นำเข้าด้วยตนเอง

สิ่งอำนวยความสะดวกเหล่านี้เป็นที่รู้จักกันทั่วไป (เพื่อหลีกเลี่ยงคุณสมบัติคำ... ) ที่มีให้ผ่านทาง UI การดูแลระบบสำหรับโมดูลเช่นกฎ , มุมมอง , ฯลฯ (รายการที่ไม่สมบูรณ์!)

สำเนาบันเดิล

บางคนพิจารณาว่าโมดูลสำเนาของบันเดิลนั้นเป็นทางเลือกที่เป็นไปได้ มีการสนับสนุนการส่งออก / นำเข้าสำหรับ:

• ประเภทโหนด
• อนุกรมวิธาน
• ผู้ใช้งาน
• ฟิลด์ API ฟิลด์
• กลุ่มฟิลด์

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

กระทำการเปลี่ยนแปลงรหัสที่ตั้งใจไว้เท่านั้น

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

• git diffเปลี่ยนแปลงรหัสทบทวนด้วย
• สร้างแพทช์ diff ด่วนโดยใช้git diff > blah.patchและแก้ไขแพทช์ด้วยตนเองเพื่อรวมการเปลี่ยนแปลงการกำหนดค่าที่ต้องการเท่านั้น
  • สิ่งต่าง ๆ เช่น "mtime" ความคิดเห็นในมุมมองการส่งออกในไฟล์ข้อมูลไม่จำเป็นต้องรวมอยู่ในการส่งข้อมูล
  • ฉันค่อนข้างเชี่ยวชาญในการตรวจสอบบล็อกของรหัสการกำหนดค่าที่แตกต่างกันในช่วงเวลา ตอนนี้มันง่ายกว่าที่จะเห็นการเปลี่ยนแปลงที่ไม่จำเป็นในมุมมองหรือพาเนลและความรวดเร็ว10ddในการกำจัดการเปลี่ยนแปลงในแพทช์ (ตัวอย่าง)
  • ฉันคิดว่า "เฮ้เฮ้ฉันไม่ได้เปลี่ยนอะไรเลยกับทุ่งนาดังนั้นฉันจะไม่ยอมfeaturename.features.field_base.inc"
• git commit -aไม่เคยใช้งาน นี่คือการปฏิบัติที่น่ากลัวที่ควรได้รับจากการใช้งาน เพิ่มและกระทำอย่างชัดเจนเสมอ!
• ใช้git rebaseในสาขา git ท้องถิ่นเพื่อให้แน่ใจว่าคุณสมบัติเป็นรุ่นล่าสุด
• กลยุทธ์การรวมคอมไพล์อาจช่วยเมื่อทำการผสานจริง:
  • git merge -s recursive -X patience (ต้องการ git 1.7+ iirc)

ในที่สุดให้พิจารณาการเพิ่มข้อ จำกัด ทางสังคมให้กับนักพัฒนาเพื่อให้นักพัฒนาจะต้องมีการตรวจสอบรหัสของพวกเขาก่อนที่จะรวมเข้ากับ trunk / เสถียรทั้งกับการตรวจสอบแก้ไขหรือดึงคำขอ ผู้คนจะโกรธเกี่ยวกับข้อ จำกัด ทางสังคม แต่พวกเขาควรจะโกรธตัวเองที่ไม่อ่านรหัสของพวกเขา