Cập nhật chi nhánh Git từ chủ

Tôi mới sử dụng Git và hiện tại tôi đang ở trong tình huống này:

• Tôi có bốn nhánh (chủ, b1, b2 và b3).
• Sau khi tôi làm việc trên b1-b3, tôi nhận ra rằng tôi có một cái gì đó để thay đổi trên nhánh chủ nên có trong tất cả các nhánh khác.
• Tôi đã thay đổi những gì tôi cần mastervà ... đây là vấn đề của tôi:

Làm cách nào để cập nhật tất cả các chi nhánh khác với mastermã chi nhánh?

Bạn có hai lựa chọn:

Đầu tiên là hợp nhất, nhưng điều này tạo ra một cam kết bổ sung cho hợp nhất.

Thanh toán từng chi nhánh:

git checkout b1

Sau đó hợp nhất:

git merge origin/master

Sau đó đẩy:

git push origin b1

Ngoài ra, bạn có thể thực hiện một rebase:

git fetch
git rebase origin/master

Về cơ bản, bạn có hai tùy chọn:

1. Bạn hợp nhất. Điều đó thực sự khá đơn giản và một hoạt động hoàn toàn cục bộ:

   git checkout b1
   git merge master
   # repeat for b2 and b3
   

   Điều này để lại lịch sử chính xác như nó đã xảy ra: Bạn rẽ nhánh từ chủ, bạn đã thực hiện thay đổi cho tất cả các chi nhánh và cuối cùng bạn kết hợp các thay đổi từ chủ vào cả ba nhánh.

   gitcó thể xử lý tình huống này thực sự tốt, nó được thiết kế để hợp nhất xảy ra theo mọi hướng, cùng một lúc. Bạn có thể tin tưởng rằng nó có thể có được tất cả các chủ đề với nhau một cách chính xác. Nó chỉ đơn giản là không quan tâm đến việc b1hợp nhất chi nhánh master, hoặc masterhợp nhất b1, cam kết hợp nhất trông giống như git. Sự khác biệt duy nhất là, nhánh nào kết thúc chỉ vào cam kết hợp nhất này.

2. Bạn nổi loạn. Những người có SVN hoặc nền tương tự tìm thấy điều này trực quan hơn. Các lệnh tương tự như trường hợp hợp nhất:

   git checkout b1
   git rebase master
   # repeat for b2 and b3
   

   Mọi người thích cách tiếp cận này vì nó giữ lại một lịch sử tuyến tính trong tất cả các chi nhánh. Tuy nhiên, lịch sử tuyến tính này là một lời nói dối, và bạn nên biết rằng nó là. Xem xét biểu đồ cam kết này:

   A --- B --- C --- D <-- master
    \
     \-- E --- F --- G <-- b1
   

   Kết quả hợp nhất trong lịch sử thực sự:

   A --- B --- C --- D <-- master
    \                 \
     \-- E --- F --- G +-- H <-- b1
   

   Cuộc nổi loạn, tuy nhiên, cung cấp cho bạn lịch sử này:

   A --- B --- C --- D <-- master
                      \
                       \-- E' --- F' --- G' <-- b1
   

   Vấn đề là, rằng các cam kết E', F'và G'không bao giờ thực sự tồn tại, và đã có thể không bao giờ được thử nghiệm. Họ thậm chí có thể không biên dịch. Thực sự khá dễ dàng để tạo ra các cam kết vô nghĩa thông qua một rebase, đặc biệt là khi những thay đổi masterquan trọng đối với sự phát triển trong b1.

   Hậu quả của việc này có thể được, mà bạn không thể phân biệt đó trong ba cam kết E, Fvà Gthực sự đã giới thiệu một hồi quy, giảm dần giá trị của git bisect.

   Tôi không nói rằng bạn không nên sử dụng git rebase. Nó có công dụng của nó. Nhưng bất cứ khi nào bạn sử dụng nó, bạn cần phải nhận thức được thực tế rằng bạn đang nói dối về lịch sử. Và ít nhất bạn nên biên dịch thử nghiệm các cam kết mới.

git rebase masterlà cách thích hợp để làm điều này. Hợp nhất sẽ có nghĩa là một cam kết sẽ được tạo ra để hợp nhất, trong khi việc đánh lại thì không.

Nếu bạn đã và đang làm việc trên một chi nhánh, hoặc rất nhiều điều đã xảy ra ở các chi nhánh khác trong khi bạn đang làm việc gì đó, tốt nhất là bạn nên từ chối chi nhánh của mình thành chủ nhân. Điều này giữ cho lịch sử gọn gàng và làm cho mọi thứ dễ dàng hơn để làm theo.

git checkout master
git pull
git checkout local_branch_name
git rebase master
git push --force # force required if you've already pushed

Ghi chú:

• Đừng từ chối các chi nhánh mà bạn đã cộng tác với những người khác.
• Bạn nên rebase trên nhánh mà bạn sẽ hợp nhất mà không phải lúc nào cũng là chủ.

Có một chương về việc nổi loạn tại http://git-scm.com/book/ch3-6.html và vô số tài nguyên khác trên mạng.

@cmaster đã đưa ra câu trả lời công phu nhất. Tóm lại:

git checkout master #
git pull # update local master from remote master
git checkout <your_branch>
git merge master # solve merge conflicts if you have`

Bạn không nên viết lại lịch sử chi nhánh thay vào đó giữ chúng ở trạng thái thực tế để tham khảo trong tương lai. Trong khi hợp nhất với chủ, nó tạo thêm một cam kết nhưng đó là giá rẻ. Cam kết không mất phí.

Để cập nhật các nhánh khác như (sao lưu) với bản sao nhánh chính của bạn. Bạn có thể làm theo một trong hai cách (rebase hoặc merge) ...

1. Thực hiện rebase (sẽ không có bất kỳ cam kết bổ sung nào được thực hiện cho nhánh dự phòng).

2. Hợp nhất các nhánh (sẽ có một cam kết bổ sung tự động cho nhánh dự phòng).

   Lưu ý: Rebase không là gì ngoài việc thiết lập một cơ sở mới (một bản sao mới)

git checkout backup
git merge master
git push

(Lặp lại cho các chi nhánh khác nếu có như backup2 & vv ..,)

git checkout backup
git rebase master
git push

(Lặp lại cho các chi nhánh khác nếu có như backup2 & vv ..,)

Bạn có thể hợp nhất hoặc bạn có thể áp dụng các cam kết riêng lẻ trên các chi nhánh bằng cách sử dụng git cherry-pick .

Có hai lựa chọn cho vấn đề này.

1) git rebase

2) hợp nhất git

Chỉ khác với ở trên cả hai trong trường hợp hợp nhất, sẽ có thêm cam kết trong lịch sử

1) chi nhánh kiểm tra git (b1, b2, b3)

2) git rebase origin / master (Trong trường hợp có xung đột giải quyết cục bộ bằng cách thực hiện git rebase --continue)

3) git đẩy

Ngoài ra, tùy chọn hợp nhất git là thời trang tương tự

1) kiểm tra git "your_branch" (b1, b2, b3)

2) git merge master

3) git đẩy

để cập nhật chi nhánh của bạn từ chủ:

  git checkout master
  git pull
  git checkout your_branch
  git merge master