Chiến lược phân nhánh Git cho dự án Agile

Question

Tôi có một dự án nằm trong Kho lưu trữ Git Stash. Mã sẽ được triển khai trong bốn môi trường (Dev, Test, Stage và Prod). Chúng tôi tuân theo phương pháp Agile. Vì vậy, nhóm dev hoạt động cho cả hoạt động Phát hành và Hoạt động không phát hành (Tương lai). Tôi phải tạo ra các chi nhánh dựa trên yêu cầu này. Dưới đây là kế hoạch của tôi.

Ba nhánh ổn định: chính, phát hành và phát triển.

chính là nhánh mặc định. phát triển sẽ được tạo ra từ chủ. bản phát hành sẽ được tạo từ việc phát triển các chi nhánh tính năng

tính năng -> chúng sẽ được tạo từ phát triển. mỗi nhà phát triển có một chi nhánh tính năng và họ hợp nhất mã vào chi nhánh phát triển khi hoàn thành. do đó triển khai môi trường dev sẽ xảy ra từ nhánh phát triển.

nếu thay đổi cần phải đi Kiểm tra môi trường, chúng tôi có hai cách ở đây. một là hợp nhất chi nhánh phát triển với nhánh phát hành (Triển khai thử nghiệm môi trường sẽ xảy ra từ nhánh phát hành). Chúng tôi không thể thực hiện điều này kể từ khi phát triển chi nhánh có thể có cả hai phát hành và không phát hành thay đổi.

một cách khác là hợp nhất các chi nhánh tính năng trực tiếp vào nhánh phát hành. để mỗi nhà phát triển thay đổi có thể được sáp nhập vào chi nhánh phát hành. Tôi không chắc liệu tôi có thể thực hiện phương pháp này hay không. Ai đó có thể vui lòng cho tôi biết nếu cách này sẽ hoạt động? có cách nào khác để xử lý tình huống này không.

nhánh:

thạc sĩ ngành ---> phát triển chi nhánh -> phát hành chi nhánh

phát triển chi nhánh --- Tính năng branch1 | tính năng branch2 | Tính năng branch3

---

triển khai:

phát triển chi nhánh cho -> triển khai dev

chi nhánh phát hành cho -> triển khai thử nghiệm

chủ chi nhánh cho -> sân khấu và sản triển khai

Tôi không thể hợp nhất phát triển chi nhánh thành chi nhánh phát hành. Vì chi nhánh phát triển cũng có một số thay đổi không được phát hành. Tôi chỉ cần thay đổi bản phát hành trên nhánh phát hành. có thể tính năng các chi nhánh được sáp nhập vào chi nhánh phát hành trực tiếp không? Cách tiếp cận tốt nhất ở đây là gì?

Answer 1

Nghe có vẻ giống tôi, bạn rất gần với việc chọn Git Flow. Trên thực tế, nếu tôi không nhầm, đây là cơ sở của bạn từ chiến lược, bạn mô tả. Điều đó thật tuyệt.

Tôi nghe rằng mối quan tâm chính của bạn là bạn muốn một nhánh "phát triển" không phát hành, giống như một "công cụ vừa thử, có thể không biên dịch" môi trường/chi nhánh. Dòng chảy Git thực sự ủng hộ một "dòng chảy" hướng tới sản xuất. I E. khi mọi thứ được hợp nhất từ ​​chi nhánh của nó vào số phát triển -branch, nó được lên kế hoạch khá nhiều cho bản phát hành tiếp theo (không khẩn cấp). đề nghị

Git dòng chảy của về cách xử lý này, là không hợp nhất một nhiệm vụ/tính năng vào phát triển, cho đến khi nó có thể là đủ sẵn sàng để đi vào giai đoạn tiếp theo/prod phát hành với có thể là một vài bản sửa lỗi.Trong luồng git, bạn sẽ luôn hợp nhất với chuyển tiếp không nhanh (git merge --no-ff FEATURE_BRANCH_NAME) để nếu bạn sắp phát hành/phát hành, và tính năng này không thể sẵn sàng, bạn sẽ đảo ngược (cam kết hợp nhất), do đó xóa nó khỏi số phát triển hoặc phát hành -branch.

tôi nghi ngờ một cuộc thảo luận dài về vấn đề này, nhưng chỉ để pitch, tôi thấy 2 cách có thể để đáp ứng ý tưởng của bạn:

1) Có 2 phát triển nhánh: một cho phát triển, phát triển chi nhánh, sẽ sớm bị loại bỏ để phát hành và phát hành sau một số QA hoặc bất cứ điều gì. Và một cho các công cụ thử nghiệm, sẽ chuyển sang môi trường thử nghiệm/dev (ví dụ: thông qua triển khai liên tục). Hãy gọi nó là dài hạn phát triển (đây là một tên imo quá dài và quá dài, vì vậy hãy tạo một cái tên tốt hơn, hoặc nhóm của bạn sẽ ghét bạn :)).

Suy nghĩ:

• phát triển chi nhánh thường nên được sáp nhập vào dài hạn-phát triển chi nhánh, để luôn giữ cho nó được cập nhật.
• Có thể bạn cần 2 môi trường phát triển để kiểm tra, 1 cho mỗi nhánh.
• Danger: chi nhánh được tạo ra từ dài hạn-phát triển được (có lẽ do nhầm lẫn) sáp nhập vào phát triển có thể kéo nhiều công cụ không sẵn sàng vào phát triển chi nhánh. Giải pháp cho điều này có thể là 1) hợp nhất tính năng-chi nhánh như không nhanh chóng vào dài hạn phát triển và 2) chọn lựa hợp nhất cam kết này thành phát triển. Nhưng điều này là dễ bị lỗi và loại phức tạp, và 1 sai hợp nhất có thể vít lên toàn bộ phát triển chi nhánh, gây ô nhiễm với những thứ chưa sẵn sàng để dàn dựng/sản xuất.

2) Có chỉ 1 phát triển chi nhánh (như bạn đề nghị) và tạo ra phát hành-chi nhánh từ vị thầy

Đây có lẽ là do sự xa cách dễ dàng nhất. Phải mất nhiều nỗ lực hơn từ mỗi nhà phát triển, nhưng ít bị lỗi hơn.

Thủ tục sẽ là:

• Tại mỗi khởi đầu của một nước rút/phát triển chu kỳ, phát hành-quản lý tạo việc phát hành chi nhánh tiếp theo dựa trên chủ. Ví dụ. release-sprint-42, khi được tạo, bằng chi nhánh chính.
• Nhà phát triển tạo chi nhánh-tính năng có cơ sở từ phát triển. Chúng hợp nhất chi nhánh tính năng với số phát triển khi đã sẵn sàng để thử nghiệm, et.c. Giống như bạn hiện đang đề xuất.
• Nếu tính năng là "đúng" và làm việc, hợp nhất cam kết đã được tạo ra từ việc sáp nhập các tính năng chi nhánh thành phát triển được cherry-nhặt với các tùy chọn -m vào release-sprint-42, ví dụgit cherry-pick -m 1 COMMIT_HASH. Ở đây nó thực sự quan trọng để biết, mà cha mẹ bạn đang chọn (trong cha mẹ ví dụ của tôi 1. Phát triển nên đọc và hiểu http://git-scm.com/docs/git-cherry-pick).

Suy nghĩ:

• Danger có thể, đó là một tính năng làm việc trong phát triển chi nhánh có thể không hoạt động trong release-sprint 42- chi nhánh, vì phụ thuộc mất tích. Điều này, cảm ơn Chúa, là lý do tại sao chúng tôi đã dàn dựng môi trường và thời hạn nội bộ :)
• Việc hái hoa anh đào không phải là điều dễ nhất. Nhưng chắc chắn là cách tốt nhất để tránh việc kéo mã không mong muốn thông qua việc hợp nhất vào một nhánh sai.

Vòng lên

nào là sự lựa chọn tốt nhất cho bạn, phụ thuộc vào cách bạn đang phát triển. Nếu bạn có 2 bản nhạc, như "công cụ hỗ trợ hàng ngày" và "tính năng lớn của tôi được lên lịch phát hành vào tháng 12 này", bạn có thể đi đến 2 chi nhánh. Nếu sự phát triển dài hạn không phải là 1 mà là một vài thứ và một điều đang diễn ra (ví dụ nếu bạn thường có nhiều nhiệm vụ, trải qua nhiều lần chạy nước rút/chu kỳ), tôi sẽ chọn tùy chọn 2.

Lý tưởng nhất Mặc dù vậy, tôi sẽ mặc định đề xuất một chiến lược, trong đó các công cụ được chia thành các phần nhỏ và chạy nước rút đủ lớn, một nhiệm vụ/tính năng thường có thể được kết luận (tức là sáp nhập và triển khai!) trong vòng 1 lần chạy nước rút. Nhưng từ kinh nghiệm tôi biết, suy nghĩ mơ hồ đó hiếm khi có thể được thực hiện :)

1 điều cuối cùng: Tôi sẽ thực sự thực sự khuyến khích bạn không có một nhánh phát hành (vĩnh viễn), mà để tạo ra một nhánh mới cho mỗi lần chạy nước rút/chu kỳ, như release-sprint-42, release-sprint-43, et.c. (cho dù bạn căn cứ nó phát triển-chi nhánh trong dòng chảy lý tưởng git hoặc tắt master-chi nhánh trong kịch bản thứ hai, tôi đã đề nghị). Có nhiều phát hành vĩnh viễn-chi nhánh thường xuyên trong kinh nghiệm của tôi dẫn đến mất tích công cụ, hợp nhất vấn đề và xấu khác. Ngoài ra, chính và phát triển phải là các chi nhánh vĩnh viễn.

Mong muốn thảo luận này :)