Tôi có chi nhánh master và chi nhánh develop để thực hiện một vài thay đổi. Tôi cần hợp nhất các thay đổi từ master thành develop, nhưng cuối cùng sẽ hợp nhất mọi thứ từ develop thành master. Tôi có hai công việc khác nhau trong tâm trí:"git pull" hoặc "git merge" giữa các nhánh chính và chi nhánh phát triển
git pull origin master vào develop chi nhánhgit merge master vào develop chi nhánhĐó là cách tốt nhất để làm điều này, và tại sao?
Hãy cẩn thận với việc rebase. Nếu bạn đang chia sẻ chi nhánh phát triển của mình với bất kỳ ai, việc rebase có thể gây ra nhiều thứ. Rebase chỉ tốt cho các chi nhánh địa phương của bạn.
Quy tắc chung, nếu bạn đã đẩy chi nhánh xuất phát, không sử dụng rebase. Thay vào đó, hãy sử dụng hợp nhất.
Tuy nhiên, nó có an toàn để rebase và một 'git push origin rebasedBranch --force' trên một repo riêng? Người dùng duy nhất là bản thân tôi. – k0pernikus
Có, nếu bạn là người dùng duy nhất, tất nhiên là an toàn.Tôi sử dụng git push --force tất cả thời gian khi tôi là người dùng duy nhất. :) –
Tôi lặp lại lời cảnh báo của Eric. Mặc dù, bạn hoàn toàn có thể khôi phục lại nhánh từ xa của chính mình. Chơi xung quanh với cả rebase và hợp nhất và bạn sẽ hiểu được những ưu và khuyết điểm của mỗi và tìm hiểu khi sử dụng chúng. –
Cách tiếp cận tốt nhất cho loại điều này có thể là git rebase. Nó cho phép bạn kéo các thay đổi từ master vào nhánh phát triển của bạn, nhưng để lại tất cả các công việc phát triển của bạn "trên đầu trang" (sau này trong nhật ký commit) những thứ từ master. Khi công việc mới của bạn hoàn tất, quá trình hợp nhất trở lại với trình chủ sẽ rất đơn giản.
Lời khuyên tốt, giả sử' phát triển' không được chia sẻ với bất kỳ ai khác. –
@KarlBielefeldt Nếu 'phát triển' ** được chia sẻ ** với những người đóng góp khác, chúng tôi sẽ cập nhật 'phát triển' như thế nào khi một số hotfix được đẩy trực tiếp vào' master'? Chúng tôi có nên thực hiện hợp nhất hay không, tức là 'git checkout master && git pull --rebase && git checkout phát triển && git merge master'? Tôi để lại một bình luận về câu trả lời bình chọn cao nhất ở trên, cũng nêu chi tiết mối quan tâm này. – modulitos
Quy trình này có hiệu quả nhất đối với tôi:
git checkout -b develop
... thực hiện một số thay đổi ...
... thông báo tổng thể đã được cập nhật ...
... cam kết thay đổi để phát triển ...
git checkout master
git pull
... đưa những thay đổi đó trở lại phát triển ...
git checkout develop
git rebase master
... thực hiện một số thay đổi thêm ...
... cam kết họ để phát triển ...
... ghép lại thành bậc thầy ...
git checkout master
git pull
git merge develop
siêu hữu ích, cảm ơn bạn! – tester
Đây là cách tôi làm việc quá, và tôi thấy nó hoạt động tốt. Có một điều tôi không làm, và đó là 'git pull' ngay trước khi' git merge develop' cuối cùng. Mục đích của việc đó là gì? – crdx
Sau khi ... thông báo chính đã được cập nhật ... một phần, không phải là chủ thanh toán lau thay đổi địa phương của bạn để phát triển nếu bạn không cam kết chúng? – a1an
Nếu bạn không chia sẻ chi nhánh phát triển với bất kỳ ai, thì tôi sẽ chỉ rebase nó mỗi lần master cập nhật, theo cách đó bạn sẽ không hợp nhất commit trong lịch sử của bạn một khi bạn sẽ hợp nhất phát triển trở lại master. Quy trình làm việc trong trường hợp này sẽ là như sau:
> git clone git://<remote_repo_path>/ <local_repo>
> cd <local_repo>
> git checkout -b develop
....do a lot of work on develop
....do all the commits
> git pull origin master
> git rebase master develop
Trên bước này sẽ đảm bảo rằng phát triển chi nhánh của bạn sẽ luôn luôn trên đầu trang của những thay đổi mới nhất từ chi nhánh tổng thể. Khi bạn đã hoàn thành việc phát triển chi nhánh và nó được hoàn trả lại những thay đổi mới nhất về chủ, bạn chỉ có thể hợp nhất lại các thay đổi đó:
> git checkout -b master
> git merge develop
> git branch -d develop
quy tắc của tôi nhỏ là:
rebasecho các chi nhánh với cùng tên ,mergekhác.
ví dụ cho cùng tên sẽ là master, origin/master và otherRemote/master.
nếu develop chỉ tồn tại trong kho lưu trữ cục bộ và luôn dựa trên cam kết origin/master gần đây, bạn nên gọi số master và làm việc trực tiếp. nó đơn giản hóa cuộc sống của bạn, và trình bày những thứ như chúng thực sự là: bạn đang trực tiếp phát triển trên chi nhánh master.
nếu develop được chia sẻ, nó không nên được rebased trên master, chỉ cần sáp nhập trở lại vào nó với --no-ff. bạn đang phát triển trên develop. master và develop có các tên khác nhau, bởi vì chúng tôi muốn chúng là những thứ khác nhau và tách biệt nhau. không làm cho chúng giống nhau với rebase.
Đề nghị đọc: http://nvie.com/posts/a-successful-git-branching-model/ –
'git pull' =' git fetch' + 'git hợp nhất FETCH_HEAD' –