Tweet
Tích hợp các thay đổi:
Như bạn có thể thấy, việc phân nhánh với Git rất dễ dàng và bạn nên sử dụng nó thường xuyên. Ví dụ: nếu bạn đang làm việc trên một chức năng mới, bạn có thể thực hiện nó trong một nhánh có tính năng riêng biệt. Nếu bạn push nó lên kho lưu trữ, người làm việc chung với bạn cũng có thể đóng góp phần của họ hoặc thực hiện kiểm tra code trước khi bạn tích hợp các thay đổi vào nhánh master. Có một số tùy chọn về cách tích hợp các thay đổi từ nhánh này sang nhánh khác. Đầu tiên chúng ta hãy xem xét sự hợp nhất.
Để hợp nhất hai nhánh, bạn cần làm các bước như sau:
• Kiểm tra nhánh master.
• Đưa ra các commit mới nhất.
• Đảm bảo rằng thư mục làm việc của bạn sạch sẽ.
• Sử dụng lệnh tính năng hợp nhất git.
Trong trường hợp lý tưởng, sẽ không có ai làm việc trên nhánh master trong khi bạn phải vật lộn để phát triển tính năng mới. Mặc dù điều đó sẽ hiếm khi xảy ra, nhưng một khi xảy ra trường hợp đó. Git sẽ phát hiện ra rằng tất cả các commit trong nhánh tính năng của bạn nằm ngay trước nhánh master và việc hợp nhất có thể được thực hiện bằng cách phát lại các commit trong nhánh tính năng. Trong trường hợp này, Git không thực sự hợp nhất mà thay vào đó sẽ di chuyển con trỏ nhánh master về phía trước. Đó được gọi là hợp nhất "fast-forward".
Trong các tình huống khác, các nhánh có thể phân nhiều hơn nữa với nhiều commit không liên quan hơn. Trong trường hợp này, Git không thể chỉ di chuyển con trỏ mà phải thực hiện hợp nhất ba chiều. Thuật toán so sánh và hợp nhất các snapshot từ ban đầu của cả hai nhánh đối với nhánh cuối cùng commit. Nếu quá trình hợp nhất tự động diễn ra tốt đẹp và không có xung đột nào được phát hiện, một commit hợp nhất mới sẽ được tạo. Commit này tham gia các nhánh đó. Nếu bất kỳ xung đột hợp nhất nào được phát hiện, commit hợp nhất sẽ không được tạo.
Nó là khá táo bạo để cho phép hợp nhất cũng tự động cam kết. Ngay cả khi không có bất kỳ xung đột nào được phát hiện, nó vẫn xảy ra để các nhà phát triển thực hiện một số thay đổi không tương thích song song. Do đó, không phải là một ý tưởng tồi nếu dừng commit tự động với tùy chọn --no-commit. Bằng cách đó, bạn có thời gian để kiểm tra lại những gì đã được chuẩn bị trong khu vực dàn dựng, cố gắng biên dịch và xây dựng ứng dụng hoặc thậm chí kiểm tra nó trước khi thực hiện hợp nhất theo cách thủ công. Nếu như bạn không hài lòng với kết quả hoặc nếu có xung đột được phát hiện, bạn vẫn có thể quyết định không commit mà hủy hợp nhất bằng lệnh $ git merge --abort. Hành động này cố gắng hoàn nguyên thư mục làm việc của bạn trở lại trạng thái trước đó trước khi hợp nhất được gọi.
Hợp nhất Git sẽ lưu giữ lịch sử hoàn chỉnh và thứ tự thời gian của các commit trong kho lưu trữ. Đó là một tính năng hay, đặc biệt là khi bạn đang làm việc trên một source code ban đầu mà không phải của bạn hoặc một code quá cũ để nhớ tại sao bạn lại tạo ra nó như bạn đã làm. Với lịch sử đầy đủ, bạn có thể xem lại các commit trung gian và cảm nhận ngữ cảnh dễ dàng hơn. Tuy nhiên, làm việc với nhiều người đóng góp, lịch sử có thể trở nên quá nhiều với nhiều commit hợp nhất.
Mặt khác, bạn có thể xây dựng lại nhánh tính năng của bạn trên nhánh master bằng lệnh git rebase. Trong quá trình này, Git trước tiên tìm thấy phần ban đầu chung và ghi nhớ tất cả các snapshot tiếp theo (không phải commit) đã được thực hiện trong nhánh tính năng. Các cam kết ban đầu trong nhánh đó cuối cùng đã bị xóa khỏi lịch sử Git và con trỏ nhánh được chuyển đến đầu của nhánh master. Sau đó, các snapshot được ghi nhớ sẽ được phát lại một lần nữa, dẫn đến các commit gần như giống hệt nhau, nhưng vẫn khác với những ảnh đã bị xóa trước đó. Khi bạn giải quyết các xung đột tiềm ẩn, bạn có thể chuyển sang nhánh master và thực hiện hợp nhất “fast-forward”. Mặc dù lịch sử đã được làm giả, nhưng bạn sẽ có một lịch sử kho lưu trữ rõ ràng.
Trong cả hai trường hợp, sử dụng hợp nhất hoặc tái cơ sở, bạn sẽ nhận được cùng một kết quả. Sự khác biệt chỉ là lịch sử và các vấn đề tiềm ẩn mà bạn có thể gặp phải khi làm việc theo nhóm. Rebase có thể là một lựa chọn hoàn hảo trong trường hợp bạn có một nhánh ngắn hạn mà bạn không push lên kho lưu trữ từ xa. Tuy nhiên, một khi bạn push công việc của mình với tất cả lịch sử chi nhánh của mình cho những người làm việc chung khác, việc giả mạo lịch sử trong môi trường phân tán có thể sẽ trở nên khó khăn.
Ngoài ra còn có một số tùy chọn khác để tích hợp công việc từ chi nhánh này sang chi nhánh khác. Một trong số đó là cherry-pick. Với phương pháp đó, bạn có thể chọn một cam kết duy nhất từ một nhánh và áp dụng nó cho nhánh khác. Trong trường hợp này, Git không tìm kiếm phần ban đầu chung mà thay vào đó, nó chỉ cố gắng áp dụng lại snapshot đã chọn. Đầu tiên, bạn chuyển sang nhánh mà bạn muốn áp dụng commit, sau đó bạn chạy lệnh git cherry-pick <commit-hash>.
Như bạn có thể thấy, việc phân nhánh với Git rất dễ dàng và bạn nên sử dụng nó thường xuyên. Ví dụ: nếu bạn đang làm việc trên một chức năng mới, bạn có thể thực hiện nó trong một nhánh có tính năng riêng biệt. Nếu bạn push nó lên kho lưu trữ, người làm việc chung với bạn cũng có thể đóng góp phần của họ hoặc thực hiện kiểm tra code trước khi bạn tích hợp các thay đổi vào nhánh master. Có một số tùy chọn về cách tích hợp các thay đổi từ nhánh này sang nhánh khác. Đầu tiên chúng ta hãy xem xét sự hợp nhất.
Để hợp nhất hai nhánh, bạn cần làm các bước như sau:
• Kiểm tra nhánh master.
• Đưa ra các commit mới nhất.
• Đảm bảo rằng thư mục làm việc của bạn sạch sẽ.
• Sử dụng lệnh tính năng hợp nhất git.
Trong trường hợp lý tưởng, sẽ không có ai làm việc trên nhánh master trong khi bạn phải vật lộn để phát triển tính năng mới. Mặc dù điều đó sẽ hiếm khi xảy ra, nhưng một khi xảy ra trường hợp đó. Git sẽ phát hiện ra rằng tất cả các commit trong nhánh tính năng của bạn nằm ngay trước nhánh master và việc hợp nhất có thể được thực hiện bằng cách phát lại các commit trong nhánh tính năng. Trong trường hợp này, Git không thực sự hợp nhất mà thay vào đó sẽ di chuyển con trỏ nhánh master về phía trước. Đó được gọi là hợp nhất "fast-forward".
Trong các tình huống khác, các nhánh có thể phân nhiều hơn nữa với nhiều commit không liên quan hơn. Trong trường hợp này, Git không thể chỉ di chuyển con trỏ mà phải thực hiện hợp nhất ba chiều. Thuật toán so sánh và hợp nhất các snapshot từ ban đầu của cả hai nhánh đối với nhánh cuối cùng commit. Nếu quá trình hợp nhất tự động diễn ra tốt đẹp và không có xung đột nào được phát hiện, một commit hợp nhất mới sẽ được tạo. Commit này tham gia các nhánh đó. Nếu bất kỳ xung đột hợp nhất nào được phát hiện, commit hợp nhất sẽ không được tạo.
Nó là khá táo bạo để cho phép hợp nhất cũng tự động cam kết. Ngay cả khi không có bất kỳ xung đột nào được phát hiện, nó vẫn xảy ra để các nhà phát triển thực hiện một số thay đổi không tương thích song song. Do đó, không phải là một ý tưởng tồi nếu dừng commit tự động với tùy chọn --no-commit. Bằng cách đó, bạn có thời gian để kiểm tra lại những gì đã được chuẩn bị trong khu vực dàn dựng, cố gắng biên dịch và xây dựng ứng dụng hoặc thậm chí kiểm tra nó trước khi thực hiện hợp nhất theo cách thủ công. Nếu như bạn không hài lòng với kết quả hoặc nếu có xung đột được phát hiện, bạn vẫn có thể quyết định không commit mà hủy hợp nhất bằng lệnh $ git merge --abort. Hành động này cố gắng hoàn nguyên thư mục làm việc của bạn trở lại trạng thái trước đó trước khi hợp nhất được gọi.
Hợp nhất Git sẽ lưu giữ lịch sử hoàn chỉnh và thứ tự thời gian của các commit trong kho lưu trữ. Đó là một tính năng hay, đặc biệt là khi bạn đang làm việc trên một source code ban đầu mà không phải của bạn hoặc một code quá cũ để nhớ tại sao bạn lại tạo ra nó như bạn đã làm. Với lịch sử đầy đủ, bạn có thể xem lại các commit trung gian và cảm nhận ngữ cảnh dễ dàng hơn. Tuy nhiên, làm việc với nhiều người đóng góp, lịch sử có thể trở nên quá nhiều với nhiều commit hợp nhất.
Mặt khác, bạn có thể xây dựng lại nhánh tính năng của bạn trên nhánh master bằng lệnh git rebase. Trong quá trình này, Git trước tiên tìm thấy phần ban đầu chung và ghi nhớ tất cả các snapshot tiếp theo (không phải commit) đã được thực hiện trong nhánh tính năng. Các cam kết ban đầu trong nhánh đó cuối cùng đã bị xóa khỏi lịch sử Git và con trỏ nhánh được chuyển đến đầu của nhánh master. Sau đó, các snapshot được ghi nhớ sẽ được phát lại một lần nữa, dẫn đến các commit gần như giống hệt nhau, nhưng vẫn khác với những ảnh đã bị xóa trước đó. Khi bạn giải quyết các xung đột tiềm ẩn, bạn có thể chuyển sang nhánh master và thực hiện hợp nhất “fast-forward”. Mặc dù lịch sử đã được làm giả, nhưng bạn sẽ có một lịch sử kho lưu trữ rõ ràng.
Trong cả hai trường hợp, sử dụng hợp nhất hoặc tái cơ sở, bạn sẽ nhận được cùng một kết quả. Sự khác biệt chỉ là lịch sử và các vấn đề tiềm ẩn mà bạn có thể gặp phải khi làm việc theo nhóm. Rebase có thể là một lựa chọn hoàn hảo trong trường hợp bạn có một nhánh ngắn hạn mà bạn không push lên kho lưu trữ từ xa. Tuy nhiên, một khi bạn push công việc của mình với tất cả lịch sử chi nhánh của mình cho những người làm việc chung khác, việc giả mạo lịch sử trong môi trường phân tán có thể sẽ trở nên khó khăn.
Ngoài ra còn có một số tùy chọn khác để tích hợp công việc từ chi nhánh này sang chi nhánh khác. Một trong số đó là cherry-pick. Với phương pháp đó, bạn có thể chọn một cam kết duy nhất từ một nhánh và áp dụng nó cho nhánh khác. Trong trường hợp này, Git không tìm kiếm phần ban đầu chung mà thay vào đó, nó chỉ cố gắng áp dụng lại snapshot đã chọn. Đầu tiên, bạn chuyển sang nhánh mà bạn muốn áp dụng commit, sau đó bạn chạy lệnh git cherry-pick <commit-hash>.