Làm thế nào để git giúp đối phó với kịch bản dưới đây:

Tôi có một nhiệm vụ được chia thành 2 phần: nhiệm vụ phụ trợ và nhiệm vụ frontend. Tôi thực hiện một yêu cầu kéo để hợp nhất các thay đổi phụ trợ và chờ đợi nó được hợp nhất (và phản hồi địa chỉ). Trong khi chờ đợi, tôi thực sự không thể làm việc với các thay đổi ở lối vào vì nó phụ thuộc vào các thay đổi phụ trợ và những thay đổi này chưa có sẵn trên nhánh chính.

Cách tốt nhất để kéo các thay đổi vào nhánh thay đổi từ nhánh thay đổi phụ trợ trong khi nó vẫn đang được xem xét là gì?

Tôi có vấn đề này quá đôi khi. Git rất linh hoạt. Đây là một cách bạn có thể làm điều đó.

Chi nhánh đầu tiên của bạn featureAlà lên để xem xét.

Chi nhánh thứ hai của bạn featureBđang được phát triển và phụ thuộc vào mã trong featureAchi nhánh.

Hợp nhất các featureAchi nhánh vào featureBchi nhánh.

Nếu bạn thực hiện thay đổi cho featureAchi nhánh thì bạn nên hợp nhất featureAchi nhánh vào featureBchi nhánh một lần nữa để kết hợp các thay đổi.

Bạn cũng nên đảm bảo hợp nhất featureAvào thân chính trước, nếu không, khi bạn hợp nhất featureBvào thân chính, bạn sẽ vô tình cũng hợp nhất featureA. Sau khi featureAđược hợp nhất vào thân chính, bạn có thể thoát khỏi featureAnhánh vì featureBchỉ phụ thuộc vào thân chính bây giờ.

Tôi thích nó khi các nhánh tính năng của tôi không phụ thuộc vào nhau nhưng đôi khi chúng làm được và bạn phải lăn lộn với nó.

Giữ, bỏ qua sáp nhập

Đối với phương pháp này, bạn không muốn hợp nhất feature_athành feature_bnhiều lần.

Rebasing đã được đề cập trong các câu trả lời khác, nhưng chỉ để nổi loạn mọi thứ trên master. Những gì bạn muốn làm trong trường hợp của bạn là:

• Bắt đầu feature_btừ feature_a, tức là:

  git checkout feature_a
  git checkout -b feature_b
  

• Bất cứ khi nào feature_athay đổi trong khi nó đang chờ đợi để được sáp nhập vào master, bạn rebase feature_b vào nó:

  ... commit something onto feature_a ...
  git checkout feature_b
  git rebase feature_a
  

• Cuối cùng, ngay sau khi feature_ađược sáp nhập vào master, bạn chỉ cần lấy cái mới mastervà khởi động feature_alại nó lần cuối:

  git checkout master
  git pull origin master
  git checkout feature_b
  git rebase --onto master feature_a feature_b
  

  Cuộc nổi loạn cuối cùng này sẽ ghép tất cả các cam kết đang lơ lửng từ feature_acam kết (hiện không liên quan vì nó đã được sáp nhập vào master) ngay trên master. feature_bBây giờ của bạn là một chi nhánh đơn giản, tiêu chuẩn đi ngay từ master.

EDIT: lấy cảm hứng từ các bình luận, một chút ngẩng cao đầu: nếu bạn cần thực hiện một số thay đổi có ảnh hưởng đến cả hai tính năng, thì hãy chắc chắn đưa nó vào feature_a(và sau đó rebase như được hiển thị). Đừng không làm cho nó trong hai cam kết khác nhau trong cả hai ngành, thậm chí nếu có thể hấp dẫn; như feature_alà một phần của lịch sử feature_b, việc có một thay đổi duy nhất trong hai cam kết khác nhau sẽ sai về mặt ngữ nghĩa và có thể dẫn đến xung đột hoặc "hồi sinh" mã không mong muốn, sau đó.

Bạn đã có một nhánh mà mỗi nhánh tính năng của bạn phụ thuộc và liên tục thay đổi. Nó được gọi là master.

Cách điển hình để một nhánh tính năng giữ đồng bộ với masternó là ở trên đỉnh của nó. Khi masterthay đổi, bạn thường git fetch origin master:master && git rebase mastertrong thư mục làm việc của chi nhánh.

Bạn có thể làm điều tương tự với một nhánh tính năng khác: tiếp tục tìm nạp nó và nổi loạn lên trên nó.

Nếu, vì một số lý do, bạn sẽ cần chuyển các thay đổi của mình sang một chi nhánh khác, bạn có thể chọn các cam kết của mình , không bao giờ trộn lẫn với các cam kết của chi nhánh khác.

Trong trường hợp này, tác vụ frontend có sự phụ thuộc quan trọng vào mã phụ trợ và bạn muốn bắt đầu công việc trên frontend trước khi phần cuối được hoàn thành và được chấp nhận trên master, tôi chỉ cần bắt đầu tác vụ frontend như một nhánh tính năng xuất phát từ nhánh phụ trợ, thay vì phân nhánh frontend trên master.

Một nhánh tính năng sống đủ lâu cần phải hợp nhất trong các thay đổi từ chính thỉnh thoảng (để đảm bảo bạn điều hòa mọi xung đột hợp nhất hoặc ngữ nghĩa như một phần của dev hoạt động trên nhánh tính năng, thay vì là một phần của "đánh giá, qa, hợp nhất- quy trình "làm chủ". Vì vậy, bạn làm điều đó trên nhánh trước của bạn và khi công việc phụ trợ đã được chấp nhận để làm chủ, bạn sẽ nhận được bất kỳ thay đổi nhỏ nào được thực hiện cho phụ trợ như một phần của đánh giá / chấp nhận tự động, theo cùng một lộ trình bạn nhận bất kỳ thay đổi mã khác trên chủ.

Nếu hóa ra nhánh phụ trợ cần nhiều công việc hơn và nó tiếp tục thay đổi trong một khoảng thời gian trước khi được hợp nhất thành chủ (giả sử nếu có vấn đề lớn được tìm thấy trong quá trình xem xét), thì bạn có thể muốn thực hiện sáp nhập định kỳ trực tiếp từ nhánh phụ trợ vào nhánh frontend (vì vậy bạn không tiếp tục dựa vào tất cả các công việc frontend của mình trên mã phụ trợ lỗi thời). Điều này thật dễ dàng nếu bạn là nhà phát triển duy nhất thực hiện cả hai tính năng (vì bạn biết nếu bản thân bạn thực hiện bất kỳ thay đổi lớn nào), nhưng ngay cả khi cả hai tính năng này đều được xử lý song song bởi các nhà phát triển khác nhau thì vẫn ổn; bạn chỉ cần duy trì liên lạc (dù sao bạn cũng cần phải thực hiện các nhiệm vụ song song khi người này có sự phụ thuộc quan trọng vào người khác).

Nếu nó chỉ ra rằng toàn bộ nhánh phụ trợ cần phải bị hủy bỏ và sẽ không bao giờ được hợp nhất (có vẻ như đây sẽ là một vấn đề lớn hiếm khi xảy ra), thì bạn có thể chọn cam kết của mình cho một chi nhánh mới sắp ra chủ không có công việc phụ trợ hoặc bạn áp dụng các cam kết ngược sẽ loại bỏ tất cả mã phụ trợ cho nhánh frontend. Nhưng như tôi có thể thấy, sẽ có nhiều khả năng tạm dừng công việc frontend cho đến khi bạn tìm ra điều gì sẽ thay thế phần phụ trợ mà bạn đang ném ra, và sau đó quyết định làm gì.

Tôi không thấy vấn đề ở đây.

Bạn đã có điều này mỗi lần với masterchi nhánh của mình , nó luôn thay đổi trong khi các tính năng được phát triển và sau đó được hợp nhất.

Vì vậy, trong ví dụ cụ thể của bạn, trước tiên bạn tạo feature_xxx_backendchi nhánh và phát triển các thay đổi phụ trợ. Khi điều này được thực hiện, chi nhánh sẽ được xem xét và sẽ được hợp nhất vào masterkhi hoàn thành đánh giá.

Vì vậy, chỉ cần bắt đầu một chi nhánh khác feature_yyy_frontend,. Bạn có thể sẽ muốn phân nhánh trực tiếp từ đó feature_xxx_backend, để bạn có những thay đổi đó trong tài khoản của bạn. sau đó chỉ cần phát triển tính năng frontend như chi nhánh master.

Khi feature_xxx_backendchi nhánh thay đổi, ví dụ vì có những thứ xuất hiện trong quá trình xem xét cần phải được quảng cáo, chỉ cần thực hiện những thay đổi này và hợp nhất chúng vào feature_yyy_frontendchi nhánh. Sau đó tiếp tục trên nhánh frontend.

Khi đánh giá của nhánh phụ trợ được hoàn thành, nó sẽ được hợp nhất vào master. Tại thời điểm này, nó sẽ là khôn ngoan để rebase các feature_yyy_frontendchi nhánh lên master, vì vậy mà các nhà phê bình chỉ cần xem lại mới thay đổi mà chi nhánh này góp phần vào việc master, và không cần phải xem lại lần nữa những thay đổi được thực hiện cho các phụ trợ (đã được phê duyệt ).

Điều này cũng có thể được thực hiện khi bạn có hai, ba hoặc nhiều nhánh phụ thuộc. Nếu bạn có hai nhánh tính năng mà bạn phụ thuộc, đơn giản hãy tạo một nhánh dẫn xuất có cả hai tính năng được hợp nhất. Chi nhánh từ đó, phát triển tính năng thứ ba, hợp nhất cả hai nhánh tính năng trên đường đi khi mỗi nhánh đó thay đổi. Khi cả hai tính năng được thực hiện và được hợp nhất vào nhánh dẫn xuất, hãy khởi động lại vào đó hoặc nếu chúng được hợp nhất thành chủ, hãy khởi động lại thành chủ.

Rebasing (như được đề xuất ở trên) thực sự mạnh mẽ và giúp giữ một bản ghi rõ ràng về các thay đổi, giúp việc đánh giá dễ dàng hơn nhiều.

Như Polygnome đã đề cập, bạn thực sự có thể hợp nhất nhánh frontend của bạn với nhánh phụ trợ thay vì các bậc thầy. Ngay cả với thiết lập chi nhánh hiện tại bạn có bây giờ, bạn chỉ cần làm:

git checkout frontend
git merge backend

hoặc đơn giản

git merge backend frontend

Hãy ghi nhớ rằng nếu thay đổi phụ trợ không được chấp nhận và cần thêm công việc, bạn sẽ phải hợp nhất các cập nhật từ phụ trợ vào giao diện để tránh xung đột. Khi các thay đổi được chấp nhận vào bản gốc, bạn có thể khởi động lại giao diện của mình trên bản gốc để thoát khỏi các cam kết hợp nhất phụ trợ.

Về mặt kỹ thuật, bạn cũng có thể làm mọi thứ với rebase, nhưng điều đó sẽ làm rối tung lịch sử cam kết của chi nhánh frontend của bạn. Tôi đến từ đâu, đây được coi là thực hành xấu. YMMV

Hầu hết các câu trả lời ở đây mô tả chính xác quá trình hợp nhất các thay đổi từ nhánh thứ hai sang nhánh thứ nhất, nhưng chúng không giải quyết làm thế nào để giảm thiểu số lượng xung đột mà bạn có thể cần giải quyết.

Bất cứ khi nào bạn có hai bộ thay đổi lớn mà bạn muốn xem xét riêng lẻ (như featureAvà featureB), hãy tạo một PR không có nghĩa là được hợp nhất, nhưng để thu thập phản hồi sớm về PoC của featureA.

Mọi người sẽ có thể xem xét nó một cách nhanh chóng (đó chỉ là PoC) và mục tiêu là xác nhận thiết kế hoặc phương pháp tiếp cận chung.

Sau đó, bạn có thể tiếp tục làm việc trên tính năng A, tạo yêu cầu kéo cho nó và chi nhánh và làm việc trên tính năng B.

Sự khác biệt lớn là bây giờ bạn có thể mong đợi featureAkhông thay đổi hoàn toàn: thiết kế và phương pháp đã được xác nhận. Việc xem xét mã và các thay đổi bắt buộc có thể tinh tế và cục bộ hơn là "woops, bạn cần một cách tiếp cận khác". Điều này sẽ giảm thiểu số lượng công việc bạn cần làm để sau này hợp nhất featureBtrên featureAmã của, bất kể phương thức bạn đã chọn.