簡體   English   中英

在 Git 中重新定位遠程分支

[英]Rebasing remote branches in Git

我正在使用中間 Git 存儲庫來鏡像遠程 SVN 存儲庫,人們可以從中克隆和工作。 中間存儲庫的主分支每晚從上游 SVN 重新定位,我們正在處理功能分支。 例如:

remote:
  master

local:
  master
  feature

我可以成功地將我的功能分支推回遠程,並以我期望的結果結束:

remote:
  master
  feature

local:
  master
  feature

然后我重新設置分支以跟蹤遠程:

remote:
  master
  feature

local:
  master
  feature -> origin/feature

一切都很好。 我想從這里做的是將 feature 分支變基到遠程的 master 分支,但我想從我的本地機器上做這件事。 我希望能夠做到:

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

使遠程功能分支與遠程主機保持同步。 然而,這種方法導致 Git 報錯:

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 pull可以解決問題,但會導致我想避免的合並提交。 我擔心該消息指出feature -> feature而不是feature -> origin/feature ,但這可能只是一種演示。

我是不是遺漏了什么,或者以完全錯誤的方式來解決這個問題? 避免在遠程服務器上進行變基並不重要,但它會使從變基修復任何合並沖突變得更加困難。

這取決於該功能是由一個人使用還是其他人正在使用它。

如果只有你,你可以在 rebase 之后強制推送:

git push origin feature -f

但是,如果其他人正在處理它,您應該合並而不是從 master 中變基。

git merge master
git push origin feature

這將確保您與合作的人有共同的歷史。

在不同的層面上,您不應該進行反向合並。 您正在做的是用不屬於該功能的其他提交污染您的功能分支的歷史記錄,從而使該分支的后續工作更加困難 - 是否重新設置基准。

這是我關於每個功能分支的主題的文章。

希望這可以幫助。

很高興你提出這個話題。

這是 git 中的一件重要事情/概念,許多 git 用戶將從中受益。 git rebase 是一個非常強大的工具,使您能夠將提交壓縮在一起,刪除提交等。但是與任何強大的工具一樣,您基本上需要知道自己在做什么,否則 go 可能真的錯了。

當您在本地工作並與本地分支打交道時,只要您沒有將更改推送到中央存儲庫,您就可以做任何您想做的事情。 這意味着您可以改寫自己的歷史,但不能改寫其他人的歷史。 只處理本地的東西,不會對其他存儲庫產生任何影響。

這就是為什么重要的是要記住,一旦你推送了提交,你以后不應該重新設置它們。 這很重要的原因是,其他人可能會拉入您的提交並將他們的工作基於您對代碼庫的貢獻,並且如果您稍后決定將該內容從一個地方移動到另一個地方(重新定位它)並推送那些更改,然后其他人會遇到問題並不得不重新調整他們的代碼。 現在假設您有 1000 名開發人員:)它只會導致大量不必要的返工。

因為您在新的master之上重新設置了feature ,所以您的本地feature不再是origin/feature的快進。 所以,我認為,在這種情況下,通過執行git push origin +feature來覆蓋快進檢查是非常好的。 您也可以在配置中指定它

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

如果其他人在origin/feature之上工作,他們將受到這種強制更新的干擾。 您可以通過將新的master合並到feature而不是 rebase 來避免這種情況。 結果確實會快進。

您可以通過使用git push--force選項來禁用檢查(如果您確定自己知道自己在做什么)。

我不熟悉使用 GitBash,我在這里為那些使用 Windows 的開發人員添加了一個使用 TortoiseGit(新手的 GUI)的答案:

使用 TortoiseGit 強制使用本地分支重新建立遠程分支

就像上面提到的許多人一樣,如果僅使用您的“私人”回購分支來執行此操作,這意味着沒有人會因為使用您的本地副本重新建立遠程“開發”或“功能”分支而向您扔椅子。 其他已經提交並推動了他們一周價值(或更多)工作的開發人員將從分支的歷史記錄(日志)中刪除。

將無法恢復它們 - 當然,您的共同開發人員仍將對其進行更改,因為他們的 PULL 很可能會拋出錯誤,因為他們將遠遠領先於分支當前歷史或最新提交與他們的。 好東西 Git 是一個分布式版本控制系統。

因此,請小心使用這種恢復遠程分支的能力。 特此警告您。 ;)

如果你和其他人一起在一個功能分支上工作,那么他們很可能已經提交了一些東西。 從那里開始,您不能簡單地推送您的更改,因為它們與提交歷史沖突。 您可以做的是調用git pull ,這是一個 git fetch + git merge 命令。 這將為合並創建另一個提交。

我會盡量避免在您的歷史記錄中進行不必要的合並提交,並通過簡單地調用git pull --rebase來保持您的 git 提交歷史記錄干凈。 這會將您的提交放在現有提交之后。

當然,你應該只添加本地分支的 git 歷史,永遠不要更改遠程分支的 git 歷史。

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM