Git提交歷史與文件歷史不同步？

Question

我一直無法正確地說出這個問題，所以雖然我已經搜索了很多，我不認爲我真的知道我在問什麼。

我們的團隊是Git的新手，我們遇到了我們不理解的行爲。我們正在開始一個全新的項目，現在我們只有一個Master分支。

場景A：

我開始存儲庫，並已做出到它的多個變化。我的一位同事加入了該項目並克隆了存儲庫。他開始在另一個領域工作，並沒有與這些更改同步好幾天。

當他推動他的改變的時候，他做出了改變並開始了一次拉動。正如預期的那樣，這一切都取消了我所有的更改。他也將這些改變提交給他的本地存儲庫，然後推動這些更改（有意義）。

我們在GitHub上看到的提交包含了他在過去幾天中所做的更改和所有更改（？），使他很難挑選出他所做的更改。但是，如果我們檢查文件歷史記錄，它們根本不包含這個歷史記錄。他們仍然反映了我上次推送更改的時間。

情形B：

很大程度上與上述相同，但另一（新）同事偶然忽略他的提交和拉步驟後傳入更改。幸運的是，這並不像聽起來那樣災難。提交歷史顯示這發生，但文件歷史沒有。我的文件基本上是「回滾」，沒有任何跡象表明文件的歷史，這似乎非常可怕。

我一直在做一些閱讀，關於如何在某個時刻應該使用開發分支，並讓每個人都分支併合並回dev，然後可能在完成所有工作時合併到master中。但我想我們並沒有從根本上理解在上述情況下發生了什麼。

編輯：我想我可能在概念上想象'pull --rebase'應該做什麼。

編輯2：也許不是。這是我的意思。我的同事和我只是通過創建具有不同內容的'testfile'來試驗這個，然後他創建了一個額外的'testfile2'。在接受他的更改時，有一個新文件和一個合併衝突（如預期的那樣）。我解決了一個衝突，然後將他的新文件和合並的文件都提交給了我的本地存儲庫。然後我推回遙控器。爲什麼它表明我在我的提交中添加了'testfile2'，當我沒有，它已經存在？

Screenshot of commit here

Answer 1

你只需要放下一些基本規則使用督促分支機構。就像你說的，理想情況下，你應該有另一個分支來進行日常開發（主）。每個開發人員也應該分出主人的特色工作，然後合併並推送他們的更改。

至於在上述情況發生的事：

• 方案1：

您的同事不應當提交了他的更改，然後拉，他應該做它周圍的其他方法。這是功能分支派上用場的地方。這樣做的一個好方法是：從主

1. 拉的最新變化
2. 分行開了一個新的特性分支並在那裏做所有的工作
3. 退房主
4. 拉的最新變化
5. 當在主，合併的特徵分支
6. 推合併提交（多個）遠程

每個團隊都有自己的管理git生命週期的方式，但建立每個人都遵循的規則是一個不錯的主意。

• 方案2：

我假設的 「忽略傳入更改」 你的意思是，他強行推。這是非常危險的，如果可能的話應該被遠程服務器禁用。這可以（也將會）有效地重寫您的歷史記錄，消除同事在其遠程回購中沒有的任何更改。如果您不能禁用強制推送或更改服務器的權限，則另一種解決方法是編寫一個腳本，爲您執行提取/拉取/合併/推送循環，並讓所有人都使用它。