Đây là thỏa thuận, tôi đã gia nhập một công ty mới và đã được yêu cầu hoàn thành công việc tại một chi nhánh đã không được chạm tới trong gần một năm. Trong khi đó, chi nhánh chính đã phát triển với một tốc độ ổn định. Lý tưởng nhất là tôi muốn hợp nhất tất cả các thay đổi từ nhánh chính vào nhánh tính năng và tiếp tục công việc từ đó, nhưng tôi không chắc chắn làm thế nào để tiếp cận điều này.

Làm cách nào để thực hiện hợp nhất này một cách an toàn trong khi vẫn bảo tồn các thay đổi quan trọng ở cả hai phía của chi nhánh?

Về cốt lõi, làm thế nào để kết hợp hai đoạn mã (có thể không tương thích) là một vấn đề phát triển , không phải là vấn đề kiểm soát phiên bản . Lệnh hợp nhất Git có thể giúp trong quá trình này, nhưng nó phụ thuộc vào hình dạng của vấn đề.

So sánh cả hai phiên bản với cơ sở đầu tiên có ý nghĩa nhất. Điều này sẽ cung cấp cho bạn một ý tưởng về chiến lược tốt nhất để thực hiện điều này. Cách tiếp cận của bạn có thể khác nhau dựa trên tính chất và sự chồng chéo của những thay đổi trong mỗi nhánh.

Hãy tưởng tượng kịch bản lý tưởng: bạn sẽ khám phá ra rằng nhánh chính và nhánh tính năng mỗi phần chỉ sửa đổi các phần loại trừ lẫn nhau của mã, vì vậy bạn có thể thực hiện tất cả các thay đổi trong đó và sẽ tốt hơn.

Tất nhiên, điều đó gần như chắc chắn sẽ không xảy ra, nhưng câu hỏi đặt ra là: nó sẽ bị loại bỏ khỏi kịch bản lý tưởng này đến mức nào? tức là xen kẽ những thay đổi như thế nào?

Ngoài ra, làm thế nào trưởng thành là nhánh tính năng cũ? Nó có ở trạng thái hoạt động tốt hay không (hoặc chưa biết)? Bao nhiêu tính năng đã được hoàn thành?

Nếu mã liên quan trong nhánh chính đã thay đổi rất nhiều trong năm qua hoặc tính năng này không ở trạng thái hoàn thiện, tôi có thể xem xét việc tạo một nhánh mới của tính năng mới nhất và kết hợp lại tính năng cũ một cách thủ công. Điều này sẽ cho phép bạn thực hiện một cách tiếp cận gia tăng để làm cho nó hoạt động.

Nếu bạn thực hiện một sự kết hợp lộn xộn của rất nhiều mã và nó không hoạt động, sẽ rất khó để gỡ lỗi. Nếu chi nhánh chính đã thay đổi rất nhiều trong năm qua, những thay đổi thiết kế lớn có thể cần thiết cho tính năng này để làm cho nó hoạt động. Sẽ không phù hợp để thực hiện những thay đổi này thông qua "giải quyết xung đột", vì điều này sẽ yêu cầu thực hiện tất cả các thay đổi cùng một lúc và hy vọng nó hoạt động. Vấn đề này sẽ được giải quyết bằng khả năng lỗi trong nhánh đã hoàn thành một phần cũ.

Theo kinh nghiệm git hạn chế của tôi, tôi có thể nói rằng đôi khi việc khởi động lại nhánh tính năng lại nhanh hơn nếu chủ đã đi quá xa điểm tách ra.

Hợp nhất hai chi nhánh mà không biết lịch sử đằng sau mã (cho rằng bạn vừa tham gia dự án) thực sự khó khăn và tôi cá rằng ngay cả một nhà phát triển đã theo dõi dự án ngay từ đầu cũng có thể mắc một số sai lầm trong việc hợp nhất.

Điều này tất nhiên có ý nghĩa nếu nhánh tính năng không lớn, nhưng bạn có thể chỉ cần mở nhánh tính năng cũ , mở lại từ chủ và giới thiệu lại các thay đổi theo cách thủ công tạo ra tính năng đó. Tôi biết đó là cách tiếp cận thủ công nhất, nhưng nó cho phép bạn kiểm soát hoàn toàn trong trường hợp thiếu mã hoặc di chuyển mã.

Lập trình cặp với một tiền bối trong trường hợp này sẽ là trường hợp tốt nhất, giúp bạn hiểu rõ hơn về mã.
Nó thậm chí có thể trở nên nhanh hơn, nếu bạn tính đến xung đột hợp nhất và thời gian thử nghiệm!

Tôi nghĩ rằng ít nhất là cố gắng hợp nhất rõ ràng là điều tốt nhất để làm. Nếu điều đó không thành công hoặc trở nên quá khó khăn, thì hãy thử hái anh đào, nếu điều đó sai đi theo cách thủ công.

git-imerge được thiết kế chính xác cho mục đích này. Nó là một công cụ git cung cấp một phương thức để hợp nhất gia tăng . Bằng cách hợp nhất gia tăng, bạn chỉ cần xử lý các va chạm giữa hai phiên bản, không bao giờ hơn. Hơn nữa, số lượng hợp nhất lớn hơn nhiều có thể được thực hiện tự động vì các thay đổi riêng lẻ nhỏ hơn.

Cố gắng hợp nhất đầu đường chính vào một nhánh cũ có thể là một bài tập trong sự thất vọng và làm sâu thêm vết lõm trên bàn bằng trán của bạn.

Tuyến chính không đi đến đâu trong một tháng. Nó cũng có sự phát triển và phát hành. Cố gắng mang tất cả cập nhật trong một hợp nhất nguyên khối có thể là quá sức.

Thay vào đó, hãy bắt đầu bằng cách hợp nhất từ ​​tính năng đầu tiên hợp nhất trở lại vào dòng chính sau khi tách nhánh cũ. Làm cho hợp nhất làm việc. Sau đó, tính năng tiếp theo hợp nhất. Và như vậy. Nhiều trong số các tính năng hợp nhất sẽ hợp nhất mà không có xung đột. Điều quan trọng là phải đảm bảo rằng chức năng hiện tại của nhánh cũ vẫn tương thích với hướng mà tuyến chính đã đi.

Bạn có thể muốn phân nhánh từ người đứng đầu chi nhánh cũ cho vai trò hợp nhất trong các thay đổi khác. Đây là nhiều hơn về việc đảm bảo rằng các cam kết và lịch sử khi ai đó nhìn lại nó rõ ràng và truyền đạt vai trò và chính sách của mỗi chi nhánh là gì. Nhánh cũ là một nhánh tính năng. Một trong những bạn đang làm việc là một chi nhánh tích lũy và hòa giải.

Phần lớn việc này sẽ dễ dàng hơn nếu tính năng cũ hoặc các nhánh phát hành vẫn tồn tại ngoài đó và có thể truy cập dễ dàng (một số nơi có chính sách làm sạch tên của các nhánh cũ hơn một số ngày để danh sách các nhánh không bị áp đảo ).

Điều quan trọng trong tất cả những điều này là đảm bảo rằng bạn kiểm tra và sửa chữa sau khi hợp nhất thành công từng phần của lịch sử tuyến chính vào vị trí. Mặc dù một cái gì đó có thể hợp nhất mà không có xung đột, điều đó chỉ có nghĩa là mã không xung đột. Nếu cách mà tính năng cũ bị truy cập bị phản đối hoặc bị loại bỏ, có thể cần phải sửa lỗi sau khi hợp nhất thành công.

Bên cạnh đó, điều này cũng hoạt động cho các hệ thống kiểm soát phiên bản khác. Thỉnh thoảng tôi cần phải hợp nhất một nhóm svn cụ thể vào một nhánh (hái anh đào) cho một tính năng, sửa nhánh để hoạt động với tính năng đó và sau đó hợp nhất nhóm svn tiếp theo thay vì chỉ thực hiện svn bán buôn hợp nhất.

Mặc dù người ta có thể thực hiện git cherry-pick ở đây và nó cho phép mang lại những cam kết cụ thể , nhưng điều này có một số nhược điểm có thể làm phức tạp quá trình. Lựa chọn anh đào sẽ không hiển thị thông tin về cam kết bạn đã chọn (bạn có thể thêm nó vào thông điệp cam kết). Điều này làm cho việc theo dõi các cam kết trong lịch sử khó hơn.

Hơn nữa, điều đó có nghĩa là bạn sẽ không phát lại chính chủ một cách hiệu quả trên nhánh cũ - bạn sẽ chọn các tính năng có thể không đầy đủ - và các tính năng đó có thể bị lỗi.

Lý do chính mà người ta nên hợp nhất từ các cam kết lịch sử để làm chủ trên nhánh cũ là để có thể giữ, hãy gọi nó là "lịch sử tương lai" của nhánh cũ trong trạng thái mà bạn có thể suy luận. Bạn có thể thấy rõ sự hợp nhất từ ​​lịch sử vào nhánh cũ và các bản sửa lỗi để tái hòa nhập chức năng. Các tính năng đang được thêm vào theo thứ tự như chúng đã thành thạo. Và khi bạn đã hoàn tất, và cuối cùng thực hiện việc hợp nhất từ ​​người đứng đầu lên nhánh cũ, bạn biết rằng mọi thứ đã được hợp nhất và bạn không bỏ lỡ bất kỳ cam kết nào.

Bước 1. Tìm hiểu về mã, phân tích kiến ​​trúc của nó và các thay đổi đã được thực hiện trên cả hai nhánh kể từ tổ tiên chung mới nhất.

Bước 2. Nếu tính năng này xuất hiện độc lập rộng rãi và chủ yếu chạm vào các khu vực khác nhau của mã, hợp nhất, sửa lỗi xung đột, kiểm tra, sửa chữa, v.v ... Đó là con đường hạnh phúc, bạn sẽ khá tốt để đi. Nếu không, hãy đến Bước 3

Bước 3. Phân tích các lĩnh vực xung đột, hiểu chi tiết về tác động và lý do chức năng. Có thể dễ dàng có xung đột trong các yêu cầu kinh doanh được đưa ra ánh sáng ở đây. Thảo luận với BA, các nhà phát triển khác khi thích hợp. Hãy cảm nhận sự phức tạp liên quan đến việc giải quyết nhiễu.

Bước 4. Trước những điều trên, hãy quyết định xem có nên hợp nhất / chọn cherry / thậm chí cắt chỉ dán những phần không xung đột và viết lại các phần xung đột hay không, hoặc có nên viết lại toàn bộ tính năng từ đầu không .

1. Chuyển sang nhánh được sử dụng làm nhánh phát triển / phát hành chính.

Đây là chi nhánh chứa các thay đổi mới nhất cho hệ thống. Có thể master, core, dev, nó phụ thuộc vào công ty. Trong trường hợp của bạn, nó có thể là mastertrực tiếp.

git checkout master
git pull

Kéo để đảm bảo bạn có phiên bản mới nhất của nhánh phát triển chính.

2. Thanh toán và kéo chi nhánh chứa công việc bạn phải hoàn thành.

Bạn kéo để đảm bảo rằng bạn thực sự có nội dung mới nhất của chi nhánh. Bằng cách kiểm tra trực tiếp, không cần tạo cục bộ trước, bạn đảm bảo không có nội dung mới từ master(hoặc nhánh dev chính tương ứng) trong đó.

git checkout <name of the obsolete branch>
git pull origin <name of the obsolete branch>

3. Hợp nhất nhánh phát triển chính thành nhánh lỗi thời.

Trước khi chạy lệnh sau, hãy đảm bảo, bằng cách nhập git branchhoặc git statusbạn đang ở nhánh lỗi thời.

git merge master

Các git mergelệnh sẽ cố gắng kết hợp các nội dung từ các chi nhánh quy định, trong trường hợp này master, để các chi nhánh bạn hiện tại đang có.

Nhấn mạnh vào sẽ cố gắng . Có thể có xung đột hợp nhất, chỉ cần bạn và bạn giải quyết.

4. Khắc phục xung đột hợp nhất, cam kết và đẩy sửa lỗi xung đột

Sau khi sửa lỗi xung đột hợp nhất trong tất cả các tệp có, giai đoạn, cam kết và đẩy giải quyết xung đột sang origin.

git add .
git commit -m "fixed the merge conflict from the past year to update the branch"
git push

Bạn thường có thể gọi git add .đến giai đoạn tất cả các tệp cho cam kết. Khi xử lý xung đột hợp nhất, bạn muốn tất cả các tệp cần thiết được cập nhật.

Ghi chú bổ sung

Giải quyết xung đột hợp nhất có thể là một công việc tẻ nhạt. Đặc biệt nếu bạn là người mới tại một công ty. Bạn thậm chí có thể không có kiến ​​thức phù hợp để giải quyết tất cả các xung đột hợp nhất một mình.

Dành thời gian của bạn để kiểm tra cẩn thận tất cả các xung đột đã xảy ra và khắc phục chúng một cách thích hợp, trước khi tiếp tục công việc của bạn.

Điều đó có thể xảy ra vì vậy, bạn bắt đầu làm việc trên một chi nhánh cũ một năm, hợp nhất trạng thái phát triển hiện tại vào đó và sẽ không có bất kỳ xung đột hợp nhất nào cả.

Điều này xảy ra khi mặc dù hệ thống đã thay đổi rất nhiều trong năm, nhưng không ai chạm vào các tệp thực sự bị thay đổi trong nhánh một năm tuổi.