ชื่อสาขาเทียบกับที่เก็บหลายแห่ง


130

ขณะนี้เรากำลังใช้การโค่นล้มบน codebase ที่ค่อนข้างใหญ่ แต่ละรีลีสได้รับสาขาของตัวเองและการแก้ไขจะดำเนินการกับลำต้นและย้ายไปยังสาขาที่ปล่อยโดยใช้svnmerge.py

ฉันเชื่อว่าถึงเวลาแล้วที่จะต้องไปสู่การควบคุมแหล่งที่มาที่ดีขึ้นและฉันเคยเล่นกับ Mercurial มาระยะหนึ่งแล้ว

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

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

ฉันถามคุณ; ข้อดีของแต่ละวิธีคืออะไร?

คำตอบ:


129

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

ซึ่งหมายความว่าการโคลนเหมาะอย่างยิ่งสำหรับการทดลองอย่างรวดเร็วที่คุณไม่ต้องการบันทึกชื่อสาขาและสาขาที่ตั้งชื่อนั้นเหมาะสำหรับสาขาในระยะยาว ("1.x", "2.x" และที่คล้ายกัน)

โปรดทราบว่าที่เก็บเดียวสามารถรองรับสาขาน้ำหนักเบาหลาย ๆ สาขาใน Mercurial ได้อย่างง่ายดาย คุณสามารถบุ๊กมาร์กสาขาในที่เก็บดังกล่าวเพื่อให้คุณสามารถค้นหาอีกครั้งได้อย่างง่ายดาย สมมติว่าคุณได้โคลนที่เก็บข้อมูลของ บริษัท เมื่อมีลักษณะดังนี้:

[a] --- [b]

คุณแฮ็คและสร้าง[x]และ[y]:

[a] --- [b] --- [x] --- [y]

หมายถึงในขณะที่มีคนใส่[c]และ[d]ลงในที่เก็บดังนั้นเมื่อคุณดึงคุณจะได้รับกราฟประวัติเช่นนี้:

            [x] --- [y]
           /
[เอบีซีดี]

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

% hg parents

[y]พูดเถอะว่ามันรายงาน คุณสามารถเห็นหัวด้วย

% hg heads

และจะรายงานและ[y] [d]หากคุณต้องการอัปเดตที่เก็บของคุณเป็นแบบชำระเงินทั้งหมด[d]ให้ทำ (แทนที่[d]ด้วยหมายเลขการแก้ไขสำหรับ[d]):

% hg update --clean [d]

จากนั้นคุณจะเห็นhg parentsรายงาน[d]นั้น ซึ่งหมายความว่าการกระทำต่อไปของคุณจะมี[d]ในฐานะผู้ปกครอง คุณสามารถแก้ไขข้อบกพร่องที่คุณสังเกตเห็นในสาขาหลักและสร้างชุดการเปลี่ยนแปลง[e]:

            [x] --- [y]
           /
[a] --- [b] --- [c] --- [d] --- [e]

ในการพุชชุดการเปลี่ยนแปลง[e]เท่านั้นคุณต้องทำ

% hg push -r [e]

ที่[e]เป็นกัญชาเซ็ตการแก้ไข โดยค่าเริ่มต้นhg pushก็จะเปรียบเทียบที่เก็บและเห็นว่า[x], [y]และ[e]จะหายไป แต่คุณอาจไม่ต้องการที่จะใช้ร่วมกัน[x]และ[y]ยัง

หากการแก้ไขข้อบกพร่องส่งผลกระทบต่อคุณด้วยคุณต้องการรวมเข้ากับสาขาคุณลักษณะของคุณ:

% hg update [y]
% hg merge

ซึ่งจะทำให้กราฟที่เก็บของคุณมีลักษณะเช่นนี้:

            [x] --- [y] ----------- [z]
           / /
[a] --- [b] --- [c] --- [d] --- [e]

ที่[z]เป็นการผสานระหว่างและ[y] [e]คุณสามารถเลือกที่จะทิ้งสาขาไปได้:

% hg strip [x]

ประเด็นหลักของเรื่องนี้คือโคลนตัวเดียวสามารถแสดงถึงการพัฒนาหลาย ๆ ด้านได้อย่างง่ายดาย สิ่งนี้เป็นจริงเสมอสำหรับ "hg ธรรมดา" โดยไม่ต้องใช้ส่วนขยายใด ๆ แม้ว่าส่วนขยายบุ๊กมาร์กเป็นตัวช่วยที่ดี จะช่วยให้คุณกำหนดชื่อ (บุ๊กมาร์ก) ให้กับชุดการเปลี่ยนแปลง ในกรณีข้างต้นคุณจะต้องมีบุ๊กมาร์กบนส่วนหัวการพัฒนาของคุณและอีกอันอยู่บนส่วนหัวอัปสตรีม สามารถผลักและดึงบุ๊กมาร์กได้ด้วย Mercurial 1.6 และกลายเป็นคุณสมบัติในตัวของ Mercurial 1.8

หากคุณเลือกที่จะสร้างสองโคลนโคลนการพัฒนาของคุณจะมีลักษณะเช่นนี้หลังจากสร้าง[x]และ[y]:

[a] --- [b] --- [x] --- [y]

และโคลนต้นน้ำของคุณจะประกอบด้วย:

[a] --- [b] --- [c] --- [d]

ตอนนี้คุณสังเกตเห็นจุดบกพร่องและแก้ไข ที่นี่คุณไม่จำเป็นต้องทำhg updateตั้งแต่โคลนต้นน้ำพร้อมใช้งาน คุณกระทำและสร้าง[e]:

[a] --- [b] --- [c] --- [d] --- [e]

หากต้องการรวม bugfix ไว้ในโคลนการพัฒนาของคุณคุณจะดึงมันเข้าไปที่นั่น:

[a] --- [b] --- [x] --- [y]
           \
            [c] --- [d] --- [e]

และรวม:

[a] --- [b] --- [x] --- [y] --- [z]
           \ /
            [c] --- [d] --- [e]

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

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


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

2
อ้างถึง: 'โคลนเหมาะสำหรับการทดลองอย่างรวดเร็ว' - ไม่พวกเขาไม่ใช่! จะเกิดอะไรขึ้นถ้าคุณมีไฟล์หลายพันไฟล์ใน repo? การโคลนนิ่งจะใช้เวลานาน (เมื่อใดก็ได้มากกว่า 1 นาที) ในขณะที่การเปลี่ยนสาขาเพียงชั่วครู่ (<1 วินาที) การยังคงใช้สาขาที่ตั้งชื่อไว้จะก่อให้เกิดการเปลี่ยนแปลง มันเป็นทางตันไม่ใช่เหรอ? หรือฉันขาดอะไรไป?
ส่ง

ตกลง seler; ดูเหมือนเป็นการแก้ไขข้อโต้แย้งเดิมของเขา การโคลนเป็นสิ่งที่ดีในกรณีที่ค่าใช้จ่ายของสำเนาที่สมบูรณ์หลายชุดไม่สำคัญสำหรับคุณหรือเมื่อคุณสามารถใช้ symlinks / hardlinks ของ hg เพื่อลดค่าใช้จ่ายของสำเนาการทำงานในเครื่องแยกต่างหากต่อสาขา
Warren P

@seler: คุณค่อนข้างถูกต้องที่โคลนนั้นใช้ไม่ได้ถ้ารหัส bade มีขนาดใหญ่ บุ๊กมาร์กเป็นทางออกแล้ว
Martin Geisler

29

ฉันคิดว่าคุณต้องการประวัติทั้งหมดใน repo เดียว การวางไข่ของ repo ระยะสั้นมีไว้สำหรับการทดลองระยะสั้นไม่ใช่เหตุการณ์สำคัญเช่นการเผยแพร่

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


20
คุณสามารถสร้างสาขาคุณลักษณะดังกล่าวได้อย่างง่ายดาย: "hg update" ไปยังจุดสาขาของคุณแก้ไขไปและ "hg คอมมิต" คุณได้สร้างสายการพัฒนาที่แตกต่างกันใหม่ - ความมุ่งมั่นใหม่จะขยายสาขานี้ ใช้ "hg clone -r" เพื่อกำจัดหรือลบแบบอินไลน์โดย "hg strip" ดังนั้นโปรดอย่าผิดหวังหรือมาที่รายชื่ออีเมล Mercurial พร้อมกับคำขอคุณสมบัติของคุณ
Martin Geisler

8
ดูเหมือนว่าhg stripเป็นสิ่งที่ฉันต้องการ เหตุใดสาขาการอ้างสิทธิ์เอกสารออนไลน์จึงไม่สามารถลบได้
Norman Ramsey

11
ดูบทความในบล็อกนี้เพื่อดูคำอธิบายเกี่ยวกับวิธีที่ Mercurial มีสาขาที่ถูกกว่า git: stevelosh.com/blog/entry/2009/8/30/…
Martin Geisler

9
คุณสามารถปิดสาขาที่มีชื่อด้วยhg ci --close-branch.
Andrey Vlasovskikh

3
@ Norman Ramsey: เมื่อมีคนบอกว่าไม่สามารถลบสาขาได้หมายความว่าคุณไม่สามารถเปลี่ยนชื่อสาขาที่ฝังอยู่ในชุดการเปลี่ยนแปลงได้ เซ็ตการแก้ไขเราไม่มีในสาขานั้นจะกำหนดสาขา คุณจะต้องลบชุดการเปลี่ยนแปลงและสร้างใหม่โดยใช้ชื่อสาขาอื่นหากคุณต้องการ "ย้าย" ไปยังสาขาอื่น
Martin Geisler

14

คุณควรทำทั้งสองอย่าง

เริ่มต้นด้วยคำตอบที่ยอมรับจาก @Norman: ใช้ที่เก็บเดียวกับหนึ่งสาขาที่มีชื่อต่อหนึ่งรุ่น

จากนั้นให้มีหนึ่งโคลนต่อหนึ่งสาขารีลีสสำหรับการสร้างและทดสอบ

ข้อสังเกตสำคัญประการหนึ่งคือแม้ว่าคุณจะใช้ที่เก็บหลายที่คุณควรหลีกเลี่ยงการใช้transplantเพื่อย้ายชุดการเปลี่ยนแปลงระหว่างชุดการเปลี่ยนแปลงเนื่องจาก 1) มีการเปลี่ยนแปลงแฮชและ 2) อาจทำให้เกิดข้อบกพร่องที่ตรวจพบได้ยากมากเมื่อมีการเปลี่ยนแปลงที่ขัดแย้งกันระหว่างชุดการเปลี่ยนแปลงที่คุณ การปลูกถ่ายและสาขาเป้าหมาย คุณต้องการทำการผสานตามปกติแทน (และไม่มีการผสานล่วงหน้า: ตรวจสอบการผสานด้วยสายตาเสมอ) ซึ่งจะส่งผลให้สิ่งที่ @mg พูดในตอนท้ายของคำตอบของเขา:

กราฟอาจดูแตกต่างกัน แต่มีโครงสร้างเหมือนกันและผลลัพธ์สุดท้ายก็เหมือนกัน

อย่างละเอียดยิ่งขึ้นหากคุณใช้หลายที่เก็บที่เก็บ "trunk" (หรือค่าเริ่มต้นหลักการพัฒนาอะไรก็ตาม) จะมีชุดการเปลี่ยนแปลงทั้งหมดในที่เก็บทั้งหมด ที่เก็บรีลีส / สาขาแต่ละแห่งเป็นเพียงสาขาเดียวในลำต้นทั้งหมดรวมกลับทางเดียวหรืออีกทางกลับไปที่ลำต้นจนกว่าคุณจะต้องการปล่อยรุ่นเก่าไว้ข้างหลัง ดังนั้นความแตกต่างที่แท้จริงเพียงอย่างเดียวระหว่าง repo หลักและ repo เดียวในโครงการสาขาที่ตั้งชื่อก็คือการตั้งชื่อสาขาหรือไม่

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

แต่คุณยังต้องดูแลหนึ่งโคลนต่อสาขา / รีลีสที่คุณต้องสร้างและทดสอบ มันไม่สำคัญเท่าที่จะทำได้hg clone <main repo>#<branch> <branch repo>จากนั้นhg pullใน repo สาขาจะดึงเฉพาะชุดการเปลี่ยนแปลงใหม่ในสาขานั้น (รวมทั้งชุดการเปลี่ยนแปลงบรรพบุรุษในสาขาก่อนหน้านี้ที่รวมเข้าด้วยกัน)

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


นี่คือตัวอย่างของ @ mg สำหรับการตั้งค่านี้ จุดเริ่ม:

[a] - [b]

ตั้งชื่อสาขาสำหรับรุ่นที่วางจำหน่ายโดยพูดว่า "1.0" เมื่อคุณเข้าสู่รุ่นอัลฟ่า แก้ไขข้อบกพร่องของมัน:

[a] - [b] ------------------ [m1]
         \                 /
          (1.0) - [x] - [y]

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

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

ในขณะเดียวกันการพัฒนาในสาขาเริ่มต้นยังคงดำเนินต่อไปในรุ่นถัดไป:

          ------- [c] - [d]
         /
[a] - [b] ------------------ [m1]
         \                 /
          (1.0) - [x] - [y]

และตามปกติคุณต้องรวมสองหัวในสาขาเริ่มต้น:

          ------- [c] - [d] -------
         /                         \
[a] - [b] ------------------ [m1] - [m2]
         \                 /
          (1.0) - [x] - [y]

และนี่คือโคลนสาขา 1.0:

[a] - [b] - (1.0) - [x] - [y]

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


ฉันหวังว่าตัวอย่างจะทำให้ประเด็นก่อนหน้านี้ชัดเจน โดยสรุปข้อดีของแนวทางนี้คือ:

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

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


5

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


2

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


0

ฉันไม่แนะนำให้ใช้สาขาที่มีชื่อสำหรับเวอร์ชันจริงๆ นั่นคือสิ่งที่แท็กมีไว้สำหรับ สาขาที่มีชื่อมีความหมายสำหรับความหลากหลายที่ยาวนานเช่นเดียวกับstableสาขา

แล้วทำไมไม่ใช้แค่แท็กล่ะ? ตัวอย่างพื้นฐาน:

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

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


ขึ้นอยู่กับกระบวนการของคุณเป็นอย่างมาก ตัวอย่างเช่นเว็บแอปทำงานได้ดีกับลำดับชั้นของสาขาที่เสถียร / การทดสอบ / ลดระดับ เมื่อสร้างซอฟต์แวร์เดสก์ท็อปโดยทั่วไปเราจะมีสาขาการพัฒนา (ค่าเริ่มต้น) รวมทั้งสาขาที่แตกต่างกันหนึ่งถึงสาม (!) ในการบำรุงรักษา เป็นเรื่องยากที่จะคาดเดาเมื่อเราอาจต้องกลับไปที่สาขาและมีความสง่างามบางประการเกี่ยวกับการมีสาขาติดตามเวอร์ชัน major.minor
James Emerton
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.