Chiến lược chi nhánh Git cho nhóm dev nhỏ

Question

Chúng tôi có một ứng dụng web mà chúng tôi cập nhật và phát hành hầu như hàng ngày. Chúng tôi sử dụng git như VCS của chúng tôi, và chiến lược phân nhánh hiện tại của chúng tôi rất đơn giản và bị phá vỡ: chúng tôi có một nhánh chính và chúng tôi kiểm tra những thay đổi mà chúng tôi cảm thấy hài lòng về nó. Điều này có hiệu quả, nhưng chỉ cho đến khi chúng tôi kiểm tra thay đổi đột ngột.

Có ai có một chiến lược git branch yêu thích cho nhóm nhỏ đáp ứng các yêu cầu sau:

1. trình tốt cho các đội từ 2 đến 3 nhà phát triển
2. quá trình Nhẹ, và không quá nhiều
3. Cho phép các nhà phát triển cách ly công việc trên các bản sửa lỗi và các tính năng lớn hơn một cách dễ dàng
4. Cho phép chúng tôi giữ một nhánh ổn định (cho những khoảnh khắc 'crap' khi chúng tôi phải làm việc với máy chủ sản xuất của chúng tôi)

Lý tưởng nhất, tôi rất muốn nhìn thấy quá trình từng bước của bạn cho một dev làm việc trên một lỗi mới

Answer 1

Bạn có thể hưởng lợi từ quy trình làm việc Scott Chacon mô tả trong Pro Git. Trong quy trình làm việc này, bạn có hai nhánh luôn tồn tại, chính và phát triển.

master đại diện cho phiên bản ổn định nhất của dự án và bạn chỉ triển khai sản xuất từ ​​chi nhánh này.

phát triển chứa các thay đổi đang diễn ra và có thể không nhất thiết sẵn sàng để sản xuất.

Từ số phát triển chi nhánh, bạn tạo các nhánh chủ đề để làm việc trên các tính năng và bản sửa lỗi riêng lẻ. Khi tính năng/sửa chữa của bạn đã sẵn sàng, bạn hợp nhất tính năng này thành phát triển, tại thời điểm này bạn có thể kiểm tra cách tương tác với các nhánh chủ đề khác mà đồng nghiệp của bạn đã hợp nhất. Sau khi phát triển ở trạng thái ổn định, hãy hợp nhất vào chính. Cần luôn an toàn để triển khai sản xuất từ ​​chính.

Scott mô tả các chi nhánh dài hạn này là "silo" của mã, trong đó mã trong một chi nhánh ít ổn định cuối cùng sẽ "tốt nghiệp" được coi là ổn định hơn sau khi thử nghiệm và phê duyệt chung bởi nhóm của bạn.

Từng bước, công việc của bạn theo mô hình này có thể trông như thế này:

1. Bạn cần phải sửa chữa một lỗi.
2. Tạo chi nhánh gọi là myfix dựa trên chi tiết phát triển chi nhánh.
3. Làm việc trên lỗi trong nhánh chủ đề này cho đến khi nó được sửa.
4. Hợp nhất myfix thành phát triển. Chạy thử nghiệm.
5. Bạn khám phá xung đột khắc phục của mình với một chi nhánh chủ đề khác hisfix mà đồng nghiệp của bạn đã hợp nhất thành phát triển trong khi bạn đang khắc phục.
6. Thực hiện thêm thay đổi trong chi nhánh myfix để giải quyết các xung đột này.
7. Hợp nhất myfix thành phát triển và chạy lại các kiểm tra.
8. Mọi thứ đều hoạt động tốt. Hợp nhất phát triển thành chính.
9. Triển khai để sản xuất từ ​​master bất kỳ lúc nào, bởi vì bạn biết nó ổn định.

Để biết thêm chi tiết về quy trình làm việc này, hãy xem chương Branching Workflows trong Pro Git.

Answer 2

Trong một VCS, có chỉ là một "bậc thầy" chi nhánh cho thấy một cách nhanh chóng giới hạn của nó bởi vì bạn không thể theo đuổi tất cả nỗ lực phát triển cùng một lúc trên một chi nhánh.
Điều đó có nghĩa là bạn cần biết when to branch.

Nhưng trong một DVCS (như trong "phân cấp" VCS), bạn cũng có một publication issue, với các chi nhánh bạn giữ địa phương để kho của bạn, và các chi nhánh bạn đang đẩy hoặc kéo từ.

Trong ngữ cảnh này, hãy bắt đầu bằng cách xác định nỗ lực phát triển đồng thời của bạn và quyết định quy trình xuất bản (đẩy/kéo). Ví dụ (và đây không phải là cách duy nhất):

• prod là một chi nhánh công cộng chỉ đọc với mã sản xuất. Mọi người đều có thể kéo từ nó để:
  • rebase phát triển hiện nay của nó trên đầu trang của nó (để thử nghiệm địa phương, hoặc cho việc tích hợp trên dev địa phương repo một hotfix thực hiện trong repo sản trên cành prod)
  • chi nhánh để thực hiện các tính năng mới (từ một mã ổn định đã biết)
  • chi nhánh để bắt đầu nhánh phát hành tiếp theo (chi tiết đang được sản xuất)
    không ai đẩy trực tiếp vào sản phẩm (do đó chỉ đọc)
• bản phát hành là chi nhánh hợp nhất đọc-ghi, nơi phù hợp cam kết kiến ​​được chọn để trở thành một phần của bản phát hành tiếp theo.
  Mọi người đều có thể đẩy để phát hành để cập nhật bản phát hành tiếp theo.
  Mọi người đều có thể lấy từ bản phát hành đã nói để cập nhật quy trình hợp nhất địa phương của mình.
• featureX là một chi nhánh ghi-đọc riêng (ở chỗ nó không cần phải đẩy tới repo trung gian) và có thể được đẩy/kéo giữa các bản repos của dev. Nó đại diện cho nỗ lực từ trung đến dài hạn, khác với công cụ dev hàng ngày
• đại diện cho nhà phát triển hiện tại và được đẩy/kéo giữa repos nhà phát triển.

Quy trình quản lý bản phát hành khác tồn tại, dưới dạng SO question attests này.

Answer 3

Đọc qua Git Workflow ReinH cho đội Agile đây: http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html

này hoạt động rất tốt cho các đội nhỏ. Mục tiêu ở đây là để đảm bảo mọi thứ có thể không ổn định đi vào một nhánh của một loại nào đó. Chỉ hợp nhất trở lại làm chủ khi bạn sẵn sàng cho mọi người làm việc bên ngoài chi nhánh tính năng để sử dụng nó.

Lưu ý: chiến lược này hầu như không chỉ rõ ràng, nhưng git thực hiện chiến lược này khá dễ dàng.

Answer 4

Sau khi đến với tư cách là một người mới, cố gắng tìm một chiến lược thẳng thắn để dạy cho những nhà phát triển khác chưa bao giờ sử dụng kiểm soát nguồn. Đây là một trong đó phù hợp với http://nvie.com/posts/a-successful-git-branching-model/ Tôi đã thử bằng cách sử dụng quy trình công việc GIT tiêu chuẩn đó trong các trang người đàn ông nhưng nó nhầm lẫn tôi một chút và khán giả của tôi hoàn toàn.

Trong 6 tháng qua, tôi chỉ phải khắc phục xung đột hai lần. Tôi đã thêm các bước để luôn kiểm tra sau khi hợp nhất và để 'tìm nạp và hợp nhất' hoặc 'kéo --rebase' rất nhiều (một lần vào buổi sáng và buổi chiều) trong khi phát triển các tính năng. Chúng tôi cũng sử dụng github.com làm nơi trung tâm để lấy mã mới nhất.

Answer 5

Sử dụng chi nhánh master làm chi nhánh phát triển của bạn và tạo chi nhánh phát hành để thực hiện sửa lỗi.

Mọi tính năng mới sẽ xuất hiện trên master trong cửa sổ phát triển (cam kết trực tiếp hoặc dưới dạng nhánh chủ đề có yêu cầu kéo, tùy thuộc vào bạn - không được hiển thị trong đồ họa). Khi tất cả các tính năng được lên kế hoạch của bạn được triển khai, hãy nhập tính năng cố định và thực hiện kiểm tra. Khi bạn hài lòng, hãy gắn thẻ bản phát hành trên master là v1.0.

Theo thời gian người dùng của bạn sẽ tìm thấy lỗi trong v1.0, do đó bạn sẽ muốn tạo chi nhánh từ thẻ đó (ví dụ: đặt tên sau khi phát hành 1.0) và sửa các lỗi đó trong nhánh. Khi bạn đã có đủ lỗi cố định mà bạn nghĩ rằng nó đảm bảo một bản phát hành mới sau đó gắn thẻ nó là v1.0.1 và hợp nhất lại thành master.

Trong khi đó, một cửa sổ phát triển mới có thể xảy ra trên chi nhánh master mà cuối cùng sẽ được gắn thẻ là v1.1.

Rửa sạch & lặp lại.

Điều này tuân theo Semantic Versioning logic đánh số.

---------(v1.0)--------------------------------(v1.1)-----------------------------> master 
      \          \ 
       ---(v1.0.1)---(v1.0.2)---> 1.0  ---(v1.1.1)---(v1.1.2)---> 1.1 

Answer 6

(Made tôi comment trên câu trả lời riêng của nó, như tôi nên có ban đầu.)

Từ Scott Chacon của Github:

How We Do It Vì vậy, GitHub Flow là gì?

• Bất cứ điều gì trong ngành thạc sĩ là có thể triển khai
• Để làm việc trên một cái gì đó mới, tạo ra một chi nhánh descriptively tên tắt của thạc sĩ (ví dụ: mới OAuth2-phạm vi)
• Cam kết chi nhánh tại địa phương và thường xuyên đẩy công việc của bạn đến chi nhánh được đặt tên tương tự trên máy chủ
• Khi bạn cần thông tin phản hồi hoặc giúp đỡ, hoặc bạn nghĩ rằng chi nhánh đã sẵn sàng cho việc sáp nhập, mở một yêu cầu kéo
• Sau khi ai đó khác đã xem xét và ký tắt vào tính năng , bạn có thể kết hợp nó vào chủ
• Sau khi nó được sáp nhập và đẩy vào 'thầy', bạn có thể và cần triển khai ngay lập tức

Xem toàn bộ bài viết cho biết thêm chi tiết: http://scottchacon.com/2011/08/31/github-flow.html

Lưu ý rằng "kéo yêu cầu" là một phát minh Github, và nó là cái gì đó là nướng vào trang web của họ, chứ không phải Git bản thân: https://help.github.com/articles/using-pull-requests/