在推送主分支的Git中，開發分支的提交也被推送。這是否應該發生？我正在使用Gitflow

Question

當我開始使用git時，我的工作流程基於Gitflow模型：http://nvie.com/posts/a-successful-git-branching-model/。我認爲主要想法是保持對適當分支的承諾;例如，主分支只有從開發分支合併的提交...即標籤... 0.1。 0.2。 1.0在圖中。我並不完全理解git是如何工作的或者這個工作流程是如何運作的，但這就是我的想法，尤其是因爲該頁面上的圖形只在主分支上顯示這幾個提交，而不是所有的開發。

我把我的回購上升到Bitbucket，並且在開發部門工作時一切順利，但是當我完成開發時，並推高主分支，我發現Bitbucket中的主分支現在包含我在開發分支上所做的所有提交，而我認爲我只包含最後一個提交（我合併的那個）。有人可以解釋爲什麼這樣做，以及這是否是有意的行爲，如果不是我能做些什麼來讓我的工作流程與上述模型一致。我使用Smartgit。

Answer 1

你的分支模型似乎需要指定每個合併--no-ff，迫使會計分錄甚至爲空的合併 - 例如，在你的圖形，你會做的修補程序合併到0.2，它得到一個提交到主分支並且實際上沒有進行任何合併，具有git merge --no-ff hotfixes。在具有un-git-aware管理需求的項目上，這是一個很好的方法。 VonC answered適用於您在某處跳過該模型的--no-ff要求的情況。

對於你確實按照你的模型，只是沒有想到push的行爲，因爲它的行爲：如果你在圖形的歷史回購的大師從1.0簽出，並推送到遠程的主分支，推完成遙控器將提交M2，M4，M5，Y1-6，G1-4，R1和C1-3（根據它們的顏色和垂直順序標記它的提交），並且遠程主分支將提及所有那。

要理解的是，提交歷史很重要，但ref名稱不是，至少不是「首都 - 我」重要。git push

使用本地引用更新遠程引用，同時發送完成給定引用所需的對象。

通常，如果您的回購是項目主要開發的一部分，那麼您正在跟蹤一些「中央」回購商的參考名稱。 Git的默認克隆爲這些設置本地遙控器/原始/ *分支;但其他設置並不罕見—如果你有一個回購項目，你在某個項目的2.1版本上工作，你可以將其他回購的release-v2.1分支作爲你的回購「主」分支。

如果您只想推送提交的結果，而不推送它的歷史記錄，則必須提交包含結果但沒有該歷史記錄的新提交。其他dvcs是由那些以不同程度的反感來構建歷史的人建造的; git認爲這樣的選擇不是它的業務：它提供了（它是）實現你想要的任何模型的工具。 git cherry-pick將通過將指定的提交與其第一個父對象進行比較，然後將該差異應用到當前頭，並使用櫻桃選擇提交的消息進行新的提交。香草git rebase挑選這樣的整個提交序列。我認爲您期待的行爲是git merge --squash; git commit所做的：在提交的歷史中應用差異並忘記它們來自哪裏。如果你這麼做了，那麼在你的分支的歷史上就不會有其他地方的提交。這絕對不是你的圖形試圖傳達的模型。

Answer 2

將development分支合併到master時，您可能會進行快速合併。
與git merge --no-ff相反，哪個（man page）「即使在合併解析爲快進時也創建合併提交」。

這意味着master HEAD僅僅移動到dev HEAD，引用所有dev提交。請參閱「Why does git use fast-forward merging by default?」。

Answer 3

請按照下列步驟操作。也許你會自己找出答案。

• 確保您目前正在正確的分支

  git branch -a //Shows you all the branches 
  git checkout {branch_name} //Make sure you checkout the correct branch 
  

• 確保你有適當的提交日誌中的

  git log --oneline -6 // Show last 6 commits on this branch 
  

• 如果你看到其他分支提交，那麼你可能已將該分支合併到當前分支中，或者您可能錯誤地在該分支中進行了提交。