Bạn có cảm thấy thoải mái khi hợp nhất mã không?

Question

Sáng nay, tôi đọc hai ý kiến ​​về tái cấu trúc.

• Opinion 1 (Trang không có mặt)
• Opinion 2 (Trang không có mặt)

Họ khuyên nhánh (và sau đó sáp nhập) mã để:

1. Giữ thân cây sạch .
2. Cho phép nhà phát triển thoát khỏi những thay đổi nguy hiểm.

Theo kinh nghiệm của tôi (đặc biệt là với StarTeam của Borland), việc hợp nhất là một hoạt động không có trival. Và vì lý do đó, tôi chỉ chi nhánh khi tôi phải (tức là khi tôi muốn đóng băng một ứng cử viên phát hành).

Về lý thuyết, phân nhánh có ý nghĩa, nhưng cơ chế hợp nhất làm cho nó trở thành một hoạt động rất nguy hiểm.

Câu hỏi của tôi:

• Bạn có cảm thấy đang kết hợp thoải mái?
• Bạn có mã chi nhánh vì các lý do khác ngoài việc đóng băng bản phát hành ứng viên không?

Answer 1

Một số nguyên tắc hướng dẫn lỏng lẻo:

• Chi nhánh muộn và chỉ khi bạn cần phải
• Merge sớm và thường xuyên
• Lấy người thích hợp để làm việc hợp nhất, một trong hai người đã thay đổi hoặc người đã viết phiên bản gốc là tốt nhất

Phân nhánh chỉ là một công cụ khác, bạn cần tìm hiểu cách sử dụng nó một cách hiệu quả nếu bạn muốn có lợi ích tối đa.

Thái độ phân nhánh của bạn có thể khác nhau giữa các dự án nguồn mở được phân phối (chẳng hạn như dự án Git) và dự án phát triển của công ty bạn (có thể chạy trên SVN). Đối với các dự án phân tán, bạn sẽ muốn khuyến khích phân nhánh để tối đa hóa sự đổi mới và thử nghiệm, cho giống thứ hai bạn sẽ muốn kiểm soát chặt chẽ hơn và ra lệnh cho chính sách checkin cho mỗi dòng mã quyết định khi nào phân nhánh nên/không xảy ra, chủ yếu là để "bảo vệ" mật mã.

Đây là một hướng dẫn để phân nhánh:
http://www.vance.com/steve/perforce/Branching_Strategies.html

Dưới đây là một hướng dẫn ngắn với một số thực hành tốt nhất trình độ cao:
https://www.perforce.com/sites/default/files/pdf/high-level-perforce-best-practices.pdf

Answer 2

Chúng tôi sử dụng svn. Chúng tôi chỉ mất khoảng 5 phút để mã chi nhánh. Đó là tầm thường so với số lượng đau nó giúp chúng tôi tiết kiệm từ thân cây rối tung lên.

Answer 3

Tôi sử dụng Subversion và xem xét phân nhánh rất đơn giản và dễ dàng. Vì vậy, để trả lời câu hỏi 1 .. Có.

Lý do phân nhánh có thể thay đổi ồ ạt. Tôi chi nhánh nếu tôi cảm thấy tôi nên. Rất khó để đặt quy tắc và lý do xuống cho tất cả các khả năng.

Tuy nhiên, theo như "Cho phép nhà phát triển thoát khỏi những thay đổi nguy hiểm". bình luận. Tôi hoàn toàn đồng ý với điều đó. Tôi tạo ra một chi nhánh bất cứ khi nào tôi muốn thực sự chơi xung quanh với mã và muốn tôi là nhà phát triển duy nhất làm việc trên nó .. Khi bạn chi nhánh, bạn có thể làm điều đó ...

Answer 4

Phân nhánh có thể gây đau đớn nhưng không nên ' t.

Đó là những dự án giống như git (mercurial, bazar) cho chúng tôi biết về CVS và SVN. Trên git và mercurial, phân nhánh rất dễ dàng. Trên SVN thật dễ dàng nhưng với các dự án lớn, nó có thể là một phần cứng để quản lý (vì thời gian dành cho quá trình phân nhánh/sáp nhập có thể rất dài - so với một số người khác như git và mercurial - và khó khăn nếu không có - xung đột rõ ràng). Điều đó không giúp người dùng không được sử dụng để phân nhánh thường xuyên để có sự tự tin trong phân nhánh. Rất nhiều người dùng không biết sử dụng mạnh mẽ của phân nhánh chỉ giữ cho nó đi để không thêm các vấn đề mới cho các dự án của họ, cho phép sự sợ hãi của không biết làm cho họ xa hiệu quả.

Phân nhánh phải là một công cụ dễ dàng và mạnh mẽ mà chúng tôi phải sử dụng vì bất kỳ lý do nào đủ tốt để phân nhánh.

Một số lý do chính đáng để chi nhánh:

• làm việc trên một tính năng cụ thể song song với những người khác (hoặc trong khi làm việc trên các tính năng khác cách khác nếu bạn đang một mình trên dự án);
• có một số phiên bản thương hiệu của ứng dụng;
• có các phiên bản song song của cùng một ứng dụng - như các kỹ thuật đồng thời phát triển trong cùng một thời điểm bởi một phần của nhóm để xem điều gì hoạt động tốt hơn;
• có tài nguyên của ứng dụng được thay đổi trên một nghệ sĩ/nhà thiết kế (ví dụ trong trò chơi) nhánh cụ thể nơi ứng dụng "ổn định" trong khi các nhánh và thân khác được sử dụng để thêm và gỡ lỗi các tính năng;
• [thêm thông tin hữu ích tại đây]

Answer 5

Phân nhánh là không đáng kể. Hợp nhất là không. Vì lý do đó, chúng tôi hiếm khi chi nhánh bất cứ điều gì.

Answer 6

Sự cố phân nhánh là lý do tại sao tôi sử dụng hệ thống Kiểm soát phiên bản phân tán (Git trong trường hợp của tôi, nhưng cũng có Mercurial và Bazaar) nơi tạo nhánh là tầm thường.

Tôi sử dụng các nhánh sống ngắn mọi lúc để phát triển. Điều này cho phép tôi lộn xộn xung quanh trong kho lưu trữ của riêng tôi, phạm sai lầm và lựa chọn không hợp lệ, và sau đó rebase thay đổi đối với nhánh chính để chỉ những thay đổi rõ ràng được lưu giữ trong lịch sử.

Tôi sử dụng tag s để đánh dấu mã cố định và dễ dàng trong các hệ thống này để quay lại và phân nhánh chúng để sửa lỗi mà không cần tải chi nhánh lâu dài trong cơ sở mã.

Answer 7

Chúng tôi sử dụng svn và đã áp dụng quy tắc cho các thay đổi đột phá chi nhánh. Thay đổi nhỏ được thực hiện ngay trong thân cây.

Chúng tôi cũng phát hành chi nhánh.

Phân nhánh và hợp nhất đã hoạt động tốt cho chúng tôi. Cấp có lần chúng ta phải ngồi và suy nghĩ về cách mọi thứ phù hợp với nhau, nhưng thường svn làm một công việc tuyệt vời của việc sáp nhập tất cả mọi thứ.

Answer 8

Sử dụng SVN, tôi thấy phân nhánh là tương đối không đau. Đặc biệt là nếu bạn định kỳ hợp nhất các thân cây vào chi nhánh của bạn để giữ cho nó từ quá xa đồng bộ.

Answer 9

Tôi sử dụng svn, mất ít hơn một phút để mã chi nhánh. Tôi đã từng sử dụng Clearcase, mất ít hơn một phút để mã chi nhánh. Tôi cũng đã sử dụng các SCM khác, ít hơn và họ không hỗ trợ các chi nhánh hoặc quá đau đớn để sử dụng. Starteam âm thanh như sau này. Vì vậy, nếu bạn không thể chuyển sang một cái hữu ích hơn (thực ra, tôi chỉ nghe những điều xấu về Starteam) thì bạn có thể phải thử một cách tiếp cận khác: phân nhánh thủ công. Điều này liên quan đến việc kiểm tra mã của bạn, sao chép nó vào một thư mục khác và sau đó thêm nó như một thư mục mới. Khi bạn cần hợp nhất, bạn sẽ kiểm tra cả hai thư mục và sử dụng WinMerge để thực hiện hợp nhất, kiểm tra kết quả đến thư mục gốc. Lúng túng và có khả năng khó khăn nếu bạn tiếp tục sử dụng chi nhánh, nhưng nó hoạt động.

mẹo bằng tính năng Phân nhánh không được coi là một sản phẩm hoàn toàn mới. Nó là một nhánh - một thiết bị tương đối ngắn được sử dụng để thực hiện các thay đổi một cách riêng biệt và an toàn cho một thân sản phẩm chính.Bất cứ ai nghĩ rằng sáp nhập là khó hoặc là tái cấu trúc các tệp mã rất nhiều (tức là họ đang đổi tên, sao chép, tạo mới, xóa cũ) rằng nhánh trở thành một điều hoàn toàn khác, hoặc họ giữ chi nhánh quá lâu mà những thay đổi tích lũy chịu ít giống với bản gốc. Bạn có thể giữ một chi nhánh trong một thời gian dài, bạn chỉ cần hợp nhất các thay đổi của bạn lại thường xuyên. Làm điều này và phân nhánh/sáp nhập trở nên rất dễ dàng.

Answer 10

Tôi đã từng tham gia một dự án sử dụng svn và TFS và phân nhánh tự nó là một điều thực sự đơn giản.

Chúng tôi đã sử dụng phân nhánh cho ứng cử viên phát hành cũng như các tính năng lâu dài hoặc thử nghiệm và để cách ly khỏi sự can thiệp của nhóm khác.

Thời điểm đau đớn duy nhất trong phân nhánh là hợp nhất, bởi vì nhánh cũ hoặc được phát triển mạnh có thể khác nhiều so với thân cây và có thể cần nỗ lực đáng kể để hợp nhất lại.

Có nói trên, tôi sẽ nói rằng phân nhánh là một thực hành mạnh mẽ và hữu ích cần được đưa vào tài khoản trong khi phát triển.

Answer 11

Tôi chỉ thực hiện một vài lần, vì vậy tôi không thực sự thoải mái với nó.

Tôi đã thực hiện nó để thực hiện các thí nghiệm thiết kế có thể trải rộng trên một số kiểm tra, vì vậy việc chia nhánh là cách dễ dàng để tự giải phóng khu vườn của bạn. Ngoài ra, nó còn cho phép tôi chi nhánh, vì vậy chúng tôi không mất nhiều thời gian.

Tôi cũng đã thực hiện nó khi thực hiện các thay đổi khác nhau, có thể khiến cho thân cây không thể kết hợp. Nó trở nên rõ ràng trong dự án của tôi rằng tôi phải loại bỏ an toàn kiểu thời gian biên dịch cho một phần lớn của codebase (đi từ generics đến system.object). Tôi biết điều này sẽ mất một lúc và sẽ yêu cầu thay đổi trên tất cả các codebase mà sẽ can thiệp vào công việc của người khác. Nó cũng sẽ phá vỡ xây dựng cho đến khi tôi hoàn thành. Vì vậy, tôi phân nhánh và loại bỏ các generics, làm việc cho đến khi nhánh đó được biên soạn. Sau đó tôi sáp nhập nó trở lại vào thân cây.

Điều này hóa ra khá tốt. Ngăn chặn rất nhiều bước chân, đó là tuyệt vời. Hy vọng rằng không có gì như thế này sẽ trở lại. Đó là một điều hiếm hoi mà một thiết kế sẽ thay đổi yêu cầu loại chỉnh sửa khác nhau mà không dẫn đến nhiều mã bị vứt bỏ ...

Answer 12

Chi nhánh phải được quản lý một cách chính xác để không bị sáp nhập. Theo kinh nghiệm của tôi (với Perforce) việc tích hợp thường xuyên vào nhánh từ dòng chính có nghĩa là sự tích hợp trở lại vào dòng chính diễn ra rất suôn sẻ.

Chỉ có những dịp hiếm hoi khi hợp nhất không thành công. Sự tích hợp liên tục từ dòng chính đến nhánh có thể liên quan đến việc hợp nhất, nhưng chúng chỉ là những chỉnh sửa nhỏ mà các công cụ tự động có thể xử lý mà không có sự can thiệp của con người. Điều này có nghĩa là người dùng không "thấy" những điều này xảy ra.

Do đó, mọi hợp nhất được yêu cầu trong tích hợp cuối cùng cũng có thể được xử lý tự động.

Perforces công cụ hợp nhất 3 chiều là một trợ giúp tuyệt vời khi chúng thực sự cần thiết.

Answer 13

Bạn có cảm thấy thoải mái nhánh mã?

Nó thực sự phụ thuộc vào công cụ tôi đang sử dụng. Với Starteam, phân nhánh thực sự không tầm thường (TBH, Starteam hút nhánh). Với Git, phân nhánh là một hoạt động thường xuyên và rất dễ dàng.

Bạn có mã chi nhánh vì các lý do khác ngoài việc đóng băng ứng cử viên phát hành không?

Vâng, điều này thực sự phụ thuộc vào mẫu điều khiển phiên bản của bạn nhưng câu trả lời ngắn là có. Trên thực tế, tôi đề nghị để đọc bài viết sau đây:

• Version Control for Multiple Agile Teams bởi Henrik Kniberg
• FeatureBranch bởi Martin Fowler

Tôi thực sự thích các mô hình được mô tả trong bài viết đầu tiên và nó có thể được áp dụng với bất kỳ (không phân phối) Phiên bản Hệ thống kiểm soát, bao gồm cả Starteam.

tôi có thể xem xét cách tiếp cận thứ hai (trên thực tế, một kết hợp của các chiến lược cả hai) với (và chỉ với) một Distributed Control Systems Version (DVCS) như Git, Mercurial ...

Answer 14

Làm việc trong một cơ sở mã hàng triệu dòng mã với hàng trăm nhà phát triển phân nhánh là sự xuất hiện hàng ngày. Cuộc sống của chi nhánh thay đổi tùy thuộc vào số lượng công việc đang được thực hiện.

Đối với một sửa chữa nhỏ:

• nhà thiết kế tạo ra một sidebranch ra khỏi dòng chính
• làm thay đổi
• kiểm tra
• đánh giá
• sáp nhập thay đổi tích lũy từ dòng chính để sidebranch
• lặp lại qua một hoặc nhiều bước trước đó
• sáp nhập trở lại vào luồng chính

Đối với một tính năng đa người đội:

• đội làm một sidebranch tính năng ngoài khơi dòng chính
• thành viên trong nhóm cá nhân hoạt động trên tính năng sidebranch như trong "sửa chữa nhỏ "cách tiếp cận và hợp nhất với tính năng sidebranch.
• thủ tục tạm thời theo định kỳ kết hợp các thay đổi tích lũy từ luồng chính để làm nổi bật các trang trại. Các hợp nhất gia tăng nhỏ từ dòng chính đến tính năng sidebranch dễ dàng hơn nhiều để giải quyết.
• khi tính năng hoạt động, làm merge thức từ dòng chính tính năng sidebranch
• tính năng merge sidebranch để dòng chính

Đối với một phiên bản phần mềm của khách hàng:

• làm cho một chi nhánh phát hành
• cung cấp các bản sửa lỗi nếu cần để giải phóng chi nhánh
• các bản sửa lỗi được chuyển đến/từ luồng chính khi cần

Luồng phát hành khách hàng có thể rất tốn kém để hỗ trợ. Yêu cầu tài nguyên thử nghiệm - con người và thiết bị. Sau một hoặc hai năm, kiến ​​thức của nhà phát triển về các luồng cụ thể bắt đầu trở nên cũ khi luồng chính di chuyển về phía trước.

Bạn có thể tưởng tượng chi phí cho Microsoft để hỗ trợ XP, Vista và Windows 7 đồng thời không? Hãy suy nghĩ về các giường thử nghiệm, quản trị, tài liệu, dịch vụ khách hàng và cuối cùng là các nhóm phát triển.

Quy tắc vàng: Không bao giờ phá vỡ luồng chính vì bạn có thể ngăn chặn một số lượng lớn các nhà phát triển. $$$

Answer 15

Chúng tôi sử dụng StarTeam và chúng tôi chỉ phân nhánh khi có yêu cầu (tức là hotfix để sản xuất trong chu kỳ phát hành hoặc dự án kéo dài nhiều cửa sổ phát hành). Chúng tôi sử dụng Xem Nhãn để xác định các bản phát hành và điều đó khiến cho việc tạo chi nhánh trở nên đơn giản sau này khi cần. Tất cả các bản dựng đều dựa trên các nhãn xem này và chúng tôi không xây dựng mã không có nhãn.

Nhà phát triển phải tuân theo mô hình "mã - thử nghiệm - cam kết" và nếu họ cần một chế độ xem cho một số mục đích thử nghiệm hoặc phát triển "nguy hiểm" mà họ tạo và quản lý nó. Tôi quản lý kho lưu trữ và tạo ra các chi nhánh chỉ khi chúng ta cần chúng.Những lần được (nhưng không giới hạn):

• hotfix Sản
• Các dự án có chu kỳ phát triển dài hoặc chồng chéo
• viết lại lan rộng hoặc phát triển thực nghiệm

Các công cụ hợp nhất trong StarTeam không phải là lớn nhất, nhưng tôi vẫn chưa gặp phải vấn đề gì. Bất cứ ai đang làm việc hợp nhất chỉ cần được RẤT nhất định họ biết những gì họ đang làm.

Tạo chế độ xem "Chỉ đọc tham chiếu" trong Nhóm sao và đặt thành cấu hình nổi sẽ cho phép thay đổi trong thân cây tự động hiển thị trong nhánh. Đặt các mục thành chi nhánh khi thay đổi. Điều này là tốt cho những nỗ lực phát triển đồng thời.

Tạo chế độ xem "Chỉ đọc tham chiếu" với cấu hình được gắn nhãn là những gì bạn sẽ sử dụng cho bản sửa lỗi nóng cho bản phát hành sản xuất hiện tại (giả sử bạn đã gắn nhãn chúng).

Answer 16

Phân nhánh là tầm thường, như phần lớn đã trả lời, nhưng hợp nhất, như bạn nói, thì không.

Các phím thực là tách và kiểm tra đơn vị. Hãy thử tách riêng trước chi nhánh của bạn và theo dõi chính để đảm bảo rằng việc tách và giao diện được duy trì. Bằng cách đó khi nó đến thời gian để hợp nhất, nó giống như thay thế một mảnh lego: loại bỏ các mảnh cũ, và mảnh mới phù hợp hoàn hảo ở vị trí của nó. Các bài kiểm tra đơn vị ở đó để đảm bảo rằng không có gì bị hỏng.

Answer 17

Nếu hợp nhất là quá nhiều đau, hãy cân nhắc chuyển sang VCS tốt hơn. Đó sẽ là một nỗi đau lớn hơn, nhưng chỉ một lần.

Answer 18

Phân nhánh và hợp nhất phải khá đơn giản.

• Tôi cảm thấy rất thoải mái khi phân nhánh/hợp nhất.
• phân nhánh được thực hiện vì những lý do khác nhau, tùy thuộc vào mô hình quá trình phát triển của bạn/

Có một vài mô hình chi nhánh khác nhau:

Dưới đây là một

Trunk   
    .  
    .  
    .  
    ..   
    . ....  
    . ... 
    .  ..Release1 
    .  
    .  
    ...   
    . .... 
    . ...Release2 
    .  
    .  
    ..   
    . ... 
    . .. 
    . ...Release3 
    .  
    .  

Bây giờ đây là một điều tò mò. Giả sử Release1 cần một số sửa lỗi. Bây giờ bạn cần phải chi nhánh Release1 để phát triển 1.1. Đó là OK, bởi vì bây giờ bạn có thể chi nhánh R1, làm công việc của bạn, và sau đó hợp nhất trở lại R1 để tạo thành R1.1. Lưu ý cách điều này giữ sự khác biệt rõ ràng giữa các bản phát hành?

Mô hình phân nhánh khác là có tất cả phát triển được thực hiện trên Trunk và mỗi bản phát hành được gắn thẻ, nhưng không phát triển thêm được thực hiện trên bản phát hành cụ thể đó. Các chi nhánh xảy ra để phát triển.

Trunk           
    .               
    .               
    .               
    .Release1   
    .      
    .      
    .     
    .     
    .Release2   
    .     
    .......     
    .  ......  
    .   ...DevVer1 
    .   .  
    .   .    
    .  ...DevVer2 
    .  ....   
    . ....    
    ...      
    .Release3   
     . 

Có thể có một hoặc hai mô hình chi nhánh chính khác, tôi không thể nhớ chúng trên đầu của tôi.

Điểm mấu chốt là, VCS của bạn cần hỗ trợ phân nhánh linh hoạt và hợp nhất. Hệ thống VCS mỗi tệp trình bày một IMO đau lớn (RCS, Clearcase, CVS). SVN được cho là một rắc rối ở đây là tốt, không chắc chắn lý do tại sao.

Mercurial thực hiện công việc tuyệt vời ở đây, cũng như (tôi nghĩ) git.