git-我应该多久获取一次最新更改

Question

作为git新手，我了解基本知识，但我感到不安的一件事是，如果我的更改需要几天才能完成。

我将从创建一个新分支p4 submit开始并进行处理，但是我听说我应该每天至少从远程获取一次最新的代码更改，以减少冲突的可能性。

1. 当我实际上仍在本地分支上进行编码时，应该多久将一次更改从远程转移到我的branch-A上？
2. 如果我在自己的本地branch-A上进行了几天的编码，是否应该每天提取/合并到branch-A或本地brach-A？

更新

我想我不清楚我需要澄清什么。

假设我使用功能分支

假设团队规模适中，并且不管我们是否都在“相同”区域工作，请帮助我了解什么是最佳安全实践。

话虽如此，我这样做是因为这是我所知道的（不确定我是新手，但会读懂，确定会是什么）：

获取最新更改并合并到开发中

master

从刚更新的开发分支中创建新分支

git fetch origin
git merge origin/develop

今天工作并进行登台和提交

git checkout -b branch-A

第二天，我想确保从远程获得所有更改，以减少冲突的机会。因此，我想再次获取/合并，但请注意，我目前在我的分支A中

我该怎么做？我会这样吗

git add.
git commit -m "my message"

或类似的

git fetch origin
git merge origin/branch-A

Answer 1

这个问题完全取决于有多少人同时从事同一段代码。如果您正在使用一项新功能（即新文件），则只需花一个月的时间就可以合并，而不会合并到一起-无论如何您都不会发生冲突。如果您有三个编码人员都试图修复同一文件中的两个不同的错误，则每30分钟合并一次。

不要对此感到焦虑或“不安”。我不认为三个连续的合并冲突比一个三倍大的合并冲突更容易。在许多情况下，连续的合并冲突最终只会一遍又一遍地更改相同的内容，如果每天在同一对夫妇的循环中发生大量琐碎的冲突，您每天将浪费更多的时间进行合并。

我绝对建议您每天都拉大师。它使您可以很好地看到已进行的所有更改，并且如果您看到正在处理的文件上出现+/-的风暴，那么最好合并下来，因为这可能是重构。如果您的文件有少量更改，请不要理会。

Answer 2

关于1 -这是您的决策+最适合您的团队的做法，要考虑到同时进行项目变更的人员数量以及应该在其中进行多少工作的人员与您相同的区域。

根据经验，与主开发分支的同步越少，必须解决的冲突就越多。

我可以说我几乎每天都要从主开发分支进行一次基础调整，有时更频繁，但这又取决于我上面已经解释过的事情。

从技术上讲，如果分支是由“ master”（这是主要的开发分支）创建的，则如下所示：

git checkout -b my_branch

然后您进行提交：

git commit -am "some commit"
git commit -am "another commit"

那么，执行以下操作一文不值：

git fetch --all
git rebase origin/master

在这种情况下，您的提交将是历史上的“最后一次”（尽管它们的sha1将更改，这不是问题，因为它只是您的分支），并且您的分支还将包含master的最新更改。

关于2

如果您一个人/在一个非常小的团队中工作-也许您总是可以直接提交给master而不使用任何分支，尽管这不是建议的git使用方法。

我可以为自己说，我为单个功能使用功能分支，通常，它可以“存活” 1-3天。然后，我通过 pull-request 机制将其合并回主服务器-我打开了一个pull请求，我的团队成员审核并批准了我的更改，然后又合并了。

这种工作方式有很多优点，但是它超出了git提供的基本“裸”命令，更多地是关于使用git（一种极为灵活的工具）在项目中工作的良好实践。 因此，我建议您阅读有关拉取请求的信息，并查看是否可以在团队中采用它们

Answer 3

答案

假设您目前在branch-A上：

易于理解

git commit -am "Make sure you save your pending changes" git checkout develop git pull # Or fetch merge like usual into develop git checkout branch-A # git merge origin/branch-A here if other people might also be working on branch-A. # It'll let you know that it's "Out of date" if other people changed branch-A git merge develop

这是更新分支的最清晰的方法。

易于键入

这仅在您未更改本地开发且抓取合并是简单的快速转发的情况下才有效。它会告诉您是否无法快进。

git commit -am "Make sure you save your pending changes" git fetch origin develop:develop # Updates your local develop # git fetch origin branch-A:branch-A # If others will be working on your branch. git merge develop

请注意，如果您忘记了这里的git fetch origin branch-A:branch-A，它不会让您知道您已经过时了，因为git fetch origin develop只会获取开发内容。

给出建议

建议1

git fetch origin git merge origin/branch-A

这实际上什么也没做。起源/分支A可能与您的本地分支A相同。如果其他人也在A分支上工作，那么您可以接受他们的更新，这很酷。但是你从来没有碰过开发。

建议2

git fetch origin # Make sure to git merge origin/branch-A here if other people are touching branch-A git merge origin/develop

这将通过使用origin / develop来更新分支机构A。在您缺席的情况下，原点/显影可能已更改，因此这将更新您的分支。

但是！这令人困惑，因为您的本地开发仍然过时了！您可以顺其自然，然后在下次结帐开发时，它会告诉您“过时”，此时您也可以将Origin / develop混入合并到开发中。

但是，您可能会签出另一个分支，然后git merge develop，以为“是的，我刚刚更新了”。但是您没有，本地开发不同步。这就是为什么这是一种不好的做法。