แบบจำลองความสำเร็จของสาขาใน Git

การใช้ Git เป็นสิ่งสำคัญ, และรักษาสภาพแวดล้อมร่วมกันพัฒนาซอฟต์แวร์จัดการ.

เครดิต

โพสต์นี้เป็นต้นฉบับฉบับภาษาโปรตุเกส, ในภาษาอังกฤษ, “โมเดลการโยง Git ที่ประสบความสําเร็จ“, ได้รับอนุญาตอย่างถูกต้องโดยผู้เขียน, วินเซนต์ ดรีสเซ่น. ขอบคุณผู้ชาย!

ด้วยเหตุผลทางเทคนิค, คําหลักบางคําถูกเก็บไว้เป็นภาษาอังกฤษอย่างจงใจ. ฉันพยายามให้แน่ใจว่าความคิดริเริ่มของข้อความ, แต่ฉันสารภาพว่าฉันต้องปรับเปลี่ยนเพื่ออํานวยความสะดวกในการทําความเข้าใจในภาษาของเรา (EN-BR (เอ็น-บีอาร์)). การแก้ไขหรือข้อเสนอแนะของการปรับปรุงใด ๆ ในการแปลยินดีต้อนรับ.

แนะนำ

นี่ไม่ใช่โพสต์สอนวิธีใช้ Git. หากนี่คือสิ่งที่คุณต้องการ, แนะนําให้ดูที่ คู่มือทํา Git. นอกจากนี้ยังไม่ใช่เป้าหมายของเราที่จะแสดงวิธีการทําซอฟต์แวร์เวอร์ชัน, ในกรณีนี้, ดู การกําหนดเวอร์ชันความหมาย.

ที่นี่ข้อเสนอคือการจัดการการทํางานร่วมกันของทีมในซอฟต์แวร์การกําหนดเวอร์ชัน. คุณรู้ว่าเมื่อคุณมีโปรแกรมเมอร์หลายคน “กวน” ในซอร์สโค้ดเดียวกัน? นี่เป็นสิ่งสําคัญเพื่อเร่งการพัฒนา, แต่มันสามารถสร้างอาการปวดหัวได้มาก (การบาดเจ็บและการทําใหม่) ถ้าไม่มีการควบคุม. เพื่อป้องกันไม่ให้นักพัฒนาคนหนึ่งเขียนทับงานของผู้อื่นและสร้างความมั่นใจในการพัฒนาที่ก้าวหน้าและเป็นระเบียบ, ลดความขัดแย้งและการจัดการเวอร์ชันซอฟต์แวร์ให้เล็กๆ, คือเราใช้ Git และ สาขา จากนั้น.

รูปแบบสาขา

ในโพสต์นี้ฉันนําเสนอรูปแบบการพัฒนาที่ฉันใช้ในบางโครงการของฉัน (ทั้งในที่ทํางานและส่วนตัว) เกี่ยวกับของ 1 ปี มาแล้ว, และนั่นประสบความสําเร็จอย่างมาก. ฉันอยากจะเขียนเกี่ยวกับเรื่องนี้มานานแล้ว, แต่ไม่พบเวลาว่าง, จนถึงตอนนี้. ฉันจะไม่พูดถึงรายละเอียดโครงการ, เพียงเกี่ยวกับกลยุทธ์ของ สาขา และการจัดการของ รุ่น.

รุ่นนี้มุ่งเน้นเฉพาะใน กิต เป็นเครื่องมือสําหรับการกําหนดเวอร์ชันซอร์สโค้ดทั้งหมดของเรา. (ยังไงก็ตาม, หากคุณสนใจ git, บริษัทของเรา กิตพรีม แสดง, ในเวลาจริง, การวิเคราะห์ข้อมูลที่น่าทึ่งสําหรับการเพิ่มประสิทธิภาพวิศวกรรมซอฟต์แวร์)

ทําไมต้อง git?

สําหรับการอภิปรายอย่างละเอียดเกี่ยวกับข้อดีและข้อเสียของ git เมื่อเทียบกับระบบควบคุมแหล่งที่มาแบบรวมศูนย์, ดู มี เว็บ. มีมหาศาล “สงคราม” รอบๆนั้น. ในฐานะนักพัฒนา, ฉันชอบ Git มากกว่าเครื่องมือที่มีอยู่อื่น ๆ ทั้งหมดในปัจจุบัน. Git ได้เปลี่ยนวิธีคิดของนักพัฒนาอย่างไม่ต้องสงสัยเกี่ยวกับการทํา เวียน หรือสร้าง สาขา. ฉันมาจากโลกคลาสสิกของ CVS/การกลับตัว, ที่ การรวม/การโยงสาขา มันเป็นสิ่งที่คุณทําเพียงครั้งเดียวในขณะที่และมักจะดูน่ากลัวเล็ก ๆ น้อย ๆ (“ระวังความขัดแย้งของ เวียน, พวกเขากัดคุณ!”).

ด้วย Git การกระทําเหล่านี้ [การรวม/การโยงสาขา] ง่ายมากและเป็นตัวแทนของหนึ่งในส่วนหลักของกิจวัตรการทํางานของเรา, เชื่อ. ตัวอย่างเช่น, นิ้ว จอง CSV/การกลับตัว, การโยงสาขา และ ผสาน ได้รับการแก้ไขเป็นครั้งแรกเฉพาะในบทต่อมาเท่านั้น (สําหรับผู้ใช้ขั้นสูง), ในขณะที่อยู่ใน จองบน Git, สิ่งนี้เห็นในบท 3 (พื้นฐาน).

เป็นผลมาจากความเรียบง่ายและธรรมชาติซ้ํา ๆ, การโยงสาขา และ ผสาน ไม่ใช่สิ่งที่ต้องกลัวอีกต่อไป. จริง, เครื่องมือควบคุมเวอร์ชันควรช่วยสร้างเวียน และสร้าง สาขา มากกว่าสิ่งอื่นใด.

ไม่ต้องพูดแล้ว, ลองไปที่รูปแบบการพัฒนา. โมเดลที่ฉันจะนําเสนอที่นี่ไม่มีอะไรมากไปกว่าชุดของขั้นตอนที่สมาชิกในทีมแต่ละคนต้องปฏิบัติตามเพื่อสร้างกระบวนการพัฒนาซอฟต์แวร์ที่มีการจัดการ.

กระจายอํานาจ, แต่รวมศูนย์

การกําหนดค่าของที่เก็บที่เราใช้และทํางานได้ดีกับรุ่นนี้ของ การโยงสาขา ประกอบด้วยที่เก็บส่วนกลาง. โปรดสังเกตว่าที่เก็บนี้เป็นเพียง “ถือเป็น” เซ็นทรัล (เพราะ Git เป็น DVCS [ระบบควบคุมเวอร์ชันแบบกระจาย], IE, ไม่มีอะไรที่เหมือนกับที่เก็บข้อมูลส่วนกลางในระดับเทคนิค). เราจะอ้างอิงที่เก็บนี้เป็น แหล่ง กำเนิด สินค้า, เนื่องจากชื่อนี้คุ้นเคยกับผู้ใช้ Git ทุกคน.

นักพัฒนาแต่ละคนทํา ดึง และ ผลัก ดัน สำหรับการ แหล่ง กำเนิด สินค้า. แต่นอกเหนือจากความสัมพันธ์ ผลักดัน- ดึง สําหรับส่วนกลาง [แหล่ง กำเนิด สินค้า], นักพัฒนาแต่ละคนสามารถรับ [ดึง] การเปลี่ยนแปลงของคู่อื่นๆ เพื่อสร้างเป็นผลรวมย่อย. ตัวอย่างเช่น, สิ่งนี้มีประโยชน์ในการทํางานร่วมกับนักพัฒนาสองคนขึ้นไปในฟังก์ชั่นใหม่ที่ยอดเยี่ยม, การส่งก่อนหน้านี้ [ผลัก ดัน] งานที่กําลังดําเนินการอยู่สําหรับ แหล่ง กำเนิด สินค้า. ในภาพด้านบน, มีอลิลและบ็อบเป็นซับทีม, อลิซและเดวิด, และแคลร์และเดวิด.

ทาง เทคนิค, ซึ่งหมายความว่าไม่มีอะไรมากไปกว่าอลิซได้กําหนด Git ระยะไกลที่เรียกว่าบ๊อบ, ชี้ไปที่ที่เก็บของบ็อบ, และในทางกลับกัน.

สาขาหลัก

ในพื้นหลัง, รูปแบบการพัฒนานี้ค่อนข้างได้รับแรงบันดาลใจจากโมเดลที่มีอยู่. พื้นที่เก็บข้อมูลส่วนกลางมีสองสาขา [สาขา] ด้วยชีวิตที่ไม่มีที่สิ้นสุด:

  • หลัก
  • พัฒนา

การ ต้นแบบสาขา ใน แหล่ง กำเนิด สินค้า ต้องคุ้นเคยกับผู้ใช้ Git ทุกคน. ขนานกับ ต้นแบบสาขา, มีอีก สาขา เรียก พัฒนา.

พิจารณา ต้นทาง/หลัก เป็นสาขาหลักที่ซอร์สโค้ดของ หัว สะท้อนสถานะเสมอ การผลิต- พร้อม [พร้อมสําหรับการผลิต].

พิจารณา กําเนิด/พัฒนา เป็น สาขา ที่รหัสแหล่งที่มาของ หัว สะท้อนสถานะที่มีการเปลี่ยนแปลงการพัฒนาล่าสุดที่จะส่งมอบในรุ่นถัดไปเสมอ. บางคนจะเรียกสิ่งนี้ “สาขา รวม”. นั่นคือที่ที่อาคารที่ชั่วร้ายที่สุดเกิดขึ้น.

เมื่อซอร์สโค้ดในหน้าต่าง สาขาพัฒนา ถึงจุดที่มั่นคงและพร้อมที่จะเปิดตัว [เผย แพร่], ต้องผสานการเปลี่ยนแปลงทั้งหมด [ผสาน] กลับไปที่หน้าต่าง ต้นแบบสาขา แล้วทําเครื่องหมายด้วยหมายเลขเวอร์ชัน [ปล่อย]. วิธีการทําเช่นนี้ในรายละเอียด, จะมีการหารือในภายหลัง.

ดังนั้น, ทุกครั้งที่มีการรวมการเปลี่ยนแปลง [ผสาน] กลับไปที่หน้าต่าง หลัก, เวอร์ชันใหม่จะถูกสร้างขึ้น [เผย แพร่], ตามคําจํากัดความ. เราพยายามค่อนข้างเข้มงวดเกี่ยวกับเรื่องนี้, ดังนั้น, ในทางทฤษฎี, เราสามารถใช้สคริปต์ได้ ตะขอ เพื่อสร้างและส่งแอปพลิเคชันของเราไปยังเซิร์ฟเวอร์การผลิตโดยอัตโนมัติเมื่อใดก็ตามที่มี ยืนยัน นิ้ว หลัก.

สาขาเสริม

ถัดจาก สาขา หลัก, หลัก และ พัฒนา, รูปแบบการพัฒนาของเราใช้ความหลากหลายของ สาขา สนับสนุนเพื่อช่วยในการพัฒนาพร้อมกันในหมู่สมาชิกในทีม, อะไรนะ 1) ทําให้ง่ายต่อการติดตามคุณสมบัติใหม่ [คุณสมบัติ], 2) เตรียมพร้อมสําหรับการจัดส่งเวอร์ชันใหม่ [ปล่อย] และ 3) ช่วยให้คุณแก้ไขความล้มเหลวของการผลิตได้อย่างรวดเร็ว [โปรแกรม แก้ไข ด่วน]. ไม่เหมือน สาขา หลัก, เหล่า นี้ สาขา มีเวลาชีวิตสั้น, เนื่องจากในที่สุดพวกเขาจะถูกลบออก.

ชนิดต่าง ๆ ของ สาขา [เสริม] ที่เราสามารถใช้, เป็น:

  • สาขาเด่น
  • นําสาขาออกใช้
  • สาขาโปรแกรมแก้ไขด่วน

แต่ละสิ่งเหล่านี้ สาขา มีวัตถุประสงค์เฉพาะและผูกพันตามกฎที่เข้มงวด, เพื่อให้, สาขา อาจก่อให้เกิด สาขา และนั่น สาขา ต้องผสาน [ผสาน] ไปยังเป้าหมายของพวกเขา. เราจะได้เห็นพวกเขาแต่ละคน [สาขา] ในทันที.

จากมุมมองทางเทคนิค, เหล่า นี้ สาขา ไม่ได้รับการพิจารณา “พิเศษ”. แต่ละชนิดของ สาขา จัดอยู่ในประเภทตามวิธีที่เราใช้. อย่างไรก็ตาม, เรียบง่าย สาขา ของ Git เก่าที่ดี.

สาขาเด่น

[คุณสมบัติ = คุณสมบัติ / คุณสมบัติ]

– มันสามารถแตกแขนง [สาขา] จาก:
พัฒนา
– ต้องผสาน [เวียน] อีกครั้ง:
พัฒนา
– อนุสัญญาว่าด้วยการแต่งตั้ง สาขา:
อะไร, ยก เว้น หลัก, พัฒนา, ปล่อย-*, หรือ หรือ โปรแกรมแก้ไขด่วน-*

Os สาขาเด่น (หรือบางครั้งเรียกว่า สาขาหัวข้อ) ใช้ในการพัฒนาคุณลักษณะ/ฟังก์ชันการทํางานใหม่สําหรับรุ่นใกล้หรือในอนาคต. เมื่อเริ่มต้นการพัฒนาของ คุณลักษณะ, รุ่นเป้าหมายที่คุณลักษณะนี้จะถูกรวมเข้าด้วยกันอาจไม่เป็นที่รู้จักในจุดนั้น.

แก่นแท้ของ สาขาเด่น คือมีอยู่ตราบเท่าที่ คุณลักษณะ อยู่ระหว่างการพัฒนา, แต่ในที่สุดมันจะถูกรวมเข้าด้วยกัน [ผสาน] กลับไปที่หน้าต่าง พัฒนา (เพิ่มใหม่อย่างแน่นอน คุณลักษณะ ไปยังรายการถัดไป ปล่อย) หรือละทิ้ง (ในกรณีของการทดลองที่ไม่ประสบความสําเร็จ).

สาขาเด่น โดยทั่วไปจะมีอยู่ในที่เก็บเท่านั้น พัฒนา, ไม่อยู่ใน แหล่ง กำเนิด สินค้า.

การสร้างสาขาคุณลักษณะ

$ การชําระเงิน git -ข พัฒนา myfeature
# Switched to a new branch "myfeature"

การรวมคุณสมบัติสําเร็จรูปในการพัฒนา

คุณสมบัติ เสร็จสามารถผสาน[ผสาน] ด้วย สาขาพัฒนา เพิ่มพวกเขาไปยังรายการถัดไปอย่างแน่นอน ปล่อย.

$ gitเช็คเอาต์พัฒนา
# เปลี่ยนเป็นสาขา 'พัฒนา'
$ ผสาน git --นิ้ว-ff myfeature (ff ไมเฟอเรต
# กําลังปรับปรุง ea1b82a.. 05e9557
# (สรุปการเปลี่ยนแปลง)
# $ สาขา git -d myfeature
# ลบสาขา myfeature (คือ 05e9557).
$ gitผลักดันกําเนิดพัฒนา

แฟล็ก –ไม่มี- ff ทําให้เกิดการผสาน [เวียน] สร้างวัตถุใหม่ของ ยืนยัน, แม้ว่าการผสานสามารถดําเนินการกับ กรอไปข้างหน้า [Ff]. วิธีนี้จะป้องกันไม่ให้ข้อมูลสูญหายเกี่ยวกับประวัติการดํารงอยู่ของ สาขาคุณลักษณะ, การจัดกลุ่มทั้งหมด ยอมรับ ที่ถูกเพิ่มไปยัง คุณลักษณะ. เปรียบ เทียบ:

ในกรณีหลัง [จากรูปด้านบน], มันเป็นไปไม่ได้ที่จะเห็นจากประวัติศาสตร์ git ซึ่งของ ยอมรับ ได้ถูกนํามาใช้ภายใน คุณลักษณะ; คุณต้องอ่านข่าวสารล็อกทั้งหมดด้วยตนเอง. ย้อนกลับ คุณลักษณะ ทั้ง หมด (IE, กลุ่มของ ยอมรับ), มันเป็นอาการปวดหัวที่แท้จริงในสถานการณ์ที่ผ่านมา, ในขณะที่มันทําได้อย่างง่ายดายถ้าธง –ไม่มี- ff มีการใช้แล้ว.

ใช่, การดําเนินการนี้จะสร้างวัตถุอีกสองสามอย่างของ ยอมรับ (ว่าง เปล่า), แต่กําไรสูงกว่าต้นทุนมาก.

นําสาขาออกใช้

[นําออกใช้ = นําออกใช้/จัดส่ง/เวอร์ชัน]

– มันสามารถแตกแขนง [สาขา] จาก:
พัฒนา
– ต้องผสาน [เวียน] อีกครั้ง:
พัฒนา และ หลัก
– อนุสัญญาว่าด้วยการแต่งตั้ง สาขา:
ปล่อย-*

Os ออกสาขา ช่วยเตรียมเวอร์ชันการผลิตใหม่ [การนําการผลิตออกใช้]. พวกเขาช่วยให้คุณสามารถใส่หยดในนาทีสุดท้ายที่ฉันเป็น. นอกจากนี้, พวกเขาอนุญาตให้มีการแก้ไขเล็กน้อยของ ข้อ บกพร่อง และคําจํากัดความของ เมตาดาต้า สําหรับ ปล่อย (หมายเลขรุ่น, วันที่สร้าง, ฯลฯ). โดยการทํางานทั้งหมดนี้ใน นําสาขาออกใช้, การ พัฒนาสาขา ได้รับการทําความสะอาดที่จะได้รับ คุณสมบัติ ของใหญ่ต่อไป ปล่อย [เวอร์ชัน].

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

มันอยู่ที่จุดเริ่มต้นของ นําสาขาออกใช้ ว่าต่อไป ปล่อย รับหมายเลขรุ่น – ไม่ใช่ก่อนหน้านี้. จนถึงจุดนั้น, การ พัฒนาสาขา การเปลี่ยนแปลงที่สะท้อนไปยัง “รุ่นถัดไป” [รุ่นถัดไป], แต่ยังไม่ชัดเจนว่า “รุ่นถัดไป” ในที่สุดจะเป็น 0.3 หรือ 1.0, จนกระทั่ง นําสาขาออกใช้ เริ่มต้นแล้ว. การตัดสินใจนี้จะดําเนินการในตอนต้นของ นําสาขาออกใช้ และดําเนินการโดยกฎโครงการเกี่ยวกับการกําหนดเวอร์ชัน [ฉันขอแนะนําให้ดูเกี่ยวกับ “การกําหนดเวอร์ชันความหมาย“].

การสร้างสาขาที่นําออกใช้

Os ออกสาขา สร้างขึ้นจาก พัฒนาสาขา. ตัวอย่างเช่น, สมมติว่าเวอร์ชัน 1.1.5 เป็นรุ่นการผลิตในปัจจุบันและเรามีที่ดี ปล่อย มา. สถานะของ พัฒนา พร้อมสําหรับ “รุ่นถัดไป” [รุ่นถัดไป] และเราตัดสินใจว่านี่จะกลายเป็นรุ่น 1.2 (แทนที่ 1.1.6 หรือ 2.0). ดังนั้น, เราแตกแขนงออกและให้ นําสาขาออกใช้ ชื่อที่สะท้อนถึงหมายเลขเวอร์ชันใหม่:

$ การชําระเงิน git -ปล่อย b-1.2 พัฒนา
# Switched to a new branch "release-1.2"
$ ./ชน-เวอร์ชัน.Sh 1.2
# ปรับเปลี่ยนแฟ้มเสร็จเรียบร้อยแล้ว, รุ่นชนกับ 1.2.
$ git กระทํา -มี -"Bumped version number to 1.2"
# [ปล่อย-1.2 74d9424] หมายเลขเวอร์ชันที่ถูกกระแทกไปยัง 1.2
# 1 ไฟล์ที่เปลี่ยนแปลง, 1 แทรก(+), 1 ลบ(-)

หลังจากสร้าง สาขา และเข้าถึงมัน, เราชนกับหมายเลขรุ่น. ที่นี่, bump-version.sh เป็นเชลล์สคริปต์ที่เปลี่ยนแฟ้มสําเนาการทํางานบางแฟ้มเพื่อให้สอดคล้องกับรุ่นใหม่. (สิ่งนี้สามารถ, แน่นอน, เป็นการเปลี่ยนแปลงด้วยตนเอง – ประเด็นคือบางไฟล์มีการเปลี่ยนแปลง) ดังนั้น, เสร็จสิ้น ยืนยัน ของหมายเลขรุ่นที่แก้ไข.

นี้ใหม่ สาขา อาจมีอยู่ที่นั่นในขณะที่, จนกระทั่ง ปล่อย เปิดตัวอย่างถาวร. ในช่วงเวลานี้, การแก้ไขข้อบกพร่องสามารถนํามาใช้ในการนี้ สาขา (แทนที่จะเป็น พัฒนาสาขา). การเพิ่มใหม่และขนาดใหญ่ คุณสมบัติ ที่นี่เป็นที่ห้ามโดยเคร่งครัด. ต้องผสานเข้าด้วยกัน [ผสาน] ใน พัฒนา และ, แบบนี้, รอใหญ่ต่อไป ปล่อย.

การสรุปสาขาที่วางจําหน่าย

เมื่อ นําสาขาออกใช้ พร้อมที่จะเป็นเวอร์ชันจริง, จําเป็นต้องดําเนินการบางอย่าง. ครั้งแรก, การ นําสาขาออกใช้ ถูกผสานเป็น หลัก (ตั้งแต่แต่ละ ยืนยัน นิ้ว หลัก เป็นรุ่นใหม่ตามข้อกําหนด, จำ). จากนั้น, นี้ ยืนยัน นิ้ว หลัก ควรทําเครื่องหมายเพื่ออํานวยความสะดวกในการอ้างอิงในอนาคตถึงประวัติรุ่นนี้. ในที่สุด, การเปลี่ยนแปลงที่ทํากับ นําสาขาออกใช้ จําเป็นต้องถูกผสาน [ผสาน] อีกครั้งเพื่อ พัฒนา, เพื่อให้ รุ่น ฟิวเจอร์สยังมีการแก้ไขข้อบกพร่องเหล่านี้.

สองขั้นตอนแรกใน Git:

$ ต้นแบบการชําระเงิน git
# เปลี่ยนเป็น 'ต้นแบบ' สาขา
$ ผสาน git --นิ้ว-ปล่อย ff-1.2
# ผสานโดยการสอบถามซ้ํา.
# (สรุปการเปลี่ยนแปลง)
$ แท็ก git -มี 1.2

การ ปล่อย ขณะนี้เสร็จสมบูรณ์แล้วและทําเครื่องหมายสําหรับการอ้างอิงในอนาคต.

หมายเหตุ: คุณยังสามารถใช้ค่าสถานะ -s หรือ -u เมื่อต้องการเซ็นชื่อในแท็กของคุณอย่างเข้ารหัส.

เมื่อต้องการเก็บการเปลี่ยนแปลงที่ทํากับ นําสาขาออกใช้, เราต้องนําพวกเขากลับมารวมกัน พัฒนา. แอท กิต:

$ gitเช็คเอาต์พัฒนา
# เปลี่ยนเป็นสาขา 'พัฒนา'
$ ผสาน git --นิ้ว-ปล่อย ff-1.2
# ผสานโดยการสอบถามซ้ํา.
# (สรุปการเปลี่ยนแปลง)

ขั้นตอนนี้สามารถนําไปสู่ข้อขัดแย้งในการผสาน (อาจจะไป, เมื่อเราเปลี่ยนหมายเลขรุ่น). ถ้าเป็นเช่นนั้น, แก้ไขและทําให้ ยืนยัน.

ตอนนี้, ว่าเราจบกันจริงๆ, การ นําสาขาออกใช้ สามารถลบออกได้, เพราะเราจะไม่ต้องการมันอีกต่อไป:

$ สาขากิต -d ปล่อย-1.2
# ลบรุ่นสาขา-1.2 (คือ ff452fe).

สาขาโปรแกรมแก้ไขด่วน

– มันสามารถแตกแขนง [สาขา] จาก:
หลัก
– ต้องผสาน [เวียน] อีกครั้ง:
พัฒนา และ หลัก
– อนุสัญญาว่าด้วยการแต่งตั้ง สาขา:
โปรแกรมแก้ไขด่วน-*

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

สาระสําคัญคือการทํางานของสมาชิกในทีม (นิ้ว พัฒนาสาขา) สามารถดําเนินการต่อได้, ในขณะที่คนอื่นกําลังเตรียมการแก้ไขอย่างรวดเร็วของความล้มเหลวของการผลิต.

การสร้างสาขาโปรแกรมแก้ไขด่วน

Os สาขาโปรแกรมแก้ไขด่วน สร้างขึ้นจาก สาขาหลัก. ตัวอย่างเช่น, สมมติว่าเป็นเวอร์ชัน 1.2 เป็นรุ่นปัจจุบันของรุ่นที่วางจําหน่ายและนําเสนอปัญหาเนื่องจากข้อผิดพลาดร้ายแรง. การเปลี่ยนแปลงใน พัฒนา ปล่อยให้ยังไม่เสถียร. จากนั้นเราสามารถแตกแขนง โปรแกรมแก้ไขด่วนสาขา และเริ่มแก้ไขปัญหา:

$ การชําระเงิน git -b โปรแกรมแก้ไขด่วน-1.2.1 หลัก
# Switched to a new branch "hotfix-1.2.1"
$ ./ชน-เวอร์ชัน.Sh 1.2.1
# ปรับเปลี่ยนแฟ้มเสร็จเรียบร้อยแล้ว, รุ่นชนกับ 1.2.1.
$ git กระทํา -มี -"Bumped version number to 1.2.1"
# [โปรแกรมแก้ไขด่วน-1.2.1 41e61bb] หมายเลขเวอร์ชันที่ถูกกระแทกไปยัง 1.2.1
# 1 ไฟล์ที่เปลี่ยนแปลง, 1 แทรก(+), 1 ลบ(-)

อย่าลืมเปลี่ยนหมายเลขเวอร์ชันหลังจากแตกแขนง!

จากนั้น, แก้ไขข้อผิดพลาดและทําให้ ยืนยัน ของการแก้ไขในหนึ่งหรือมากกว่า ยืนยัน แยก ต่างหาก.

$ git กระทํา -"Fixed severe production problem"
# [โปรแกรมแก้ไขด่วน-1.2.1 abbe5d6] แก้ไขปัญหาการผลิตที่รุนแรง
# 5 ไฟล์ที่เปลี่ยนแปลง, 32 แทรก(+), 17 ลบ(-)

การสรุปสาขาโปรแกรมแก้ไขด่วน

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

ครั้งแรก, ปรับปรุง หลัก และติดแท็ก a ปล่อย [ทําเครื่องหมายฤดูร้อน]:

$ ต้นแบบการชําระเงิน git
# เปลี่ยนเป็น 'ต้นแบบ' สาขา
$ ผสาน git --นิ้ว-โปรแกรมแก้ไขด่วน ff-1.2.1
# ผสานโดยการสอบถามซ้ํา.
# (สรุปการเปลี่ยนแปลง)
$ แท็ก git -มี 1.2.1

หมายเหตุ: คุณยังสามารถใช้ค่าสถานะ -s หรือ -u เมื่อต้องการเซ็นชื่อในแท็กของคุณอย่างเข้ารหัส.

จากนั้น, รวมถึง บักฟิกซ์ นิ้ว พัฒนา นอกจากนี้:

$ gitเช็คเอาต์พัฒนา
# เปลี่ยนเป็นสาขา 'พัฒนา'
$ ผสาน git --นิ้ว-โปรแกรมแก้ไขด่วน ff-1.2.1
# ผสานโดยการสอบถามซ้ํา.
# (สรุปการเปลี่ยนแปลง)

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

ในที่สุด, เอา สาขา คราว:

$ สาขากิต -dโปรแกรมแก้ไขด่วน-1.2.1
# ลบสาขาโปรแกรมแก้ไขด่วน-1.2.1 (คือ abbe5d6).

สรุป

แม้ว่าจะไม่มีอะไรพิเศษจริงๆในรูปแบบการแตกแขนงนี้, ตัวเลขที่จุดเริ่มต้นของโพสต์จะมีประโยชน์มากในโครงการของเรา. มันแสดงให้เห็นถึงรูปแบบทางจิตที่เข้าใจง่ายและช่วยให้สมาชิกในทีมสามารถพัฒนาความเข้าใจร่วมกันเกี่ยวกับกระบวนการของ การโยงสาขา และ ปล่อย.

รุ่น PDF ที่มีคุณภาพสูงของตัวเลขมีให้ในบล็อกของโพสต์ต้นฉบับ: http://nvie.com/posts/a-successful-git-branching-model/ [หรือในลิงค์ดาวน์โหลดด้านล่าง]. ไปข้างหน้าและวางไว้บนผนังที่จะได้รับการอ้างอิงอย่างรวดเร็วได้ตลอดเวลา.

จำนวนผู้เข้าชม: 10275

ความคิดเห็นบน “แบบจำลองความสำเร็จของสาขาใน Git

  1. เกิด Deivson กล่าวว่า:

    สวัสดี, ฉันรู้ว่า Git เริ่มพัฒนาขึ้น โดยระบบ Linux แต่เมื่อพูดในการพกพา, ผมสงสัยว่า ถ้า Git ทำงานบน windows และ POSIX MSIS??

ทิ้งคำตอบไว้

อีเมลของคุณจะไม่ถูกเผยแพร่. ฟิลด์ต้องมีเครื่องหมาย *