在Git中，當推送master分支時，來自開發分支的提交也被推送。 這應該發生嗎？ 我正在使用Gitflow

Question

當我開始使用git時，我的工作流程基於Gitflow模型： http ://nvie.com/posts/a-successful-git-branching-model/。 我以為主要想法是保留對適當分支的承諾。 這樣，例如主分支將僅具有從開發分支中合並的提交...即標記... 0.1。 0.2。 在圖形中為1.0。 我不完全了解git的工作方式或該工作流的工作方式，但這就是我的想法，尤其是因為該頁面上的圖形僅顯示了master分支上的少數提交，也不是所有開發中的提交。

我將回購推到Bitbucket上時，在開發部門工作時一切順利，但是在完成開發后； 然后推上master分支，我發現Bitbucket中的master分支現在包含了我在development分支上所做的所有提交，而我以為我只會包含最后一個提交（我合並到其中的那個）。 有人可以解釋為什么這樣做，以及這是否是預期的行為，如果不是，我可以做些什么來使我的工作流程與上述模型保持一致。 我使用Smartgit。

Answer 1

您的分支模型似乎要求在每次合並中都指定--no-ff ，甚至對於空合並也要強制記賬條目-例如，在圖形中，您將從合並到0.2的修補程序進行合並，這會將一次提交提交到master分支並且實際上並沒有進行任何合並，使用git merge --no-ff hotfixes 。 對於不了解git的管理要求的項目，這是個好方法。 VonC回答了您在某處跳過該模型的--no-ff要求的情況。

對於您確實遵循模型而只是不希望push具有這種行為的情況：如果您在回購中從圖形版本中簽出了版本為1.0的master，然后推送到遠程的master分支，則當推送完成后，將具有提交M2，M4，M5，Y1-6，G1-4，R1和C1-3（根據其顏色和垂直順序標記其提交），而遠程主分支將引用所有這些。

要理解的是，提交歷史很重要，但是引用名稱並不重要，至少“ capital-I”並不重要。 git push

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

通常，如果您的存儲庫是項目主要開發的一部分，則您正在跟蹤一些“中央”存儲庫的引用名稱。 Git的默認克隆為這些設置了本地遠程/ origin / *分支； 但是其他設置一點也不罕見-如果您在某個項目的v2.1上有一個回購，您可能會將其他回購的release-v2.1分支視為回購的“主”分支。

如果您只想推送提交的結果而不推送其歷史記錄，則必須進行一個具有結果但沒有該歷史記錄的新提交。 人們以不同程度的厭惡認為以這種方式構建歷史的人們已經建立了其他的dvc。 git將這樣的選擇視為一項無關緊要的事情：它提供了（實現的）工具來實現您想像的任何模型。 git cherry-pick將進行新提交，方法是將命名的提交與第一個父提交進行比較，然后將該差異應用於帶有摘自櫻桃的提交消息的當前頭部。 Vanilla git rebase像這樣選擇整個提交序列。 我認為您期望的行為是git merge --squash; git commit git merge --squash; git commit是：將差異應用於提交的歷史記錄，而忘記它們的來源。 如果這樣做，分支機構的歷史記錄中將永遠不會出現任何其他提交。 那絕對不是您的圖形試圖傳達的模型。

Answer 2

將您的development分支合並到master ，您可能進行了快進合並。
與git merge --no-ff ，它（ 手冊頁 ）“即使合並解析為快進，也會創建合並提交”。

這意味着master HEAD只需引用所有dev提交即可移至dev HEAD。

請參閱“ 為什么git默認使用快速轉發合並？ ”。

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 

• 如果看到其他分支的提交，則可能是該分支已合並到當前分支中，或者您可能錯誤地在此分支中進行了提交。