我目前与一位博士后合作为一场会议撰写论文。我们调查了使用版本控制软件,Git似乎是一个不错的选择。现在我们已经开始实践,但是遇到了一些问题。具体来说,我们有时会在推送之前编辑相同的文件,这会导致想要第二次推送的人出现错误。
有什么建议/工具/等可以用来防止同时编辑?我知道Git被用于有许多合作者的大型项目,他们不会遇到这些问题,那么我们做错了什么?
有什么想法吗?
我目前与一位博士后合作为一场会议撰写论文。我们调查了使用版本控制软件,Git似乎是一个不错的选择。现在我们已经开始实践,但是遇到了一些问题。具体来说,我们有时会在推送之前编辑相同的文件,这会导致想要第二次推送的人出现错误。
有什么建议/工具/等可以用来防止同时编辑?我知道Git被用于有许多合作者的大型项目,他们不会遇到这些问题,那么我们做错了什么?
有什么想法吗?
Git没有像TFS那样的“锁定”文件的机制。如果两个人都在积极编辑同一部分文件,则应该预期会发生冲突。
主要事项:
与同事讨论您正在做什么。如果可以协调,如果必须警告他们。这似乎有点平凡,但通常比应该晚一些发生。Scrum很好,因为它使其成为您例行公事的一部分。
最大的因素是您将更改保留给自己的时间有多长。您拥有未解决更改的时间越长,就越有机会出现重叠的更改集。
在一起工作的功能上创建集成分支是一件好事。如果您经常创建检查点、推送和变基,那么您就不太可能进行难以纠正的大型更改。小冲突相当简单处理。您可能需要回去清理一些提交,然后再推送到主分支,但通常很容易协调。
次要事项:
查看差异是了解代码如何更改的不可思议的工具。人们在不同的格式设置偏好之间转换会破坏此工具。
保持一致的格式有助于解决这些不重要的冲突。选择一致的格式的过程又是另外一回事。
如果您在处理某个函数时发现空格不正确,您会进行修复。同样处理该函数的其他人也会这么做。
例如,左缩进:
namespace foo {
namespace bar {
class Foo {
public:
void something();
};
class Foo {
public:
void something();
};
}}
namespace foo {
namespace bar {
}
}
我个人更喜欢将所有命名空间左对齐,就像第一组一样。这样可以将空格噪音降到最低。但是一致性才是最重要的。
制表符与空格也是一个问题。理论上,选择哪一个都无所谓,但确实需要选择一个。
避免移动代码(除非有充分的理由)。这很难做到,但如果您有更多文件,每个文件中的内容较少,则这不是一个问题。
将小的“清理”更改与您的功能/错误修复提交分开。这使得合并这些提交的更改变得非常简单。如果其中一个是功能更改,另一个是空格更改,则可以盲目地采用功能更改。
实际上,如果你在写论文而不是代码,Git可能不是最完美的工具。使用Google文档或类似工具,你将能够几乎实时地看到你的合作者所做的更改。而且你不必经历提交/推送/合并的过程。
合并
期间,git提供了一种机制来将更改组合成一个统一的文档。有时它会失败,要求你手动执行合并操作。有时(很少)它会出错。我建议你阅读有关基本git操作的git手册。 - Xyand