คุณจะทำโครงร่างการกำหนดตัวเลขด้วย Git ได้อย่างไร

องค์กรของฉันกำลังพิจารณาย้ายจาก SVN เป็น Git การโต้แย้งหนึ่งเรื่องการเคลื่อนย้ายมีดังนี้:

เราจะทำเวอร์ชันอย่างไร

เรามีการเผยแพร่ SDK ตามแพลตฟอร์ม NetBeans เนื่องจากการแก้ไข SVN เป็นตัวเลขอย่างง่ายเราจึงสามารถใช้พวกเขาเพื่อขยายหมายเลขรุ่นของปลั๊กอินและการสร้าง SDK ของเรา เราจะจัดการกับสิ่งนี้ได้อย่างไรเมื่อเราย้ายไปที่ Git

การแก้ปัญหาที่เป็นไปได้:

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

หากคนอื่นพบปัญหาที่คล้ายกันและแก้ไขมันเรายินดีที่จะได้ยินว่า

ใช้แท็กเพื่อทำเครื่องหมายคอมมิชชันด้วยหมายเลขเวอร์ชัน:

git tag -a v2.5 -m 'Version 2.5'

กดแท็กอัปสตรีมซึ่งไม่ได้ทำตามค่าเริ่มต้น:

git push --tags

จากนั้นใช้คำสั่งอธิบาย :

git describe --tags --long

สิ่งนี้จะทำให้คุณมีรูปแบบสตริง:

v2.5-0-gdeadbee
^    ^ ^^
|    | ||
|    | |'-- SHA of HEAD (first seven chars)
|    | '-- "g" is for git
|    '---- number of commits since last tag
|
'--------- last tag

สิ่งนี้ได้เกิดขึ้นในสองสามโครงการสำหรับฉัน ทางออกที่ดีที่สุดที่ฉันเคยมีคือการสร้างหมายเลขรุ่นดังนี้:

xy <จำนวนคอมมิต> .r <git-hash>

โดยปกติจะสร้างขึ้นโดยการสร้างระบบของเราใช้การรวมกันของไฟล์แบบคงที่บางส่วนหรือแท็กที่จะได้รับการแก้ไขตัวเลขที่สำคัญgit rev-list HEAD | wc -l(ซึ่งเร็วกว่าการใช้git log) git rev-parse HEADและ เหตุผลมีดังนี้:

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

หมายเลข 2 จะมองไม่เห็นคนส่วนใหญ่ แต่จริงๆที่สำคัญและมันยากลำบากกับการควบคุมแหล่งกระจาย SVN ให้ความช่วยเหลือในเรื่องนี้โดยให้หมายเลขการแก้ไขเดียวแก่คุณ ปรากฎว่าการนับการกระทำนั้นใกล้เคียงที่สุดเท่าที่คุณจะทำได้ในขณะที่การแก้ข้อที่ 4 อย่างน่าอัศจรรย์ ในการปรากฏตัวของสาขานี้ยังคงไม่ซ้ำกันซึ่งในกรณีนี้เราเพิ่มแฮชซึ่งแก้ไข # 3 ได้อย่างเรียบร้อย

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

ในกรณีที่คุณสงสัยเราเลือกที่จะใส่ r ไว้ข้างหน้าของแฮชเนื่องจากความแปลกประหลาดกับวิธีที่บรรจุภัณฑ์ของงูใหญ่จัดการตัวอักษรในหมายเลขรุ่น (เช่น ae น้อยกว่า 0 ซึ่งจะทำให้ "1.3.10.a1234" < "1.3.10" <"1.3.10.1234")

นี่อาจจะเกินเลยไปหน่อย แต่ฉันจะบอกให้คุณรู้ว่าเราจะทำอย่างไร

เราใช้โครงสร้างที่แตกแขนงคล้ายกันมากกับเรื่องนี้

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

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

ตัวอย่าง: 2.1.0 build 1337

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

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

ดูกระบวนการใช้ 'git-อธิบาย' ผ่าน GIT-VERSION-GEN และวิธีที่คุณสามารถเพิ่มสิ่งนี้ผ่านกระบวนการสร้างของคุณเมื่อคุณแท็กการเปิดตัวของคุณ

นี่เป็นบล็อกที่ดีที่ให้ตัวอย่างของวิธีการได้รับสิ่งที่คุณต้องการ:

http://cd34.com/blog/programming/using-git-to-generate-an-automatic-version-number/

Jon Purdy มีความคิดที่ถูกต้อง ทำให้การบริหารจัดการที่เกิดขึ้นจริงในสาขาเหล่านี้ได้ง่ายเช่นกันและการจัดการสาขาการโต้แย้งสำหรับการย้ายไปgit flowgit

ขอเริ่มต้นด้วยบทสรุปพื้นฐานของgitตั้งแต่คุณมาจากsvn-to- gitมุมมอง พิจารณาในgitสิ่งต่อไปนี้:

master--...............-.....-..............-
        \             /     /              /
         ---develop---------............../
                            \            /
                             --feature---

ด้านบนคุณแยกmasterไปที่develop(แสดงโดย\) และแยกdevelopไปที่featureสาขา เรารวมสาขาเหล่านั้นกลับมา (แสดงโดย/) ด้วยคอมมิชชัน ( -) ตามสาขา (ถ้าไม่มีการคอมมิชชัน แต่การผสานเป็นวิธีที่ถูกต้องมี.ตัวบ่งชี้ที่แสดงว่าการถัดไป-เป็นการคอมมิทถัดไป)

ง่ายพอสมควร เกิดอะไรขึ้นถ้าเรามีโปรแกรมแก้ไขด่วนในรุ่นหลักของเรา

master--...............-.....-................-...........-.........-
        \             /     /                / \         /|        /
         \           /     /                /   -hotfix-- V       /
          ---develop---------............../..............-...----
                             \            / \             V   /
                              --feature---   --feature2...----

ข้างต้นแยกจากdevelop masterข้อผิดพลาดที่พบในการmasterได้รับการแก้ไขโดยการแตกแขนงจากการแก้ไขมันและกลับเข้ามาในการควบรวมกิจการmaster masterจากนั้นเราก็รวมmasterเข้ากับdevelopและจากนั้นdevelopเข้าสู่feature2ซึ่งรีดรหัสใหม่จากhotfixในสาขาเหล่านี้

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

ดังนั้นนี่เป็นอีกวิธีในการทำเช่นนั้น

master--..........-........-
        \        /\       /
         ---1.0--  --1.1-- 

1.0 รีลีสของคุณจะถูกแท็1.0.1ก1.0.2— 1.0.3,, และอื่น ๆ

ต่อไปนี้เป็นเคล็ดลับ: คุณพบข้อบกพร่องใน 1.0 และมีผลกับ 1.1, 1.2 และ 1.3 คุณทำอะไร?

คุณแยกสาขาออกเป็นรุ่นล่าสุดหรือรุ่นที่เก่าที่สุดและทำการแก้ไข จากนั้นคุณผสานใหม่hotfixสาขาเข้า1.3และอื่นเข้า1.2, และ1.1 1.0อย่าแยกสาขาจากเวอร์ชันการบำรุงรักษาแต่ละสาขา อย่ารวม1.0เข้าmasterหรือผสานmasterเข้า1.0ด้วยกัน นำhotfixสาขาเดียวและรวมเข้าไปในสาขาเวอร์ชันทั้งหมดของคุณ หากมีความขัดแย้งก็จะบอกคุณ ตรวจสอบรหัสของคุณเพื่อให้แน่ใจว่าการเปลี่ยนแปลงนั้นถูกต้อง ( git diffคือเพื่อนของคุณ)

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

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

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

Pro Git ในส่วน 7.2 "แอตทริบิวต์ Git"ในส่วน "การขยาย" คำหลัก "มีตัวอย่างที่ดีของการใช้ตัวกรองรอยเปื้อน & ทำความสะอาดสำหรับการสร้างคำหลักสไตล์ RCS คุณสามารถใช้เทคนิคเดียวกันสำหรับการฝังบางรุ่นสตริงเป็นรหัสในรูปแบบและคำนวณตามกฎของคุณ คุณยังสามารถใช้git describeเป็นจุดเริ่มต้นได้ แต่คุณมีความเป็นไปได้ที่จะแปลงเป็นรูปแบบที่เหมาะสมมากขึ้นและได้รับจาก v2.5-14-feebdaed ตัวอย่างเช่นทำความสะอาด 2.5.14