ฉันจะเริ่มใช้ Git สำหรับการทำรหัสฐานที่แตกต่างจากเซิร์ฟเวอร์ต่าง ๆ ได้อย่างไร

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

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

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

คำถาม:วิธีที่ดีที่สุดสำหรับฉันในการจัดระเบียบและย้ายสิ่งเหล่านี้ไปยัง Git คืออะไร? ฉันจะจัดโครงสร้าง repos / สาขาของฉันเพื่อรองรับความแตกต่างในรหัสได้อย่างไร

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

ผลักสิ่งที่ผลิตลงในmasterสาขาของ repo ใหม่ สร้างdevelopสาขาจากนั้นรวมเซิร์ฟเวอร์ staging เข้าด้วยกัน คุณอาจจบลงด้วยความขัดแย้งที่ต้องได้รับการแก้ไข เมื่อแก้ไขแล้วให้สร้างเซิร์ฟเวอร์อื่นfeature_branchจากนั้นdevelopรวมเซิร์ฟเวอร์การพัฒนาเข้าด้วยกัน แก้ไขข้อขัดแย้งใด ๆ ที่เกิดขึ้น

สิ่งนี้ทำให้คุณมี 3 สาขาซึ่งเป็นตัวแทนของการผลิตการจัดเตรียมและสภาพแวดล้อมการพัฒนาของคุณ ผลิต -> masterแสดงละคร -> developการพัฒนา feature_branch-> การพัฒนาทั้งหมดจึงเกิดขึ้นfeature_branchesและรวมเข้ากับdevelopสาขาเมื่อคุณสมบัติเสร็จสิ้นการทดสอบและมีเสถียรภาพ เนื่องจากมีความเสถียรจึงสามารถใช้เป็น staging ได้ ตัดreleaseสาขาจากdevelopเมื่อคุณพร้อมที่จะปล่อยผูกปลายหลวมรวมเข้าmasterด้วยกันแล้วคุณมีงานสร้างใหม่ของคุณ

หนึ่งในคำสั่งซื้อธุรกิจแรกของคุณหลังจากการตั้งค่านี้ควรจะรวมfeature_branchด้านหลังเข้ากับdevelop* แล้วdevelopกลับเข้าmasterมา จำไว้ว่าfeature_branchอาจมีรหัสยังไม่ทดลองและคุณสมบัติเพื่อให้ระมัดระวังการออกกำลังกายเมื่อผสานลงในแล้วdevelop masterเมื่อทำเสร็จแล้วทุกสาขาควรมีรหัสเดียวกันและการพัฒนาใด ๆ ที่ทำบนเซิร์ฟเวอร์ที่ใช้งานจริงจะได้รับการย้ายกลับสู่การพัฒนา "เซิร์ฟเวอร์"

ในโมเดลนี้แต่ละโครงการจะอยู่ใน repo ของตนเองและ repo นั้นจะมีmasterและdevelopสาขารวมถึงfeature_branchesงานที่ทำเสร็จ

แก้ไขเพื่อแก้ไขความคิดเห็น: ใช่นี่คือ Gitflow

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

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

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

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

ดังนั้นตรวจสอบstagingรหัสของคุณในstagingสาขาจากนั้นทำgit checkout -b master stagingเพื่อสร้างmasterสาขาของคุณและตรวจสอบรหัสการผลิตของคุณที่นั่น จากนั้นทำgit checkout -b development stagingเพื่อสร้างdevelopmentสาขาของคุณและตรวจสอบรหัสการพัฒนาของคุณลงไปที่นั่น

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

มันเป็นความคิดที่ดีที่จะมีประวัติศาสตร์ ฉันจะสร้างพื้นที่เก็บข้อมูล (หรือหนึ่งสำหรับแต่ละผลิตภัณฑ์) จากสภาพแวดล้อมที่มั่นคงที่สุด สร้างสาขาหรือความแตกต่างสำหรับคนอื่น ๆ

ในระดับสูง:

1. สร้าง repo ใหม่
2. จากสำเนาการทำงานที่ใช้งานจริง: เพิ่มทั้งหมดกระทำและพุช
3. ชำระเงินหลักไปยังไดเรกทอรีใหม่
4. สำหรับแต่ละสภาพแวดล้อมเพิ่มเติม XYZ
   1. สร้างสาขา Archive-XYZ
   2. แทนที่ทุกอย่างด้วยXYZแหล่งที่มา (ยกเว้น. git)
   3. เพิ่มทั้งหมดกระทำและกด

อีกทางเลือกหนึ่งถ้าคุณสงสัยในคุณค่าของสิ่งนี้git diff > XYZ.diffแทนที่จะมุ่งมั่นและผลักดันและเก็บส่วนต่าง

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