基准恢復后git分支不等於master

Question

我正在想弄清楚使用GIT的正確方法的想法。 我以為我知道了，但是最近我們遇到了一些問題。 這是我的觀點，非常希望我能解決我的問題。

2個人（稱為A和B）從事同一項目。

A所做的開發工作較少，但他負責審核B並將代碼推送到生產中。

B完成大部分開發工作，但無法進行生產，因此需要A審查並批准其代碼。

到目前為止，我們一直這樣工作：

A正在研究“主”。

B正在分支'dev'上工作-dev是一個遠程分支，B正在推送對其的更改，A可以從遠程分支中提取。

A直接在“主”（已推送到生產）上進行更改。 當B完成某項功能時，A會將“ dev”合並到主節點（git checkout開發人員； git pull； git checkout主節點； git merge開發人員）

B僅在'dev'上工作，並告訴A何時合並。 如果A對主服務器進行了更改，則B會重新設置基礎（git checkout master; git pull; git rebase dev; git checkout dev）

這似乎可以正常工作（並且我們認為這是一種正確的工作方式），但是無論如何，即使在A合並並B重新建立基礎之后，“ dev”也不等於“ master”。

我們做錯了什么，是否應根據需要使用其他方法/工作流程？

Answer 1

我認為您誤會了如何使用git rebase 。 您說B希望將他/她的工作重新基於master ，該開發人員會這樣做：

git checkout master
git pull
git rebase dev
git checkout dev

當您在master上運行git rebase dev時，（粗略地）說要接受master但不在dev所有提交，並嘗試重新應用那些在master之上引入新穎更改的提交。 您可能想要執行以下操作：

git checkout master
git pull
git checkout dev
git rebase master

......使任何新的dev是在上面重新應用master 。 請注意，這些命令后，你只會想到dev和master是一樣的，如果有什么在新的dev 。

作為更一般的評論，找出類似情況的歷史記錄的最簡單方法通常是使用一種工具，該工具向您顯示提交圖的圖形表示。 例如，如果您運行gitk --all ，則應該能夠看到master和dev在哪里，以及為什么它們沒有指向您期望的同一提交。

另外，值得注意的是，為了避免由於重寫已發布的歷史記錄而引起的混亂，當dev分支包含尚未合並到master已發布提交時，B可能希望避免進行重新設置。