Tôi đã sử dụng Git được vài tháng trong một dự án với một nhà phát triển khác. Tôi có vài năm kinh nghiệm với SVN , vì vậy tôi đoán rằng tôi mang rất nhiều hành lý cho mối quan hệ.
Tôi đã nghe nói rằng Git là tuyệt vời để phân nhánh và hợp nhất, và cho đến nay, tôi chỉ không thấy nó. Chắc chắn, việc phân nhánh rất đơn giản, nhưng khi tôi cố gắng hợp nhất, mọi thứ sẽ biến thành địa ngục. Bây giờ, tôi đã quen với điều đó từ SVN, nhưng dường như tôi chỉ giao dịch một hệ thống phiên bản phụ cho một hệ thống khác.
Đối tác của tôi nói với tôi rằng các vấn đề của tôi xuất phát từ mong muốn hợp nhất của tôi và tôi nên sử dụng rebase thay vì hợp nhất trong nhiều tình huống. Ví dụ: đây là quy trình công việc mà anh ấy đã đặt ra:
clone the remote repository
git checkout -b my_new_feature
..work and commit some stuff
git rebase master
..work and commit some stuff
git rebase master
..finish the feature
git checkout master
git merge my_new_feature
Về cơ bản, tạo một nhánh tính năng, LUÔN LUÔN rebase từ master sang nhánh và hợp nhất từ nhánh trở lại master. Điều quan trọng cần lưu ý là chi nhánh luôn ở địa phương.
Đây là quy trình làm việc mà tôi bắt đầu với
clone remote repository
create my_new_feature branch on remote repository
git checkout -b --track my_new_feature origin/my_new_feature
..work, commit, push to origin/my_new_feature
git merge master (to get some changes that my partner added)
..work, commit, push to origin/my_new_feature
git merge master
..finish my_new_feature, push to origin/my_new_feature
git checkout master
git merge my_new_feature
delete remote branch
delete local branch
Có hai điểm khác biệt cơ bản (tôi nghĩ): Tôi luôn sử dụng hợp nhất thay vì khởi động lại và tôi đẩy nhánh tính năng của mình (và nhánh tính năng của tôi cam kết) vào kho lưu trữ từ xa.
Lý do của tôi cho chi nhánh từ xa là tôi muốn công việc của mình được sao lưu khi tôi đang làm việc. Kho lưu trữ của chúng tôi được tự động sao lưu và có thể được khôi phục nếu có sự cố. Máy tính xách tay của tôi không, hoặc không triệt để. Do đó, tôi ghét phải có mã trên máy tính xách tay của mình mà không được nhân đôi ở nơi khác.
Lý do của tôi cho việc hợp nhất thay vì rebase là hợp nhất dường như là tiêu chuẩn và rebase dường như là một tính năng nâng cao. Cảm giác ruột của tôi là những gì tôi đang cố gắng không phải là một thiết lập nâng cao, vì vậy việc rebase là không cần thiết. Tôi thậm chí đã đọc cuốn sách Lập trình thực dụng mới trên Git, và chúng bao gồm việc hợp nhất rộng rãi và hầu như không đề cập đến rebase.
Dù sao, tôi đã theo dõi quy trình làm việc của mình trên một chi nhánh gần đây và khi tôi cố gắng hợp nhất nó trở lại thành chủ, tất cả đã đi vào địa ngục. Có hàng tấn xung đột với những thứ không nên quan trọng. Những mâu thuẫn chỉ vô nghĩa với tôi. Tôi mất một ngày để sắp xếp mọi thứ, và cuối cùng lên đến đỉnh điểm buộc phải đẩy chủ nhân từ xa, vì chủ địa phương của tôi đã giải quyết xong mọi mâu thuẫn, nhưng người ở xa vẫn không vui.
Quy trình làm việc "chính xác" cho một cái gì đó như thế này là gì? Git được cho là làm cho việc phân nhánh và hợp nhất trở nên siêu dễ dàng, và tôi chỉ không thấy điều đó.
Cập nhật 2011-04-15
Đây có vẻ là một câu hỏi rất phổ biến, vì vậy tôi nghĩ rằng tôi sẽ cập nhật với kinh nghiệm hai năm kể từ lần đầu tiên tôi hỏi.
Nó chỉ ra rằng quy trình làm việc ban đầu là chính xác, ít nhất là trong trường hợp của chúng tôi. Nói cách khác, đây là những gì chúng tôi làm và nó hoạt động:
clone the remote repository
git checkout -b my_new_feature
..work and commit some stuff
git rebase master
..work and commit some stuff
git rebase master
..finish the feature, commit
git rebase master
git checkout master
git merge my_new_feature
Trên thực tế, quy trình làm việc của chúng tôi có một chút khác biệt, vì chúng tôi có xu hướng thực hiện hợp nhất squash thay vì hợp nhất thô. ( Lưu ý: Điều này còn gây tranh cãi, xem bên dưới. ) Điều này cho phép chúng tôi biến toàn bộ nhánh tính năng của mình thành một cam kết duy nhất trên bản gốc. Sau đó, chúng tôi xóa chi nhánh tính năng của chúng tôi. Điều này cho phép chúng tôi cấu trúc một cách hợp lý các cam kết của chúng tôi trên chủ, ngay cả khi chúng hơi lộn xộn trên các nhánh của chúng tôi. Vì vậy, đây là những gì chúng tôi làm:
clone the remote repository
git checkout -b my_new_feature
..work and commit some stuff
git rebase master
..work and commit some stuff
git rebase master
..finish the feature, commit
git rebase master
git checkout master
git merge --squash my_new_feature
git commit -m "added my_new_feature"
git branch -D my_new_feature
Tranh cãi về Squash Merge - Như một số nhà bình luận đã chỉ ra, việc hợp nhất squash sẽ vứt bỏ tất cả lịch sử trên nhánh tính năng của bạn. Như tên của nó, nó đè bẹp tất cả các cam kết thành một. Đối với các tính năng nhỏ, điều này có ý nghĩa vì nó ngưng tụ nó thành một gói duy nhất. Đối với các tính năng lớn hơn, có lẽ đó không phải là một ý tưởng tuyệt vời, đặc biệt nếu các cam kết cá nhân của bạn đã là nguyên tử. Nó thực sự đi xuống sở thích cá nhân.
Yêu cầu kéo Github và Bitbucket (những người khác?) - Trong trường hợp bạn đang tự hỏi làm thế nào hợp nhất / rebase liên quan đến Yêu cầu kéo, tôi khuyên bạn nên làm theo tất cả các bước trên cho đến khi bạn sẵn sàng hợp nhất trở lại thành chủ. Thay vì kết hợp thủ công với git, bạn chỉ cần chấp nhận PR. Lưu ý rằng điều này sẽ không thực hiện hợp nhất squash (ít nhất là không theo mặc định), nhưng không squash, không chuyển tiếp nhanh là quy ước hợp nhất được chấp nhận trong cộng đồng Pull Request (theo như tôi biết). Cụ thể, nó hoạt động như thế này:
clone the remote repository
git checkout -b my_new_feature
..work and commit some stuff
git rebase master
..work and commit some stuff
git rebase master
..finish the feature, commit
git rebase master
git push # May need to force push
...submit PR, wait for a review, make any changes requested for the PR
git rebase master
git push # Will probably need to force push (-f), due to previous rebases from master
...accept the PR, most likely also deleting the feature branch in the process
git checkout master
git branch -d my_new_feature
git remote prune origin
Tôi đã yêu Git và không bao giờ muốn quay lại SVN. Nếu bạn đang vật lộn, chỉ cần kiên trì với nó và cuối cùng bạn sẽ thấy ánh sáng ở cuối đường hầm.
rebasesự hiểu biết
