quản lý phát hành git

Question

Tôi không thể tìm thấy phương pháp "đúng" để quản lý bản phát hành bằng git. Nói, tôi có các nhánh master, release-1, release-2 và release-3. Bản phát hành 1 đã được phát hành và tôi chỉ thực hiện các phiên bản sửa lỗi và phát hành gắn thẻ trên đó. Bản phát hành 2 sắp được phát hành và tôi phát triển chủ yếu trên nhánh này trong khi vào ngày 3, tôi sẽ phát triển những thứ cần thiết trong tương lai.

1. Khi tôi thêm một số tính năng trên phiên bản-2 và nó sẽ đi đến 3 là tốt, nhưng không phải là 1, nên I:

   • merge phát hành-2 để làm chủ và cherry-pick tính năng cam kết liên quan đến release-3?
   • cam kết liên quan đến tính năng cherry-pick để làm chủ và hơn cherry-chọn nó để phát hành-3?
   • sth else?

2. Khi tôi cần thay đổi sth trong tất cả các phiên bản, tôi có nên thực hiện nó trên máy chủ và chọn nó cho tất cả các nhánh không?

3. Tôi có nên giữ cho đến thời điểm cập nhật mới nhất (chi nhánh phát hành-3) hay đúng hơn là nhà phát triển trên bản phát hành 3 và hợp nhất với chủ ngay trước khi tôi cần nhánh phát hành-4?

4. Khi tôi sửa lỗi trên phiên bản release-1 hoặc release-2, tôi có nên hợp nhất hoặc chọn nó để làm chủ hay không?

Tôi không khá chắc chắn khi tôi nên cherry-pick, khi tôi nên sáp nhập và nếu dòng chảy của mã giữa các ngành đó đúng.

Answer 1

Những gì bạn đang yêu cầu thường là một sự cố : điều gì cần hợp nhất từ ​​đâu đến nơi.

Nhưng bạn cũng cần phải nhớ rằng trong một DVCS, một hợp nhất cũng sẽ có ảnh hưởng bởi publication considerations (là những chi nhánh đẩy lên kho địa phương, hoặc những công)

"bậc thầy" chi nhánh đặc biệt là một hiển thị theo mặc định khi ai đó sao chép repo của bạn, có nghĩa là nó sẽ tham chiếu những gì bạn cho là hữu ích nhất cho người dùng/nhà phát triển đó. (Kể từ other branches are not referenced locally by default)

---

1/Khi tôi thêm một số tính năng trên phiên bản-2 và nó sẽ đi đến 3 là tốt, nhưng không phải để 1

Bạn có thể thực sự sáp nhập r2 để làm chủ , sau khi thực hiện một số cam kết với r2 để đạt được các diễn biến cần thiết. Bằng cách đó, chỉ có một số lượng hạn chế các cam kết có thể nhìn thấy trong chủ, tránh "cam kết lộn xộn".
Tuy nhiên, đối với r3, bạn có thể chọn lựa những gì bạn cần từ r2, nếu r3 đang được đẩy và xuất bản. Nếu không, bạn có thể rebase r3 trên r2. Xem "git workflow and rebase vs merge" câu hỏi

2/Khi tôi cần thay đổi sth trong tất cả các phiên bản, tôi có nên thực hiện nó trên máy chủ và chọn nó cho tất cả các nhánh không?

Bạn nên làm điều đó trên r2, sau đó hợp nhất trên bản gốc và r1 và r3. Bằng cách đó, chỉ có một cam kết được thêm vào các nhánh đó.

3/Tôi có nên giữ cho đến thời điểm cập nhật mới nhất (nhánh phát hành 3) hoặc thay vì phát triển trên bản phát hành 3 và hợp nhất với chủ ngay trước khi tôi cần nhánh phát hành-4 không?

Tùy thuộc vào những gì bạn muốn đồng nghiệp khác của bạn nhìn thấy khi họ sao chép bản ghi nhớ.
Nhưng từ 1 /, tôi thu thập tổng thể là đại diện cho r2 (phát triển hiện nay) và không r3 (trong tương lai, refactoring dài hạn-)

4/Khi tôi sửa chữa sth về phát hành-1 hoặc phát hành-2, nên Tôi hợp nhất hoặc anh đào-chọn nó để làm chủ hay đúng hơn?

• r1: cherry-pick: không phải tất cả những gì bạn đang sửa chữa trên r1 có nghĩa là để được sáp nhập vào sự phát triển hiện nay.
  Thực ra, tôi thà vui vẻ chọn r1 cố định trên r2, đảm bảo mọi thứ hoạt động ở đó, và sau đó kết hợp với chủ.
• r2: hợp nhất. Nếu master đại diện cho r2, thì việc hợp nhất đơn giản là đủ.

Answer 2

Xem bài viết sau trên Junio ​​C Hamano (git duy trì) blog:

• Completing a merge
• Never merging back (khoảng chi nhánh chia hai với ý định không sáp nhập lại)
• Resolving conflicts/dependencies between topic branches early
• Fun with remote branches (1)
• Fun with remote branches (2)

Hãy xem trang gitworkflows thủ công.

Answer 3

tôi sẽ làm:

1) Merge r2 để làm chủ và sau đó làm chủ để r3 (r3 nên có thể chấp nhận tất cả những thay đổi để làm chủ)

2) Cam kết r1, sáp nhập để r2, sáp nhập r2 để làm chủ và sau đó hợp nhất master thành r3

3) Có thể bạn nên dùng master thay vì r3, và chỉ phát triển nhánh rẽ r3 khi bản phát hành đang được chuẩn bị và hợp nhất mọi thay đổi ở đây để làm chủ (đó sẽ là phiên bản tiếp theo). Hoặc sử dụng nhánh "master" và "next" làm Linux.

4) Merge để làm chủ

Tôi nghĩ rằng việc sáp nhập là sạch hơn cherry-hái và nghĩ rằng bạn chỉ nên cherry-pick khi bạn cần phải backport một tính năng hoặc bugfix đến một chi nhánh cũ mà bạn không mong đợi khi cam kết đã được thực hiện (khác cam kết trên các chi nhánh lâu đời nhất/phát hành bạn muốn mã trên).