Để chi nhánh hay không chi nhánh?

Cho đến gần đây, quy trình phát triển của tôi là như sau:

1. Nhận tính năng từ chủ sở hữu sản phẩm
2. Tạo một chi nhánh (nếu tính năng là hơn 1 ngày)
3. Thực hiện nó trong một chi nhánh
4. Hợp nhất các thay đổi từ chi nhánh chính sang chi nhánh của tôi (để giảm xung đột trong quá trình hợp nhất ngược)
5. Hợp nhất chi nhánh của tôi trở lại chi nhánh chính

Đôi khi có vấn đề với việc hợp nhất, nhưng nói chung tôi thích nó.

Nhưng gần đây tôi thấy ngày càng có nhiều người theo dõi ý tưởng không tạo ra các chi nhánh vì việc thực hiện tích hợp liên tục, phân phối liên tục, v.v. Git, Mercurial, v.v.

Vì vậy, câu hỏi là chúng ta có nên sử dụng các chi nhánh ngày nay?

Trừ khi bạn đang làm việc trên cùng một cây làm việc, bạn đang sử dụng các nhánh, cho dù bạn có gọi chúng như vậy hay không. Mỗi khi một nhà phát triển kiểm tra vào cây làm việc của mình, anh ta tạo ra một nhánh phát triển cục bộ riêng biệt và mỗi khi anh ta kiểm tra anh ta sẽ hợp nhất. Đối với hầu hết các đội, câu hỏi không phải là nếu bạn sử dụng các nhánh, câu hỏi là bao nhiêu và cho mục đích gì?

Cách duy nhất để thực hiện tích hợp "liên tục" thực sự là cho mọi người làm việc trên cùng một cây làm việc. Bằng cách đó, bạn sẽ biết ngay những thay đổi của mình có ảnh hưởng xấu đến người khác hay không. Rõ ràng, đó là không thể bảo vệ. Bạn cần một mức độ cô lập nhất định trong một nhánh để hoàn thành bất cứ điều gì, ngay cả khi "nhánh" đó chỉ là thư mục làm việc cục bộ của bạn. Những gì cần thiết là một sự cân bằng hợp lý của sự tích hợp và cô lập.

Theo kinh nghiệm của tôi, việc sử dụng nhiều chi nhánh sẽ cải thiện mức độ tích hợp, bởi vì việc tích hợp được thực hiện với chính xác những người cần thực hiện và mọi người khác có thể dễ dàng cách ly các vấn đề không liên quan hơn theo yêu cầu.

Ví dụ, tôi đã dành ngày cuối cùng để theo dõi ba lỗi liên quan đến tích hợp được giới thiệu gần đây trong bản dựng của chúng tôi đang chặn công việc "thực sự" của tôi. Đã thực hiện sự chuyên cần của tôi trong việc báo cáo các lỗi này cho những người cần sửa chúng, giờ tôi chỉ cần đợi cho đến khi chúng kết thúc để tiếp tục công việc của tôi? Dĩ nhiên là không. Tôi đã tạo một nhánh cục bộ tạm thời hoàn nguyên những thay đổi đó để tôi có thể có đường cơ sở ổn định để xử lý trong khi vẫn nhận được những thay đổi mới nhất từ ​​thượng nguồn.

Nếu không có khả năng tạo một nhánh mới cho mục đích đó, tôi sẽ bị giảm xuống một trong ba tùy chọn: hoặc hoàn nguyên các thay đổi trong repo trung tâm, duy trì thủ công các bản vá hoàn nguyên chúng trong cây làm việc của tôi và cố gắng không vô tình kiểm tra chúng hoặc quay trở lại phiên bản trước khi những lỗi đó được giới thiệu. Tùy chọn đầu tiên có khả năng phá vỡ một số phụ thuộc khác. Tùy chọn thứ hai là rất nhiều công việc, vì vậy hầu hết mọi người chọn tùy chọn thứ ba, về cơ bản ngăn bạn thực hiện nhiều công việc tích hợp hơn cho đến khi các lỗi được tìm thấy trước đó được sửa.

Ví dụ của tôi đã sử dụng một chi nhánh địa phương tư nhân, nhưng nguyên tắc tương tự áp dụng cho các chi nhánh được chia sẻ. Nếu tôi chia sẻ chi nhánh của mình, thì có thể 5 người khác có thể tiếp tục với các nhiệm vụ chính của họ thay vì thực hiện công việc tích hợp dự phòng, do đó, tổng hợp công việc tích hợp hữu ích hơn được thực hiện. Vấn đề với việc phân nhánh và tích hợp liên tục không phải là bạn có bao nhiêu chi nhánh, đó là tần suất bạn hợp nhất chúng.

Câu hỏi là chúng ta có nên sử dụng các chi nhánh ngày nay?

Khoảng nửa năm trước tôi được chỉ định thực hiện một nghiên cứu để trả lời câu hỏi đó. Đây là tóm tắt, dựa trên các tài liệu tham khảo được nghiên cứu (được liệt kê dưới đây)

• không có chiến lược phân nhánh "tốt nhất" thường được thống nhất áp dụng cho bất kỳ dự án nào
  • hầu hết các nguồn lực dường như đồng ý rằng việc lựa chọn chiến lược sản xuất phụ thuộc vào các chi tiết cụ thể của dự án
  • lưu ý phụ. Dựa vào bên trên, có vẻ như bất kỳ thay đổi nào đối với chiến lược phân nhánh dự án cần phải được kiểm tra, đo lường và so sánh với các tùy chọn khác được thử nghiệm
• ý kiến ​​phổ biến là việc hợp nhất với Subversion cần rất nhiều nỗ lực. Tất cả những người so sánh SVN và Git đều lưu ý rằng việc hợp nhất trở nên dễ dàng hơn với Git
• một yếu tố quan trọng dường như là liệu các bản phát hành sản xuất có nguồn gốc từ thân cây hay cành cây. Các nhóm thực hiện phát hành prod từ thân cây (dường như không hoàn toàn là một cách phổ biến) về cơ bản bị cấm sử dụng chiến lược trung kế không ổn định . Các nhóm thực hiện phát hành prod từ các chi nhánh có nhiều tùy chọn phân nhánh hơn để lựa chọn.
• chiến lược phổ biến dường như là thân cây ổn định, thân cây không ổn định và nhánh phát triển (tích hợp)

người giới thiệu

• http://msdn.microsoft.com/en-us/l Library / aa730834% 28v = vs.80% 29.aspx
  

  ... Quyết định chiến lược phân nhánh tốt nhất là một hành động cân bằng. Bạn phải đánh đổi tăng năng suất chống lại rủi ro tăng lên. Một cách để xác nhận một chiến lược đã chọn là xem xét một kịch bản thay đổi. Ví dụ: nếu bạn quyết định căn chỉnh các nhánh với kiến ​​trúc hệ thống (ví dụ: nhánh đại diện cho một thành phần hệ thống) và bạn mong đợi các thay đổi kiến ​​trúc quan trọng, bạn có thể phải cơ cấu lại các nhánh của mình và các quy trình và chính sách liên quan với mỗi thay đổi. Việc lựa chọn một chiến lược phân nhánh không đầy đủ có thể gây ra các chi phí quá trình và các chu kỳ phát hành và tích hợp kéo dài gây ra sự bực bội cho toàn đội ...

• http://www.cmcrossroads.com/bradapp/acme/branching/
  

  ... Sự tích hợp thường xuyên, gia tăng là một trong những dấu hiệu thành công và sự vắng mặt của nó thường là một đặc điểm của sự thất bại. Các phương pháp quản lý dự án hiện tại có xu hướng tránh các mô hình thác nước nghiêm ngặt và nắm lấy các mô hình giống như xoắn ốc của phát triển lặp / tăng dần và phân phối tiến hóa. Các chiến lược tích hợp tăng dần, như Hợp nhất sớm và thường xuyên và các biến thể của nó, là một hình thức quản lý rủi ro cố gắng loại bỏ rủi ro sớm hơn trong vòng đời khi có nhiều thời gian hơn để đáp ứng. Sự đều đặn của nhịp giữa các tích hợp được xem bởi [Booch], [McCarthy] và [McConnell] như là một chỉ số hàng đầu về sức khỏe dự án (như "nhịp đập" hoặc "nhịp tim").  
   
  Không chỉ tích hợp sớm và thường xuyên có nguy cơ sớm hơn và trong các "khối nhỏ", nó còn truyền đạt những thay đổi giữa các đồng đội ...

• http: //www.codinghorror.com/blog/2007/10/software-branching-and-abul-universes.html
  

  ... Trong hầu hết các hệ thống kiểm soát nguồn, bạn có thể tạo hàng trăm nhánh mà không gặp vấn đề gì về hiệu năng; đó là chi phí tinh thần của việc theo dõi tất cả các nhánh mà bạn thực sự cần phải lo lắng ... Phân nhánh là một con thú phức tạp. Có hàng tá cách để phân nhánh và không ai có thể thực sự nói cho bạn biết bạn đang làm đúng hay sai ...

• http://www.lostechies.com/bloss/derickbailey/archive/2010/02/24/branching-strargeties-when-to-branch-and-merge.aspx
  

  ... Có nhiều khía cạnh của một hệ thống được xem xét khi phân nhánh mã của bạn ... Cuối cùng, mục tiêu là cung cấp một hộp cát cho bối cảnh mà mã được viết. Hiểu các tùy chọn khả dụng, khi mỗi tùy chọn phù hợp nhất với tình huống hiện tại và chi phí của các tùy chọn này sẽ giúp bạn quyết định cách thức và thời điểm phân nhánh ...

• http://www.snuffybear.com/ucm_branch.htm
  Lưu ý đưa ra các tài liệu tham khảo khác được liệt kê ở đây, tác giả cho rằng "Bài viết này mô tả ba mô hình phân nhánh chính được sử dụng trong các dự án Kỹ thuật phần mềm" có vẻ không hợp lý. Thuật ngữ được sử dụng trông không phổ biến ( EFIX , Model-1,2,3, v.v.).

• http://svn.haxx.se/users/archive-2007-10/att-0101/SCMBranchingModels-talkback.pdf
  Tham khảo trình bày một ví dụ thú vị về những khó khăn trong việc truyền đạt chiến lược phân nhánh.

• http://simpleprogrammer.com/2010/06/04/simple-branching-strargety-part-1-back-to-basics/
  ... Giữ cho nó đơn giản. Theo tôi, làm việc trực tiếp từ thân cây là cách tiếp cận tốt nhất theo quan điểm của tôi.  
   
  Nó gần giống như dị giáo khi tôi thực sự gõ nó lên màn hình của mình, nhưng nếu bạn chịu đựng tôi một lúc, tôi sẽ không chỉ cho bạn thấy lý do tại sao tôi nghĩ rằng điều này rất cần thiết cho quy trình Agile, nhưng tôi sẽ chỉ cho bạn cách để làm cho nó hoạt động ...  
   
  ... Nếu tôi phải dựa trên lý lẽ của mình dựa trên một lý lẽ chắc chắn, đó sẽ là giá trị của sự tích hợp liên tục. Tôi viết blog về giá trị của CI và thực tiễn tốt nhất trong quá khứ. Tôi là một người ủng hộ khá lớn của CI ...  
   
  ... Bạn thực sự phải tự hỏi mình một câu hỏi ở đây: "Có phải tất cả các chi phí bạn đang phải gánh chịu từ việc phân nhánh phức tạp và sáp nhập chiến lược dẫn đến một giá trị thực sự mà không tồn tại trên một chiến lược đơn giản hơn?" ...  
   
  .. Một chiến lược tôi đã sử dụng hiệu quả trong quá khứ và đã phát triển theo thời gian. Tôi sẽ tóm tắt ngắn gọn ở đây.

  • Mọi người làm việc ra khỏi thân cây.
  • Chi nhánh khi bạn phát hành mã.
  • Chi nhánh phát hành khi bạn cần tạo một bản sửa lỗi cho mã đã phát hành.
  • Chi nhánh cho các nguyên mẫu.
    ...
    • http://simpleprogrammer.com/2010/06/07/simple-branching-strargety-part-2-im THỰCation /
      ... khá chi tiết hướng dẫn ...

• http://www.codeledit.com/blog/index.php/2009/07/02/a-svn-branching-strargety-that-works/
  ... Cuối cùng, hãy nhớ rằng không có chiến lược hợp nhất và phân nhánh lý tưởng. Nó phụ thuộc khá nhiều vào môi trường phát triển độc đáo của bạn ...

• http://blog.perforce.com/blog/?cat=62
  ... Trường hợp xấu nhất là bạn đưa ra vấn đề "hợp nhất ngữ nghĩa", trong đó kết quả của hợp nhất tự động là không chính xác, nhưng biên dịch OK và lén lút qua thử nghiệm, thậm chí có thể tồn tại đủ lâu để trở thành một lỗi có thể nhìn thấy của khách hàng. Ôi!  
   
  Thêm sự xúc phạm vào thương tích, bởi vì chúng có thể thoát khỏi sự phát hiện lâu hơn, các vấn đề hợp nhất ngữ nghĩa sẽ khó khắc phục hơn sau đó, vì sự thay đổi không còn mới mẻ trong tâm trí của nhà phát triển đã tạo ra sự thay đổi. (Thông thường tốt nhất là hợp nhất các thay đổi ngay sau khi thực hiện, lý tưởng nhất là nhà phát triển đã tạo ra thay đổi nếu điều đó thực tế) ...

  • http://blog.perforce.com/blog/?p=1635
    Lưu ý chính sách được đề xuất xuất hiện tương tự như nhánh phát triển vì nó được định nghĩa trong http://www.infoq.com/articles/agile-version-control#q11 và http : //msdn.microsoft.com/en-us/l Library / bb668955.aspx
  • Giải thích về mô hình khuyến mãi: http://www.perforce.com/perforce/ con / life.html

• https://stackoverflow.com/questions/34975/branching-str Strategies
  Các thành viên cộng đồng chia sẻ kinh nghiệm khác nhau trong các dự án khác nhau bằng cách sử dụng các chiến lược phân nhánh khác nhau. Không có sự đồng thuận đồng ý về "tốt nhất" hoặc "tồi tệ nhất".

  • http://oreilly.com/catalog/prrealperforce/ch CHƯƠNG / ch07.pdf cách
    đọc "cổ điển" - thuật ngữ được giải thích như Mô hình chính , Codeline , v.v.

• http://www.stickyminds.com/s.asp?F=S16454_COL_2
  Về cơ bản là một bản tóm tắt ngắn gọn về nội dung được trình bày trong http://oreilly.com/catalog/prrealperforce/ch CHƯƠNG / ch07.pdf

  • http://www.stickyminds.com/s.asp?F=S16511_COL_2
    ... Có ba cách tiếp cận phổ biến để quyết định thời điểm và cách phân nhánh:
    • Tạo nhánh phát hành khi bạn "hoàn thành tính năng" và lên kế hoạch khắc phục các sự cố vào phút cuối trên dòng mã này. Trong trường hợp này, nhánh phát hành thực sự là một "dòng mã chuẩn bị phát hành", như được mô tả trong Các mẫu quản lý cấu hình phần mềm , vì bạn cho rằng vẫn còn nhiều việc phải làm.
    • Thay đổi phong cách làm việc của bạn để tránh công việc tích hợp cuối cùng, hoạt động theo dòng phát triển tích cực.
    • Chi nhánh cho công việc mới bằng cách tạo một nhánh nhiệm vụ và hợp nhất công việc đó vào dòng phát triển hoạt động sau khi phát hành hoàn tất.
      ... Một lý do cho việc phân nhánh là cô lập mã ở cuối bản phát hành để nó có thể ổn định. Sự cô lập thông qua việc phân nhánh thường che giấu một vấn đề chất lượng sẽ tự biểu hiện trong chi phí tăng thêm để duy trì các luồng song song trước khi sản phẩm được phát hành. Sự phân nhánh rất dễ dàng. Thay vào đó, đó là sự hợp nhất và chi phí nhận thức để hiểu cách thay đổi chảy giữa các nhánh khó khăn, vì vậy điều quan trọng là chọn một quy trình giảm thiểu chi phí phân nhánh và sáp nhập ...

• http://nvie.com/posts/a-successful-git-branching-model/ Chiến lược định hướng Git.
  ... Chúng tôi coi nguồn gốc / bản gốc là nhánh chính trong đó mã nguồn của HEAD luôn phản ánh trạng thái sẵn sàng sản xuất .  
   
  Chúng tôi coi nguồn gốc / phát triển là nhánh chính trong đó mã nguồn của HEAD luôn phản ánh trạng thái với các thay đổi phát triển được phân phối mới nhất cho lần phát hành tiếp theo. Một số người sẽ gọi đây là "nhánh tích hợp". Đây là nơi mà bất kỳ bản dựng hàng đêm tự động nào được xây dựng từ ....

  • Một phần nào đó tương tự như chiến lược chi nhánh phát triển như được định nghĩa trong http://www.infoq.com/articles/agile-version-control#q11 và http://msdn.microsoft.com/en-us/l Library / bb668955.aspx

• http://svnbook.red-bean.com/en/1.5/svn.branchmerge.html
  ... các chính sách dự án rất khác nhau liên quan đến chính xác khi nào phù hợp để tạo một nhánh tính năng. Một số dự án không bao giờ sử dụng các nhánh tính năng: cam kết / trung kế là miễn phí cho tất cả. Ưu điểm của hệ thống này là đơn giản, không ai cần học về phân nhánh hoặc sáp nhập. Nhược điểm là mã thân thường không ổn định hoặc không sử dụng được. Các dự án khác sử dụng các nhánh đến mức cực đoan: không có thay đổi nào được cam kết trực tiếp với thân cây. Ngay cả những thay đổi nhỏ nhất cũng được tạo ra trên một nhánh tồn tại ngắn, được xem xét cẩn thận và sáp nhập vào thân cây. Sau đó, chi nhánh sẽ bị xóa. Hệ thống này đảm bảo một thân cây đặc biệt ổn định và có thể sử dụng mọi lúc, nhưng với chi phí rất lớnquá trình trên không.  
   
  Hầu hết các dự án có một cách tiếp cận giữa đường. Họ thường nhấn mạnh rằng / biên dịch thân cây và vượt qua các bài kiểm tra hồi quy mọi lúc. Một nhánh tính năng chỉ được yêu cầu khi một thay đổi đòi hỏi một số lượng lớn các cam kết gây mất ổn định. Một nguyên tắc nhỏ là đặt câu hỏi này: nếu nhà phát triển làm việc trong nhiều ngày một mình và sau đó thực hiện thay đổi lớn cùng một lúc (để / thân cây không bao giờ bị mất ổn định), liệu có phải là một thay đổi quá lớn để xem xét? Nếu câu trả lời cho câu hỏi đó là "có", thì sự thay đổi sẽ được phát triển trên một nhánh tính năng. Khi nhà phát triển cam kết thay đổi gia tăng cho chi nhánh, họ có thể dễ dàng xem xét bởi các đồng nghiệp.  
   
  Cuối cùng, có vấn đề làm thế nào để giữ một nhánh tính năng "đồng bộ hóa" tốt nhất với thân cây khi tiến trình công việc. Như chúng tôi đã đề cập trước đó, có một rủi ro lớn khi làm việc trên một chi nhánh trong nhiều tuần hoặc nhiều tháng; thay đổi thân cây có thể tiếp tục đổ vào, đến mức hai dòng phát triển khác nhau đến mức nó có thể trở thành một cơn ác mộng khi cố gắng hợp nhất nhánh trở lại thân cây.  
   
  Tình trạng này là tốt nhất để tránh bằng cách thường xuyên hợp nhất thay đổi thân cây với chi nhánh. Tạo một chính sách: mỗi tuần một lần, hợp nhất các thay đổi trung kế trị giá của tuần trước cho chi nhánh ...

• http://thedesignspace.net/MT2archives/000680.html
  ... Phần này trong hướng dẫn CVS của Eclipse dựa trên bài viết của Paul Glezen trên trang web Eclipse: Phân nhánh với Eclipse và CVS , và được sử dụng với sự cho phép của anh ta theo các điều khoản của giấy phép EPL. Những thay đổi tôi đang thực hiện cho phiên bản của anh ấy chủ yếu là mở rộng nó với nhiều hình ảnh và giải thích từng bước hơn, đồng thời tích hợp nó với các hướng dẫn cho người mới bắt đầu của tôi để cố gắng làm cho người mới bắt đầu và nhà thiết kế dễ tiếp cận hơn. Các nhà phát triển có kinh nghiệm có thể sẽ thích làm việc từ phiên bản của Paul ...

  • http://www.eclipse.org/articles/article.php?file=Article-BranchingWithEclipseAndCVS/article1.html
  • http://www.eclipse.org/articles/article.php?file=Article-BranchingWithEclipseAndCVS/article2.html

• http://learnsoftwareprocesses.com/2007/12/29/common-branching-strargeties/
  ... Dưới đây là một số mô hình phân nhánh phổ biến:  

  1. Mô hình phát hành chi nhánh: Một trong những chiến lược phân nhánh phổ biến nhất là liên kết các chi nhánh với các bản phát hành sản phẩm. Một nhánh giữ tất cả các tài sản phát triển phần mềm cho một bản phát hành. Đôi khi, các bản cập nhật cần được hợp nhất từ ​​bản phát hành này sang bản phát hành khác, nhưng chúng thường không bao giờ hợp nhất. Các chi nhánh sẽ bị ngừng khi phát hành đã nghỉ hưu.  
  2. Chi nhánh cho mỗi khuyến mãi: Một cách tiếp cận rất phổ biến khác là sắp xếp các chi nhánh với các mức khuyến mãi tài sản phần mềm. Một phiên bản phát triển cụ thể được phân nhánh thành một nhánh Thử nghiệm, tại đó tất cả các thử nghiệm tích hợp và hệ thống được thực hiện. Khi bạn hoàn thành thử nghiệm, các tài sản phát triển phần mềm được phân nhánh vào nhánh Sản xuất và cuối cùng được triển khai.  
  3. Chi nhánh trên mỗi nhiệm vụ: Để tránh các nhiệm vụ (hoặc hoạt động) chồng chéo và mất năng suất, bạn có thể cách ly chúng trên một nhánh riêng biệt. Hãy nhớ rằng đây là những nhánh ngắn hạn nên được sáp nhập ngay khi hoàn thành nhiệm vụ, vì nếu không, nỗ lực sáp nhập cần thiết có thể vượt quá lợi ích năng suất của việc tạo ra chúng ở nơi đầu tiên.  
  4. Nhánh trên mỗi thành phần: Bạn có thể căn chỉnh từng nhánh với kiến ​​trúc hệ thống. Trong chiến lược này, bạn phân nhánh các thành phần riêng lẻ (hoặc hệ thống con). Sau đó, mỗi nhóm phát triển một thành phần quyết định khi hợp nhất mã của họ trở lại dòng phát triển đóng vai trò là nhánh tích hợp. Chiến lược này có thể hoạt động tốt nếu kiến ​​trúc hệ thống được đưa ra và các thành phần riêng lẻ có giao diện được xác định rõ. Việc bạn phát triển các thành phần trên các nhánh cho phép kiểm soát chi tiết hơn đối với các tài sản phát triển phần mềm.  
  5. Nhánh trên mỗi công nghệ: Một chiến lược phân nhánh khác phù hợp với kiến ​​trúc hệ thống. Trong trường hợp này, các chi nhánh được liên kết với các nền tảng công nghệ. Mã chung được quản lý trên một nhánh riêng. Do tính chất độc đáo của các tài sản phát triển phần mềm được quản lý trên các chi nhánh, có lẽ chúng không bao giờ hợp nhất ...

• http://msdn.microsoft.com/en-us/l Library / bb668955.aspx
  ... Tham khảo hướng dẫn phân nhánh và hợp nhất trong "Nguyên tắc kiểm soát nguồn" trong hướng dẫn này để biết tóm tắt về hướng dẫn phân nhánh và hợp nhất. ... Khi phân nhánh, hãy xem xét những điều sau đây:

  • Không phân nhánh trừ khi nhóm phát triển của bạn cần làm việc trên cùng một tập hợp các tệp. Nếu bạn không chắc chắn về điều này, bạn có thể gắn nhãn một bản dựng và tạo một nhánh từ bản dựng đó vào một thời điểm sau. Việc hợp nhất các nhánh có thể tốn thời gian và phức tạp, đặc biệt nếu có những thay đổi đáng kể giữa chúng.
  • Cấu trúc cây nhánh của bạn để bạn chỉ cần hợp nhất dọc theo cấu trúc phân cấp (lên và xuống cây nhánh) chứ không phải qua cấu trúc phân cấp. Phân nhánh trên hệ thống phân cấp yêu cầu bạn sử dụng hợp nhất vô căn cứ, đòi hỏi giải quyết xung đột thủ công nhiều hơn.
  • Hệ thống phân cấp nhánh dựa trên nhánh cha và nhánh con, có thể khác với cấu trúc vật lý của mã nguồn trên đĩa. Khi lập kế hoạch hợp nhất của bạn, hãy ghi nhớ cấu trúc nhánh logic hơn là cấu trúc vật lý trên đĩa.
  • Đừng phân nhánh quá sâu. Bởi vì cần có thời gian để thực hiện mỗi hợp nhất và giải quyết xung đột, nên cấu trúc phân nhánh sâu có thể có nghĩa là những thay đổi trong nhánh con có thể mất nhiều thời gian để truyền đến nhánh chính. Điều này có thể tác động tiêu cực đến lịch trình dự án và tăng thời gian để sửa lỗi.
  • Chi nhánh ở mức cao và bao gồm các tệp cấu hình và nguồn.
  • Phát triển cấu trúc phân nhánh của bạn theo thời gian.
  • Việc hợp nhất đòi hỏi một hoặc nhiều nhà phát triển để thực hiện hợp nhất và giải quyết xung đột. Nguồn được hợp nhất phải được kiểm tra kỹ lưỡng vì không có gì lạ khi đưa ra các quyết định hợp nhất xấu có thể gây mất ổn định cho việc xây dựng.
  • Việc hợp nhất trên hệ thống phân cấp chi nhánh đặc biệt khó khăn và đòi hỏi bạn phải xử lý thủ công nhiều xung đột có thể được xử lý tự động.  
    Quyết định có tạo chi nhánh có thể được giảm xuống hay không, liệu chi phí sáp nhập xung đột trong thời gian thực có cao hơn chi phí đầu tư của xung đột sáp nhập giữa các chi nhánh ...

• http://kashfarooq.wordpress.com/2009/11/23/bazaar-branching-strargety-with-a-subversion-trunk/

  • http://kashfarooq.wordpress.com/2010/12/16/bazaar-branching-strargety-with-a-subversion-trunk-revised/
  • http://kashfarooq.wordpress.com/2009/11/02/USE-bazaar-feature-branches-with-a-subversion-trunk/
  • http://kashfarooq.wordpress.com/2009/09/08/bazaar-or-git-moving-away-from-subversion/
    ... Có bất kỳ khiếu nại Subversion nào nghe có vẻ quen thuộc không?
    • Bạn được hướng dẫn ngẫu nhiên rằng "bạn cần chạy cập nhật". Sau đó, bạn thực hiện một bản cập nhật - mất nhiều thời gian để hoàn thành. Và cuối cùng, bạn thấy rằng không có thay đổi nào cần phải tải xuống.
    • Bạn được hướng dẫn ngẫu nhiên rằng "bạn cần chạy dọn dẹp".
    • Bạn có vấn đề hợp nhất rất lớn. Ví dụ: bạn sử dụng ReSharper để đổi tên một lớp và một số người khác đã cập nhật lớp đó trong thời gian đó. Sau đó, bạn nhìn thấy lỗi xung đột cây đáng sợ (rùng mình). Hoặc thậm chí tệ hơn, bạn đổi tên toàn bộ không gian tên và thư mục (nhân đôi). Bây giờ bạn thực sự đang ở trong một thế giới của nỗi đau.
    • Sự hợp nhất của bạn có xu hướng ngày càng thủ công. Bạn thường xuyên phải sử dụng WinMerge vì Subversion không có manh mối.
    • Bạn thường chờ đợi Rùa để cập nhật / kiểm tra sửa đổi / bất cứ điều gì.  
       
      Tôi có một kho lưu trữ lật đổ trên ổ USB của tôi. Tôi nhận được xung đột cây và hợp nhất các vấn đề với điều đó và tôi là người dùng duy nhất!  
       
      Vấn đề chính là hợp nhất ...  
       
  • "lật đổ" nghe có vẻ quen thuộc. Thời gian để nghe Joel và Linus ?

• http://social.msdn.microsoft.com/Forums/en/tfsversioncontrol/thread/f127676c-8f05-410c-9a30-0eb43a26a9fa
  thảo luận về thực tiễn tốt nhất cho chiến lược phân nhánh phát hành trong trường hợp phát triển hệ thống.

• http://branchingguidance.codeplex.com/
  "Hướng dẫn phân nhánh máy chủ Microsoft Team Foundation" - tài liệu khổng lồ và chi tiết với các đề xuất phù hợp với các dự án khác nhau: phiên bản HTML tại đây . Chứng tỏ rằng Microsoft không tin vào các chiến lược phân nhánh tiếp cận một kích cỡ phù hợp với tất cả.

• https://stackoverflow.com/questions/597707/best-branching-strargety-when-doing-continupt-integration
  Chiến lược phân nhánh tốt nhất để sử dụng khi bạn muốn thực hiện tích hợp liên tục là gì? ... Câu trả lời phụ thuộc vào quy mô nhóm của bạn và chất lượng kiểm soát nguồn của bạn và khả năng hợp nhất các bộ thay đổi phức tạp chính xác ...

  • http://www.zeroturnaround.com/blog/continupt-integration-and-feature-branches/ phân tích chi tiết hơn về tương tác phân nhánh với tích hợp liên tục, dựa trên kinh nghiệm cụ thể với Hudson / Jenkins - cùng với một vài tài liệu tham khảo hữu ích
    .. Phát hiện lớn nhất của tôi là mặc dù CI liên quan đến việc cam kết, đẩy và nhận phản hồi thường xuyên (nghĩa là cụm CI cung cấp cho bạn thông tin phản hồi rằng máy trạm của bạn không bao giờ có thể cung cấp cho bạn trong cùng một khoảng thời gian), CI thực sự thuần túy thực sự có thêm một yêu cầu nữa - rằng nhóm cần phải làm việc trên cùng một đường cơ sở ...
    Tài liệu được sử dụng
    • Thực tiễn tốt nhất nhiều chi nhánh - đăng lên danh sách Jenkins
    • Có thể xử lý nhiều chi nhánh trong đó một số công việc nên chạy trên mỗi chi nhánh mà không trùng lặp - đăng lên danh sách Jenkins
    • Phát triển song song với các chi nhánh - đăng lên danh sách Jenkins
    • Định cấu hình hoặc tạo công việc Hudson tự động - stackoverflow.com
    • Tích hợp liên tục với phát triển nhiều chi nhánh - stackoverflow.com
    • Xử lý nhiều chi nhánh trong tích hợp liên tục - stackoverflow.com
    • Tích hợp liên tục - Martin Fowler
    • Tích hợp liên tục - Wikipedia

• http://codicesoftware.blogspot.com/2010/03/branching-strargeties.html
  ... CVS và SVN đã không khuyến khích toàn bộ chiến lược phân nhánh / hợp nhất vì họ hoàn toàn không thể làm như vậy ... ... Quy tắc đơn giản: tạo một nhánh nhiệm vụ cho mọi tính năng hoặc lỗi mới mà bạn triển khai ... Nghe có vẻ như quá mức cần thiết cho người dùng SVN / CVS nhưng bạn biết bất kỳ SCM hiện đại nào cũng sẽ cho phép bạn tạo các nhánh trong một giây, do đó không có chi phí thực sự.  
   
  Lưu ý quan trọng: nếu bạn nhìn vào nó một cách cẩn thận, bạn sẽ thấy rằng tôi đang nói về việc sử dụng các nhánh nhiệm vụ như những người thay đổi người giàu ...

• http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.cc_proj.doc/c_bntr_plnbrstrat.htm
  ... Chính sách chi nhánh bị ảnh hưởng mục tiêu của dự án và cung cấp một cơ chế để kiểm soát sự phát triển của cơ sở mã. Có nhiều biến thể của chính sách phân nhánh như các tổ chức sử dụng kiểm soát phiên bản Rational ClearCase. Nhưng cũng có những điểm tương đồng phản ánh sự tuân thủ phổ biến đối với các thực tiễn tốt nhất ...

• http://bloss.open.collab.net/svn/2007/11/branching-strat.html
  ... Mô hình Subversion (hoặc mô hình nguồn mở chung chính xác hơn) là những gì đang được hiển thị trong mô hình trung kế không ổn định .. .

• http://en.wikipedia.org/wiki/Trunk_%28software%29
  Trong lĩnh vực phát triển phần mềm, trunk đề cập đến nhánh (phiên bản) không tên của cây tập tin dưới sự kiểm soát sửa đổi . Các thân cây thường có nghĩa là cơ sở của một dự án mà trên đó phát triển tiến triển. Nếu các nhà phát triển đang làm việc độc quyền trên thân cây, nó luôn chứa phiên bản tiên tiến mới nhất của dự án, nhưng do đó cũng có thể là phiên bản không ổn định nhất. Một cách tiếp cận khác là tách một nhánh ra khỏi thân cây, thực hiện các thay đổi trong nhánh đó và hợp nhất các thay đổi trở lại vào thân cây khi nhánh đã được chứng minh là ổn định và hoạt động. Tùy thuộc vào chế độ phát triển và cam kếtchính sách trung kế có thể chứa phiên bản ổn định nhất hoặc kém ổn định nhất hoặc giữa phiên bản.  
   
  Thông thường công việc của nhà phát triển chính diễn ra trong thân cây và các phiên bản ổn định được phân nhánh và các bản sửa lỗi thường xuyên được hợp nhất từ ​​các nhánh đến thân cây. Khi việc phát triển các phiên bản trong tương lai được thực hiện trong các nhánh không phải là thân cây, nó thường được thực hiện cho các dự án không thay đổi thường xuyên hoặc khi cần thay đổi trong một thời gian dài để phát triển cho đến khi nó sẵn sàng để kết hợp trong thân cây .. .

• http://www.mcqueeney.com/cont/page/tom/20060919
  ... Đây là những ghi chú từ hội thảo trên web về thực tiễn tốt nhất của Subversion , được thực hiện vào ngày 30 tháng 8 năm 2006 bởi CollabNet. ... Hai chiến lược tổ chức: thân cây không ổn định so với thân cây ổn định ... ... TRƯỚC một thân cây không ổn định khi có thể ...

• https://stackoverflow.com/questions/153812/subversion-is-trunk-really-the-best-place-for-the-main-development
  Trong SVN, trunk là nơi được đề xuất cho sự phát triển chính và tôi sử dụng quy ước này cho tất cả các dự án của tôi. Tuy nhiên, điều này có nghĩa là thân cây đôi khi không ổn định hoặc thậm chí bị hỏng ... ... sẽ tốt hơn nếu thực hiện "phát triển hoang dã" trên một số nhánh như / nhánh / dev và chỉ hợp nhất với thân cây khi xây dựng hợp lý chất rắn?

  • ... Thân cây là nơi phát triển liên tục được cho là sẽ xảy ra. Bạn thực sự không nên có vấn đề với mã "bị hỏng", nếu mọi người đang kiểm tra các thay đổi của họ trước khi cam kết. Một nguyên tắc nhỏ là thực hiện cập nhật (lấy tất cả mã mới nhất từ ​​repos) sau khi bạn đã mã hóa các thay đổi của mình. Sau đó xây dựng và làm một số thử nghiệm đơn vị. Nếu mọi thứ được xây dựng và hoạt động, bạn nên kiểm tra nó trong ...
  • ... Thân cây không phải là nơi tốt nhất. Tại tổ chức của chúng tôi, chúng tôi luôn tuân theo cách tiếp cận này: Trunk chứa mã phát hành, vì vậy nó luôn biên dịch. Với mỗi bản phát hành / cột mốc mới, chúng tôi mở một chi nhánh mới. Bất cứ khi nào nhà phát triển sở hữu một vật phẩm, anh ấy / cô ấy sẽ tạo một nhánh mới cho nhánh phát hành này và sáp nhập nó vào một nhánh phát hành chỉ sau khi thử nghiệm nó. Chi nhánh phát hành được sáp nhập vào thân cây sau khi thử nghiệm hệ thống ...

• http://blog.yclian.com/2009/03/usiness-on-branches-and-urdy-trunk.html
  ... Tôi đã từng làm việc trên thân cây vì đối với tất cả các dự án tôi đã làm, đó là tôi nhà phát triển duy nhất hoặc nhóm đảm bảo rằng tất cả mọi người đăng ký mã đã vượt qua các bài kiểm tra cục bộ. Mặt khác, chúng tôi đã tạo (chúng tôi) các nhánh để sửa lỗi, mã lớn cho các tính năng mới, v.v ...  
   
  Khoảng 2 tháng trước, tôi có một phiên git ngắn với Kamal và anh ấy đã chia sẻ với tôi ý tưởng về câu chuyện / chi nhánh . Và khi nhóm của tôi bắt đầu phát triển với nhiều người phát triển hơn, tôi cảm thấy cần phải khuyến khích nhiều chi nhánh hơn và bây giờ điều này đã trở thành một quy tắc. Đối với một dự án với các thử nghiệm tự động được xác định với CI được thiết lập, một thân cây ổn định được đảm bảo và thực tiễn này có thể rất phù hợp với nó.  
   
  Chúng tôi không sử dụng git nhưng Subversion vì đó là cách chúng tôi bắt đầu và chúng tôi vẫn cảm thấy thoải mái với nó bây giờ (hầu hết thời gian) ...

• http://www.ericsink.com/scm/scm_branches.html
  Đây là một phần của cuốn sách trực tuyến có tên Source Control HOWTO , hướng dẫn thực hành tốt nhất về kiểm soát nguồn, kiểm soát phiên bản và quản lý cấu hình ...  
   
  ... Phân nhánh ưa thích của Eric Thực hành ... Giữ một thân cây "về cơ bản không ổn định". Do sự phát triển tích cực của bạn trong thân cây, sự ổn định sẽ tăng lên khi bạn tiếp cận phát hành. Sau khi bạn giao hàng, tạo một chi nhánh bảo trì và luôn giữ cho nó rất ổn định ...  
   
  ... Trong chương tiếp theo tôi sẽ đi sâu vào chủ đề hợp nhất các chi nhánh ...

• http://marc.info/?l=forrest-dev&m=112504297928196&w=2
  Thư bắt đầu của chủ đề thảo luận về các chiến lược phân nhánh cho dự án Forrest của Apache

  • lưu ý hiện tại dự án dường như sử dụng mô hình thân cây không ổn định với các nhánh phát hành:
  • "Công việc phát triển được thực hiện trên thân của SVN ... Có" các nhánh phát hành "của SVN, ví dụ: forrest_07_branch." ( hướng dẫn dự án )
  • "Xây dựng gói ứng viên phát hành ... 17. Tạo chi nhánh bảo trì trong SVN ..." ( Cách phát hành )

• Tài liệu phân nhánh CVR của O'Reilly:
  http://commons.oreilly.com/wiki/index.php/Essential_CVS/Using_CVS/Tagging_and_Branching#Bas Về_ Ổn
  

  • ... Triết lý phân nhánh cơ bản ổn định nói rằng thân cây nên chứa dữ liệu dự án luôn sẵn sàng để phát hành ... ... Các biến thể khoan dung hơn của triết lý này cho phép mọi thứ vượt qua thử nghiệm đơn vị của nhà phát triển được sáp nhập vào Thân cây. Cách tiếp cận thoải mái như vậy đòi hỏi một ứng cử viên phát hành phải được phân nhánh và đưa ra phân tích QA đầy đủ trước khi xuất bản ...
  • ... Triết lý cơ bản không ổn định nói rằng thân cây nên chứa mã mới nhất, bất kể tính ổn định của nó và các ứng cử viên phát hành nên được phân nhánh cho QA.
     
     
    ... Các biến thể nhẹ nhàng hơn cũng cho phép phân nhánh cho mã thử nghiệm, tái cấu trúc và mã trường hợp đặc biệt khác. Việc hợp nhất một chi nhánh trở lại vào thân cây được thực hiện bởi các nhà quản lý của chi nhánh. ...
    • Lưu ý tài nguyên trên không xuất hiện trong bất kỳ tìm kiếm nào tôi thực hiện (hướng dẫn liên quan đến CVS không còn phổ biến nữa?)

• Các thực tiễn tốt nhất trong SCM (bài viết về lực lượng) tại
  http://www.perforce.com/perforce/ con / bestpractices.html
  ... sáu lĩnh vực chung về triển khai SCM và một số thực tiễn tốt nhất chi tiết trong từng lĩnh vực đó. Các chương sau giải thích từng mục ...
  Không gian làm việc, Bộ luật, Phân nhánh, Tuyên truyền thay đổi, Bản dựng, Quy trình ...

Nếu bạn có một số nhóm làm việc trên các tính năng khác nhau cùng một lúc, không có cách nào bạn có thể bỏ qua việc phân nhánh. Bạn nên chia sẻ mã (được thực hiện một phần) với các thành viên trong nhóm, ngăn các nhóm khác nhận được các tính năng chưa hoàn thành của bạn.

Chi nhánh là cách dễ nhất để đạt được điều đó.

Mặc dù thật tốt khi rút ngắn vòng đời của các nhánh và tránh làm việc trên cùng một mô-đun ở hai nhánh cùng một lúc - sau đó bạn sẽ không gặp phải xung đột.

Nhưng gần đây tôi thấy ngày càng có nhiều người theo dõi ý tưởng để không tạo ra các chi nhánh vì việc thực hành tích hợp liên tục, giao hàng liên tục, v.v.

Vâng, có khó khăn hơn để thực hành tích hợp liên tục, giao hàng liên tục, vv cho bạn một cách cụ thể không?

Nếu không, tôi thấy không có lý do để thay đổi cách làm việc của bạn.

Tất nhiên, đó là cách thực hành tốt để theo dõi những gì đang diễn ra và cách thức thực hành tốt nhất hiện tại phát triển. Nhưng tôi không nghĩ rằng chúng ta cần phải từ bỏ các quy trình / công cụ / không có gì chỉ vì X (và / hoặc Y và / hoặc Z) nói rằng họ không còn mốt nữa :-)

Thật là một bộ câu trả lời thú vị. Trong hơn 20 năm qua, tôi chưa bao giờ làm việc tại một công ty thực hiện nhiều hơn việc sử dụng phân nhánh tầm thường (Nói chung chỉ là phát hành chi nhánh).

Hầu hết các địa điểm tôi từng làm việc đều dựa vào kiểm tra khá nhanh và phát hiện / giải quyết va chạm nhanh chóng - Phương pháp Agile dạy rằng bạn có thể giải quyết vấn đề nhanh hơn nếu bạn nhận thấy chúng trong khi cả hai bên đang tích cực suy nghĩ về đoạn mã đó.

Mặt khác, tôi đã không sử dụng git nhiều và có lẽ đó là việc bao gồm thẻ git đã ảnh hưởng đến những câu trả lời này - tôi hiểu rằng nhánh / hợp nhất là một thứ được đưa ra bởi git bởi vì nó rất dễ dàng.

Có, bạn nên sử dụng các nhánh để cô lập bất kỳ nỗ lực phát triển (ít nhất là trung bình). Xem " Khi nào bạn nên phân nhánh? ".

Vấn đề là nhiều hơn để sử dụng các phép hợp nhất chuyển tiếp nhanh (bao gồm lịch sử chi nhánh trong một trường hợp khác), với điều kiện bạn phải xóa hết tất cả các "cam kết điểm kiểm tra trung gian" (có thể là một vấn đề trong trường hợp quay ngược lại hoặc git bisect).
Xem " Tìm hiểu quy trình công việc Git ", để phân biệt các chi nhánh tư nhân (không có nghĩa là bị đẩy) khỏi các chi nhánh công cộng, sẽ được hoàn thành bằng cách hợp nhất ff (sáp nhập nhanh) với điều kiện bạn thực hiện việc dọn dẹp cần thiết trong chi nhánh bạn đang sáp nhập .
Xem thêm " Tại sao git sử dụng hợp nhất chuyển tiếp nhanh theo mặc định? ".

Bạn hoàn toàn nên sử dụng các chi nhánh. Có một số điểm mạnh cho điều đó.

• Bạn có thể kiểm tra công việc khi bạn đi nếu bạn lo lắng về việc mất việc do lỗi HD, mất máy tính xách tay, v.v. và nó sẽ không phá vỡ CI chính.
• Bạn vẫn có thể làm CI, chỉ cần thiết lập CI cục bộ của riêng bạn để xem chi nhánh của bạn.
• Nếu tính năng đột nhiên bị tạm dừng (điều đó không bao giờ xảy ra), bạn có thể đỗ nó.

Quá khó không bao giờ là một cái cớ. Luôn luôn nỗ lực nhiều hơn để làm điều đó đúng.

Nếu hai đội làm việc trên chi nhánh của riêng họ, họ sẽ không thấy những thay đổi của nhóm khác, ngay cả khi cả hai tích hợp masterchi nhánh. Điều đó có nghĩa là các nhánh phát triển của họ sẽ tách ra và nếu một trong các đội hợp nhất với nhau master, nhóm kia phải phản ứng lại rất nhiều thay đổi.

Vì vậy, ngay cả khi bạn có các nhánh cho các tính năng, tôi vẫn khuyến khích bạn thực hiện 'backport' của tất cả các phép tái cấu trúc cho nhánh chính và chỉ giữ nhánh cho các tính năng mới.

• Tái cấu trúc backport

Tôi nghĩ đôi khi có thể dễ dàng hơn khi sử dụng các công tắc tính năng để vô hiệu hóa các tính năng mới, chưa được kiểm tra mà chưa được đưa vào sản xuất. Bằng cách đó, tất cả các đội khác sẽ thấy những thay đổi và không có sự hợp nhất lớn nào xảy ra.

• Sử dụng các tính năng chuyển đổi

Chúng ta vừa mới trải qua điều này (một lần nữa) .. Đầu tiên chúng ta có toàn bộ cuộc tranh luận về GIT / SVN, điều này dẫn chúng ta đến các chiến lược phân nhánh nói chung.

Các công ty lớn hơn đều sử dụng chiến lược dựa trên thân cây, nơi mọi người làm việc trong cùng một chi nhánh, và xây dựng và tích hợp liên tục xảy ra từ chi nhánh đó. Tránh xung đột được thực hiện bằng cách sử dụng mô đun hóa mã, chuyển đổi tính năng và công cụ thông minh. Điều này nghe có vẻ khó khăn .. bởi vì nó là. Nhưng nếu bạn đang có cuộc tranh luận này thì đó là vì bạn đã trở thành nạn nhân của những tưởng tượng của mọi người về việc phân nhánh. Một số tuyên bố họ sử dụng công cụ chèn SCM ở đây với cơ chế phân nhánh quảng cáo tuân thủ hoàn toàn sarbanes-oxley và tất cả đều tuyệt vời. Họ đang nói dối, tự lừa dối bản thân hoặc không làm việc trên cùng một quy mô hệ thống mà bạn đang có.

Phân nhánh và sáp nhập là khó. Đặc biệt là nếu bạn có một doanh nghiệp thường xuyên thay đổi ý định và đòi hỏi phải quay trở lại, v.v.

Câu này có thể cứu mạng bạn: Những gì trong SCM không giống với những gì trong các tạo tác được xây dựng của bạn!

Nếu bạn gặp khó khăn với việc phân nhánh vì bạn đang sử dụng sai SCM của mình. Tất cả chúng ta đã làm điều đó trong nhiều năm. Bạn có một hệ thống tại đó SCM đang được sử dụng để xác định những gì đi vào bản dựng cuối cùng của bạn.

Đó không phải là công việc của SCM. SCM là một máy chủ tập tin được tôn vinh. Công việc xác định tệp nào từ SCM đi vào bản dựng của bạn thuộc về công cụ xây dựng của bạn.

Mô-đun A đang được thực hiện và đi vào bản phát hành hàng tuần của bạn. Mô-đun B là mô-đun A nhưng có dự án X trong đó và nó đang được thực hiện trên cùng một nhánh, nhưng không được tích hợp vào bản phát hành của bạn. Tại một thời điểm nào đó trong tương lai bạn muốn phát hành dự án X. Vì vậy, bạn nói với công cụ xây dựng của mình ngừng đưa vào mô-đun A và bắt đầu đưa vào mô-đun B.

Sẽ có rất nhiều tiếng khóc và vặn vẹo về điều này. Những gì iffery, và hú nói chung. Đó là mức độ cảm xúc xung quanh một cái gì đó đơn giản như một kho lưu trữ tệp, cho dù thông minh như thế nào.

Nhưng có câu trả lời của bạn.

Vấn đề chính với việc phân nhánh là khó khăn trong việc sáp nhập trở lại vào nhánh chính khi quá trình phát triển hoàn tất. Sáp nhập có thể là một quá trình dễ bị lỗi và do đó nên tránh hầu hết thời gian.

Một số trường hợp ngoại lệ đáng chú ý mà tôi thích phân nhánh là để tái cấu trúc lớn, các tính năng khổng lồ mất nhiều thời gian hơn để chạy nước rút hoặc phá vỡ các tính năng sẽ làm gián đoạn sự phát triển của các tính năng khác trong phần lớn lần chạy nước rút đó.

Tôi đề nghị loại chương trình chi nhánh này:

phát hành - thử nghiệm - phát triển

Sau đó, từ sự phát triển, chi nhánh của nhà phát triển và / hoặc theo tính năng.

Mỗi nhà phát triển có một nhánh để chơi và hợp nhất từ ​​đó, sau đó vào nhánh phát triển thường xuyên - lý tưởng mỗi ngày (cung cấp cho nó biên dịch).

Kiểu lược đồ này hoạt động thực sự tốt với nhiều nhà phát triển và nhiều dự án trên cùng một cơ sở mã.

Chúng tôi làm sử dụng ngành, nhưng không phải ở cấp chi tiết về tính năng. Chúng tôi sử dụng các chi nhánh cho mỗi lần chạy nước rút. Phân nhánh về bản chất không phải là một điều xấu IMO, bởi vì nó mô phỏng khái niệm SOC trong tính năng hoặc lớp chạy nước rút. Bạn dễ dàng có thể nhận ra và quản lý chi nhánh thuộc về tính năng hoặc chạy nước rút nào.

IMHO, sau đó trả lời là, CÓ . Chúng ta vẫn nên sử dụng phân nhánh.

Quá trình tại tổ chức của tôi sử dụng rộng rãi các chi nhánh và (một quy trình trông hơi giống) tích hợp liên tục.

Ở cấp độ cao, các nhà phát triển không lo lắng quá nhiều về việc hợp nhất với tuyến chính, họ chỉ cam kết với chi nhánh. một quy trình (bán) tự động kiểm tra các tính năng nào được lên lịch để đi vào tuyến chính, hợp nhất các chi nhánh đó và xây dựng sản phẩm. Quá trình này hoạt động vì chúng tôi thực sự tích hợp quá trình hợp nhất này từ trình theo dõi vấn đề, để công cụ xây dựng biết những nhánh nào cần hợp nhất.