Chiến lược chi nhánh Git cho nhóm phát triển nhỏ [đã đóng]

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 gần như hàng ngày. Chúng tôi sử dụng git làm 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 chi nhánh chính và chúng tôi kiểm tra các thay đổi mà chúng tôi cảm thấy tốt về nó. Điều này hoạt động, nhưng chỉ cho đến khi chúng tôi kiểm tra một sự thay đổi phá vỡ.

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

1. Hoạt động tốt cho các nhóm từ 2 đến 3 nhà phát triển
2. Nhẹ, và không quá nhiều quá trình
3. Cho phép các nhà phát triển cô lập 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 chi nhánh ổn định (cho những khoảnh khắc 'oh crap' khi chúng tôi phải làm cho máy chủ sản xuất của chúng tôi hoạt động)

Lý tưởng nhất là tôi muốn thấy quy trình từng bước của bạn cho một nhà phát triển làm việc với một lỗi mới

Bạn có thể hưởng lợi từ quy trình làm việc mà 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, làm chủ và phát triển .

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

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

Từ nhánh phát triển , bạn tạo các nhánh chủ đề để làm việc trên các tính năng và sửa lỗi riêng lẻ. Khi tính năng / sửa lỗi của bạn đã sẵn sàng, bạn hợp nhất nó để phát triển , tại thời điểm đó bạn có thể kiểm tra cách nó 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. Khi phát triển ở trạng thái ổn định, hãy hợp nhất nó thành chủ . Nó phải luôn luôn an toàn để triển khai để sản xuất từ chủ .

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

Từng bước, quy trình làm 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 sửa một lỗi.
2. Tạo một nhánh gọi là myfix dựa trên nhánh phát triển .
3. Làm việc với lỗi trong nhánh chủ đề này cho đến khi nó được sửa.
4. Hợp nhất myfix để phát triển . Chạy thử nghiệm.
5. Bạn phát hiện ra mâu thuẫn sửa chữa của bạn với một chi nhánh chủ đề hisfix rằng đồng nghiệp của bạn sáp nhập vào phát triển trong khi bạn đang làm việc trên sửa chữa của bạn.
6. Thực hiện nhiều thay đổi trong nhánh myfix để giải quyết các xung đột này.
7. Hợp nhất myfix để phát triển và chạy thử nghiệm một lần nữa.
8. Mọi thứ đều hoạt động tốt. Hợp nhất phát triển thành chủ .
9. Triển khai để sản xuất từ chủ bất cứ 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 công việc này, hãy xem chương Phân nhánh công việc trong Pro Git.

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

Trong 6 tháng qua tôi chỉ phải sửa hai lần xung đột. 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' pull --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.

(Đưa ra nhận xét của tôi ở trên đó là câu trả lời của riêng tôi, như tôi nên có lúc đầu.)

Từ Scott Chacon của Github:

Làm thế nào chúng ta làm điều đó Vậy, GitHub Flow là gì?

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

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

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

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

Bất kỳ tính năng mới nào sẽ xuất hiện mastertrong cửa sổ phát triển (được cam kết trực tiếp hoặc dưới dạng nhánh chủ đề với 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 theo kế hoạch của bạn được triển khai, hãy đóng băng tính năng và thực hiện kiểm tra. Khi bạn hài lòng, hãy gắn thẻ phát hành masterdưới dạng v1.0.

Theo thời gian, người dùng của bạn sẽ tìm thấy các lỗi trong v1.0đó vì vậy bạn sẽ muốn tạo một nhánh từ thẻ đó (ví dụ: đặt tên cho nó sau khi phát hành 1.0) và sửa các lỗi đó trong nhánh. Khi bạn đã sửa đủ các lỗi 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ó v1.0.1và nhập lại master.

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

Rửa sạch và lặp lại.

Điều này tuân theo logic đánh số ngữ nghĩa .

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

Trong một VCS, việc chỉ có một nhánh "chính" thể hiện nhanh chóng các 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 nhánh.
Điều đó có nghĩa là bạn cần biết khi nào chi nhánh .

Nhưng trong một DVCS (như trong VCS "phi tập trung"), bạn cũng gặp vấn đề về xuất bản , với các nhánh bạn giữ cục bộ cho kho lưu trữ của bạn và các nhánh bạn đang đẩy tới 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). Chẳng hạn (và đây không phải là cách duy nhất):

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

Các quy trình quản lý phát hành khác tồn tại, vì câu hỏi SO này chứng thực .

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

Điều 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ó khả năng không ổn định sẽ đi vào một nhánh nào đó. Chỉ hợp nhất trở lại thành chủ khi bạn đã sẵn sàng cho mọi người làm việc bên ngoài nhánh tính năng để sử dụng nó.

Lưu ý: chiến lược này hầu như không cụ thể, nhưng git làm cho việc thực hiện chiến lược này khá dễ dàng.