Nổi loạn các chi nhánh từ xa trong Git


135

Tôi đang sử dụng kho lưu trữ Git trung gian để phản chiếu kho lưu trữ SVN từ xa, từ đó mọi người có thể sao chép và làm việc. Kho lưu trữ trung gian có chi nhánh chính được khởi động hàng đêm từ SVN ngược dòng và chúng tôi đang làm việc trên các nhánh tính năng. Ví dụ:

remote:
  master

local:
  master
  feature

Tôi có thể đẩy thành công nhánh tính năng của mình trở lại điều khiển từ xa và kết thúc với những gì tôi mong đợi:

remote:
  master
  feature

local:
  master
  feature

Sau đó tôi thiết lập lại chi nhánh để theo dõi điều khiển từ xa:

remote:
  master
  feature

local:
  master
  feature -> origin/feature

Và tất cả đều tốt. Những gì tôi muốn làm từ đây là khởi động lại nhánh tính năng sang nhánh chính trên điều khiển từ xa, nhưng tôi muốn làm điều này từ máy cục bộ của mình. Tôi muốn có thể làm:

git checkout master
git pull
git checkout feature
git rebase master
git push origin feature

Để giữ cho tính năng từ xa chi nhánh được cập nhật với chủ từ xa. Tuy nhiên, phương pháp này khiến Git phàn nàn:

To <remote>
 ! [rejected]        feature -> feature (non-fast-forward)
error: failed to push some refs to '<remote>'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again.  See the
'Note about fast-forwards' section of 'git push --help' for details.

git pullthực hiện thủ thuật nhưng gây ra một cam kết hợp nhất mà tôi muốn tránh. Tôi lo ngại rằng thông điệp nói rõ feature -> featurehơn feature -> origin/featurenhưng đây có thể chỉ là một điều trình bày.

Tôi đang thiếu một cái gì đó, hoặc đi về điều này theo cách hoàn toàn sai? Việc tránh thực hiện rebase trên máy chủ từ xa là không quan trọng, nhưng nó giúp việc khắc phục mọi xung đột hợp nhất từ ​​rebase trở nên khó khăn hơn nhiều.


Tôi đã từng gặp vấn đề tương tự. Tôi muốn bắt đầu một mô hình rebase chi nhánh ( như thế này ). Sau đó, tôi nhận thấy rằng tôi đã mắc một lỗi: Nếu bạn muốn rebase (Bạn không nên đẩy các thay đổi của mình sang tính năng từ xa trước khi bạn thực hiện rebase lên master) Vì vậy, bạn cam kết một số mã cho tính năng của mình. Và bây giờ bạn muốn đẩy nó vào tính năng từ xa của bạn. Bevor bạn làm điều này: -Bạn nên thực hiện tìm nạp và kéo chủ của mình nếu bạn cần. -Bạn nên khởi động lại thành chủ nếu có một số thay đổi trên chủ mà bạn không có trong tính năng của mình. Bây giờ bạn có thể đẩy tính năng này và sẽ không có vấn đề gì.
Markus

Câu trả lời:


185

Nó liên quan đến việc tính năng này được sử dụng bởi một người hay nếu những người khác đang sử dụng nó.

Bạn có thể buộc đẩy sau cuộc nổi loạn nếu đó chỉ là bạn:

git push origin feature -f

Tuy nhiên, nếu những người khác đang làm việc trên nó, bạn nên hợp nhất và không loại bỏ chủ.

git merge master
git push origin feature

Điều này sẽ đảm bảo rằng bạn có một lịch sử chung với những người bạn đang cộng tác.

Ở một cấp độ khác, bạn không nên thực hiện hợp nhất lại. Những gì bạn đang làm là làm ô nhiễm lịch sử của nhánh tính năng của bạn với các cam kết khác không thuộc về tính năng này, khiến công việc tiếp theo với nhánh đó trở nên khó khăn hơn - nổi loạn hay không.

Đây là bài viết của tôi về chủ đề được gọi là chi nhánh cho mỗi tính năng .

Hi vọng điêu nay co ich.


29
+1 cho if others are working on it, you should merge and not rebase off of master, rebase tốt hơn chỉ được sử dụng trên nhánh riêng.
Hendra Uzia

6
Alternativ để git đẩy tính năng gốc -f bạn cũng có thể xóa tính năng từ xa và tính năng đẩy một lần nữa
Markus

2
Hợp nhất chủ vào chi nhánh của bạn sẽ tạo ra một cam kết hợp nhất và sẽ gây ra xung đột với bất kỳ nhánh tính năng mở nào khác từ chủ sau khi các thay đổi của bạn được đẩy.
Steven

+1 cho git push origin feature -f. Trong một số bối cảnh nhất định, có thể cần phải thực hiện rebase ngay cả với các nhánh từ xa. Mấu chốt là biết những gì bạn đang làm. Và chúng ta nên đảm nhận rằng bạn có thể xóa các xác nhận trong repo từ xa.
enagra

33

Rất vui vì bạn đã đưa chủ đề này lên.

Đây là một điều quan trọng / khái niệm trong git mà một người dùng git sẽ được hưởng lợi từ việc biết. git rebase là một công cụ rất mạnh và cho phép bạn kết hợp các cam kết với nhau, xóa các cam kết, v.v. Nhưng như với bất kỳ công cụ mạnh mẽ nào, về cơ bản bạn cần phải biết những gì bạn đang làm hoặc có thể thực sự sai.

Khi bạn đang làm việc tại địa phương và loay hoay với các chi nhánh địa phương, bạn có thể làm bất cứ điều gì bạn muốn miễn là bạn chưa đẩy các thay đổi vào kho lưu trữ trung tâm. Điều này có nghĩa là bạn có thể viết lại lịch sử của riêng bạn, nhưng không phải lịch sử khác. Bằng cách chỉ loay hoay với những thứ địa phương của bạn, sẽ không có bất kỳ tác động nào đến các kho lưu trữ khác.

Đây là lý do tại sao điều quan trọng cần nhớ là một khi bạn đã thực hiện các cam kết, bạn không nên từ chối chúng sau này. Lý do tại sao điều này lại quan trọng, là vì những người khác có thể thực hiện các cam kết của bạn và dựa trên sự đóng góp của bạn cho cơ sở mã và nếu sau đó bạn quyết định chuyển nội dung đó từ nơi này sang nơi khác (phản đối nó) và đẩy những điều đó thay đổi, sau đó những người khác sẽ gặp vấn đề và phải khởi động lại mã của họ. Bây giờ hãy tưởng tượng bạn có 1000 nhà phát triển :) Nó chỉ gây ra rất nhiều việc không cần thiết.


Bị từ chối vì ngôn ngữ xấu: meta.stackexchange.com/questions/22232/iêng
Quyền hạn

1
Cập nhật ngôn ngữ của tôi.
ralphtheninja

5

Bởi vì bạn đã nổi loạn featuretrên đỉnh mới master, địa phương của bạn featurekhông còn là một bước tiến nhanh origin/featurenữa. Vì vậy, tôi nghĩ rằng, trong trường hợp này hoàn toàn ổn để ghi đè kiểm tra chuyển tiếp nhanh bằng cách thực hiện git push origin +feature. Bạn cũng có thể chỉ định điều này trong cấu hình của bạn

git config remote.origin.push +refs/heads/feature:refs/heads/feature

Nếu những người khác làm việc trên đầu trang origin/feature, họ sẽ bị làm phiền bởi bản cập nhật bắt buộc này. Bạn có thể tránh điều đó bằng cách sáp nhập trong mới mastervào featurethay vì rebasing. Kết quả thực sự sẽ là một chuyển tiếp nhanh.


1

Bạn có thể vô hiệu hóa kiểm tra (nếu bạn thực sự chắc chắn rằng bạn biết bạn đang làm gì) bằng cách sử dụng --forcetùy chọn này git push.


15
Vấn đề là, tôi không chắc là tôi thực sự biết mình đang làm gì :)
kfb

@r_: Vui lòng đọc câu trả lời của tôi. Nó có thể giúp bạn hiểu những gì bạn đang làm :)
ralphtheninja
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.