Git提交历史记录与文件历史记录不同步？

Question

我一直无法正确地说出这个问题，所以当我搜索了一下时，我并不认为我真的知道我在问什么。

我们的团队是Git的新手，我们遇到了一些我们不理解的行为。我们正在开始一个全新的项目，现在我们只有一个主分支。

情景A：

我启动了存储库，并对其进行了多次更改。我的一位同事加入了该项目并克隆了存储库。他开始在另一个地区工作，并且几天没有与这些变化同步。

当他推动他的改变时，他做出了改变并开始了拉动。正如预期的那样，这降低了我的所有变化。他也将这些更改提交到他的本地存储库，然后推动更改（有意义）。

我们在GitHub上为他看到的提交包含了他在过去几天中所做的更改和所有更改（？），因此很难找出他所改变的内容。但是，如果我们检查文件历史记录，它们根本不包含此历史记录。它们仍反映了我最后一次推动变革。

情景B：

与上面大致相同，但另一位（新）同事在提交和拉出步骤后意外忽略了传入的更改。幸运的是，这并不像听起来那样灾难性。提交历史记录显示发生了这种情况，但文件历史记录没有。我的文件基本上被回滚了＃39;文件历史中没有任何指示，这看起来非常可怕。

我一直在做一些关于我们应该如何使用dev分支并让每个人从中分支并合并回dev的内容，然后在完成所有操作时可能合并为master。但我想我们并不能从根本上理解上述情况中发生的事情。

编辑：我想我可能在概念上想象什么＆＃39;拉动 - 基础＆＃39;应该做的。

编辑2：也许不是。这就是我的意思。我的同事和我刚刚通过创建＆＃39; testfile＆＃39;使用不同的内容，然后他创建了一个额外的＆＃39; testfile2＆＃39;。在接受他的更改时，有一个新文件和一个合并冲突（如预期的那样）。我解决了一个冲突，然后将他的新文件和合并的文件提交到我的本地存储库。然后我推回遥控器。为什么它表明我添加了＆＃39; testfile2＆＃39;在我的提交中，当我没有，它已经存在？

Screenshot of commit here

Answer 1

您只需要为使用prod分支制定一些基本规则。就像你说的那样，理想情况下你应该有另一个分支进行日常开发（主人）。每个开发人员也应该从master中分支出来进行功能，然后合并并推送他们的更改。

至于上述情景中发生的事情：

• 场景1：

你的同事不应该做出改变然后拉，他应该反过来做。这是功能分支派上用场的地方。这样做的一个好方法是：

1. 从掌握最新的更改
2. 分支到新功能分支并完成所有工作
3. 查看大师
4. 拉最新的更改
5. 在master上时，合并功能分支
6. 将合并提交推送到远程

每个团队都有自己管理git生命周期的方法，但建立像每个人都遵循的规则通常是个好主意。

• 场景2：

我假设“被忽略的传入变化”你的意思是他强迫推动。这是非常危险的，如果可能，应该由远程服务器禁用。这可以（并且将会）有效地重写您的历史记录，删除同事在其远程仓库中没有的任何更改。如果您无法在服务器上禁用强制推送或更改权限，另一种解决方法是编写一个脚本，为您执行获取/拉取/合并/推送循环，并让每个人都使用它。