3

我目前正在与一个会议的博士后合作写一篇论文。我们使用版本控制软件进行了调查，git 似乎是一个很好的选择。现在我们必须真正体验它并且面临一些问题。具体来说，我们有时会在推送之前编辑相同的文件，从而导致第二个想要推送的人出错。

为了防止这种同时编辑，可以使用哪些技巧/工具/等？我知道 git 用于大型项目，有许多没有面临这些问题的合作者，那么我们做错了什么？

有任何想法吗？

4

3 回答 3

1

实际上，当你在写论文而不是代码时，git 可能不是完美的工具。通过使用谷歌文档或类似的东西，您将能够几乎实时地看到您的合作伙伴所做的更改。而且您不必经历提交/推送/合并的事情。

于 2013-11-20T16:10:57.603 回答
1

Git 没有像 TFS 那样“锁定”文件的任何机制。如果两个人都在积极编辑文件的同一部分，您应该预料到会有冲突。

主要事项：

和你的同事谈谈你在做什么。如果可以，请协调，如果必须，请警告他们。这似乎是一种行人，但它通常比它应该发生的晚。 Scrum很好，因为它使它成为你日常工作的一部分。

最大的因素是您对自己的更改保留多长时间。未完成更改的时间越长，重叠更改集的机会就越大。

在您正在共同开发的功能上创建集成分支是一件好事。如果您经常创建检查点、推送和变基，那么您就不太可能做出难以纠正的重大更改。不过，小冲突很容易处理。在推送到 master 之前，您可能需要返回并清理一些提交，但这通常很容易协调。

小事：

查看差异是了解一段代码如何变化的绝佳工具。人们在不同的格式偏好之间切换会破坏这个工具。

具有一致的格式有助于解决这些无关紧要的冲突。选择一致格式的过程是另一回事。;)

如果您正在处理一个函数并注意到空格不正确，您将修复它。从事相同功能的其他人也会这样做。

例如，左缩进：

namespace foo {
namespace bar {

    class Foo {
    public:
        void something();
    };

    class Foo {
        public:
            void something();
    };

}}

namespace foo {
    namespace bar {
    }
}

我个人更喜欢将所有命名空间像第一组一样左对齐。这将空白噪声保持在最低限度。不过，一致性很重要。

制表符与空格是另一个。从理论上讲，您选择哪一种并不重要，但一定要选择一种。

避免移动代码（显然没有充分的理由）。这很难做到，但如果你有更多的文件，每个文件中的东西更少，这不是一个问题。

将小的“内务处理”更改与您的功能/错误修复提交分开。这使得合并这些提交上的更改变得非常简单。如果一个是特征变化，一个是空格变化，那么你可以盲目地接受特征变化。

于 2012-10-11T22:05:42.287 回答
0

“锁定”在某种意义上是自动的。您有自己的副本，他们无法将其从您手中夺走！就像他们有他们的副本一样，您无法将其从他们手中夺走。这假设您正在使用 git DVCS 的分布式特性（而不是同时访问文件共享 :-( 您将各自拥有自己的克隆并交换分支或推送到公共裸仓库。

下一步是确保您使用的文档处理器适合 git 合并，理想情况下是纯文本源，例如 Latex 或 markdown。Git 会很高兴地合并您的单独贡献并突出显示您的冲突。但是不要使用很长的行。

如果您正在合作，您将能够讨论发生合并冲突的常见区域并同意最佳措辞。

享受同时工作的自由。

于 2012-10-11T23:08:00.627 回答