【问题标题】:Conflict resolution or conflict avoidance in GIT?GIT 中的冲突解决或冲突避免?
【发布时间】:2013-07-23 18:39:09
【问题描述】:

问题:如何让几个人使用 GIT? update-commit 是像 SVN 一样常见还是默认合并?合并时,谁应该作为合并提交的作者出现?

很多背景信息:我正在和另一个人写一篇关于 LaTeX 的论文,我们正在使用 GIT 进行版本控制。

从一开始我们就决定我们都在 master 分支上工作,因为无论如何我们只有两个人。

我已经完成了许多提交。然后他对旧版本进行了提交,并合并了我的上一个版本和最新的版本(在他提交之后)。用图片更容易看出:

对我来说,以这种方式进行合并很奇怪,如果我没记错的话他应该先拉然后提交,合并应该在两个不同的分支之间完成。

最奇怪的是,我的提交在任何时候都没有被删除,但内容在最新的提交中显示为新的,并且他显示为作者。这看起来像一个错误,但说实话我真的不明白这里发生了什么。

所以问题是:

这是一个错误吗?

我们应该使用分支单独工作吗?如果他不将它们推送到服务器,我可能会忽略他的提交。

他是否正确使用了系统,或者他是否应该像在 SVN 中那样在提交之前进行拉取(更新 -> 提交)?

最后,我做了一个分支、一个提交和一个合并(还没有出现在图片中),可能同样的事情会再次发生,因为现在 master 更新了,他可能会忽略这些更新,提交,然后以作者身份合并。

这对我来说看起来不对,但我不知道它是否正确。

恕我直言:合并应该在本地完成,然后将更新推送到共享存储库,如更新提交方式。

【问题讨论】:

    标签: git git-merge git-rebase


    【解决方案1】:

    我们应该使用分支单独工作吗?

    是的:他应该在推送他的更改之前完成git pull --rebase(对于尚未推送的分支),此时您可以将他的分支合并为简单的快进合并。
    另请参阅 merge vs. rebasesimilar blog post

    (来自Git Is Your Friend not a Foe Vol. 4: Rebasing

    更一般地说,是的,在推送之前在本地合并。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2015-10-15
      • 1970-01-01
      • 2018-05-15
      • 2020-11-25
      • 1970-01-01
      • 1970-01-01
      • 2018-08-04
      • 2017-08-13
      相关资源
      最近更新 更多