新开发人员无法跟上分支合并的步伐

#1 楼

如果您在分支中所做的更改接近您的同事在同时在develop分支中所做的更改，也就是说，如果您和您的同事更改了同一行代码或同一文件中的相邻行，则您将发生合并冲突。 br />
因此，为减少合并冲突的可能性，您可以尝试更早进行合并，以便您的同事同时更改较少的行，或者您可以尝试自行更改较少的行。

要自己更改较少的行，请确保仅进行与您的任务相关的更改。

如果您需要尝试不同的方法来实现目标，则可能有些实验更改了行而没有真的需要更改吗？合并之前请撤消这些更改。

还有一些Git命令可以帮助您更改尽可能少的行：



git diff和git diff --staged看看您更改了哪些行。

git add -p仅将某些更改添加到文件中。

git commit --amend和git rebase -i进行调整以提交已在本地要素分支中完成的操作将它们推送到其他Git存储库。

（更改尽可能少的行还可以使您更轻松地查看工作或使用处理提交之间差异的工具，例如git cherry-pick，git rebase，git bisect，和git blame。）

但是，即使减少合并冲突的可能性，有时仍然会遇到合并冲突。因此，不要害怕它们，而要学习解决冲突的方法。

#2 楼

我假设您正在使用git。如果是这样，请使用git rebase -i（-i表示交互式）。使其日常事务（根据需要甚至更频繁）成为使您的分支基于develop分支的基础。这每天（至少）递增地引入更改，以使功能分支保持最新状态。如果在日常改组过程中发生冲突，则需要与团队讨论谁在做什么。

如果每天运行它，则可能不需要交互部分。只要让它做就行。

我是一位经验丰富的开发人员，但要花上很多时间才能加快新项目的开发速度。在您的情况下，听起来好像有几个人同时在同一个项目上工作，所以它要么是一个很大的项目，要么是一个快速发展的新项目。无论哪种情况，都不要担心是否需要花费几个月的时间才能进入流程。如果我将项目切换2到3周，然后又切换回去，则可能要花几个小时（甚至一两天）才能完全“回到”我自己写100％的项目！ >
简而言之，不要担心现在变慢。变得更好的方法就是继续练习。不要害怕向其他开发人员询问您不了解的项目方面。

编辑：

或使用merge。这也是一种选择。因此，以上内容将是：“使用git rebase -i（-i表示交互式）或git merge”。至于要使用哪个，请与团队中的其他成员讨论。他们可能会（也可能不会）有强烈的偏好。显然有些人确实有强烈的偏好。

#3 楼

这可能表明该公司的软件工程不佳。相互依赖性过多，功能重叠的不同问题，尝试以错误的顺序解决问题等都可能导致您描述的情况。我建议在开发过程中定期将develop合并到您的分支中

#4 楼

我认为已接受的答案更多是技术上的“如何更好地使用Git”性质，我认为这更多是团队问题，而不是工程或工具问题。

如果遇到很多问题合并冲突意味着您和团队中的其他任何人都在互相踩脚趾。
您或他们应该在编码时开发个人空间，并避免在已经很忙的区域工作。

在我的团队中，我们倾向于高度的任务所有权。
我通常一次要完全拥有两个或三个文件的所有权，然后在分支中处理一天或一天​​。通常最多只有两个。
如果其他任何人触摸这些文件，则只有在绝对有必要执行其任务时，我们通常根本不会一起处理同一任务！

如果您发现自己必须进行大量合并，然后所有团队代码都放在一个地方（这本身就可以避免）或所有任务都在这里。

所有这些说，作为一个新开发人员，您可能无力执行，请求或什至没有真正建议任何形式的重组。
我希望您的任务已被分配为“学习绳索” ”这些东西应该在您的技能水平上较为合理，以使您轻松进入团队。他们可能是从仍在同一地区工作的同事的任务中剔除而来的，因此您的合并冲突。
然后的解决方案是把它塞住，解决问题，处理合并冲突将尽力而为，不要太担心，只要您尽力而为，那就要让经理来担心您的进度。
随着时间的流逝，您会变得更快，更自信，您的同事将为您提供更多的自主权，并减少您的举动。

#5 楼

合并最重要的是，等待时间越长，痛苦就越大。而且问题的增长远非线性问题。三倍的冲突是九倍的工作。有一些策略：

每当开发分支发生更改时就将其合并，因此您始终可以与之接近，并且永远不会发生大量冲突。

如果花费很长时间，则可能是因为您花费了大部分时间来确定更改是什么，然后花了少量时间来执行更改。如果是这种情况，请在开始实际代码更改之前与development分支合并。

与您的同事讨论避免冲突的策略。如果两个人编辑相同的代码，则会产生冲突。不仅是相同的文件，而且是相同的代码。因此，我需要一个新的函数functionA，而您需要一个新的函数functionB，并且我们都将其添加到同一文件的末尾，因此发生冲突。如果将其添加到其他位置，则不会发生冲突。如果我们都将其添加到文件中逻辑上所属的位置，则可能没有冲突。

如果有冲突，请使用一个不错的diff工具，以便您可以在合并之前比较developer分支，在合并之前比较您的代码，原始代码和合并的代码，然后手动合并。

最坏的情况：您不会丢掉您的工作，而是使用一个好的diff工具来找出您所做的确切更改，再次从开发分支，然后应用您手动进行的所有更改，而不是应用重新打字。

#6 楼

等到我准备将分支合并回develop（重点是我的）时，git merge中的处理冲突通常比git rebase中的处理简单。在Git merge中，您可以看到一次被修改的文件的完整列表。无论其他同事完成了多少次提交，您都必须合并一次。使用变基工作流，您可能最终会一遍又一遍地遇到相同的冲突，因此必须手动进行检查。您最终可以解决第13次提交，感觉好像看不见隧道。

根据我的经验，当我试图天真地解决重复的基础冲突时，我最终失去了某人的修改或甚至没有编译的应用程序。我和同事经常做很多工作，但由于重复冲突的复杂性而变得不知所措，以至于在进行了几次重新提交后，我们不得不中止并丢失了以前的工作。

我将建议您一些技巧，但它们只能使合并比自动化任务更容易。



资源/语言文件。如果您对资源文件进行了附加更改，请确保始终将它们移到文件末尾，以便您可以轻松地将更改与其他更改一起撤回。您可能可以将更改复制并粘贴到底部，也可以仅删除冲突标记

执行。不。绝对。重新格式化。您和您的其他开发人员都不应在日常工作中执行“大量代码重新格式化”。代码重新格式化在冲突管理中增加了过多的误报。可以重新设置代码格式


例如，递增由每位开发人员在每次提交时使用自动工具（例如，Eclipse可以选择重新格式化保存选项，而普通的Visual Studio都没有）。绝对每个开发人员都必须使用相同的代码格式标准，并将其编码为IDE占用的格式文件。为了让您有个想法，如果是4个空格或2个制表符没关系，但是如果每个人都使用相同的空格就很重要。
就在发布之前，由团队负责人进行。如果当人们不在分支上工作时（即在分支之前）发生“代码重新格式化”提交，事情将变得更容易




查看同事之间的工作拆分。这是大多数工程技术的一部分。正如其他答案所指出的那样，如果执行不同任务的多个开发人员必须接触相同的资源，这就是设计的味道。您可能需要与团队负责人讨论每个并发开发人员将修改哪些部分。

我在团队中的Git工作流中也看到了一些不良习惯。人们经常过度使用自己的分支机构。我亲眼目睹了一个开发人员添加10到20个标记为“修复”的提交，每个提交都包含一到两行。我们的政策是用JIRA票证标记提交，以便给您一个构想。

@JacobRobbins建议将git rebase设为日常任务。我想推动他的方法前进。

首先，使用一次rebase只是为了减少少数提交的次数。并且仅基于原始的develop分支（这是您从中分支的提交）重新建立基础。当我说几句时，我的意思是3或4（例如，所有前端，所有后端，所有数据库补丁）或任何合理的数字。合并它们之后，请使用fetch并在上游分支上进行基础调整。除非您的团队评估自己的方法，否则这将不会使您摆脱冲突，但是这会使您的生活减轻痛苦。

如果您对特定任务还有其他疑问，请随时在Stackoverflow上进行搜索和提问。

[编辑]关于不重新格式化和童子军规则。我对RE格式做了些许措辞，以强调我的意思是从头开始对整个源文件进行格式化的任务，包括您未触及的代码。与总是格式化自己的代码（完全是男孩子般的做法）相反，包括我在内的许多开发人员都习惯于使用IDE的功能来重新格式化整个文件。当文件被其他人触摸时，即使受影响的行的内容和语义没有更改，Git也会将其视为冲突。只有功能非常强大的语言感知编辑器才可能提示冲突仅与格式化有关，并且会自动合并最佳格式的片段。但是我没有任何此类工具的证据。

毕竟，童子军规则并没有要求您清理别人的烂摊子。只是你的。

#7 楼

首先，不要考虑放弃所做的更改。您将失去学习合并过程的机会。

其次，找到一个处理这些文件而导致冲突的人。您可以查看历史记录。与该人交谈并解决这些文件中的冲突。对于其他冲突也要这样做。

如果冲突太多，您的任务可能很小，但重复。尝试找到一个模式。这将有助于通过Git UI客户端工具解决冲突。我使用TortoiseGit。它有助于合并。

为了避免将来出现，


定期将开发分支合并到功能分支是一种很好的做法。
如果启用了CI，请查看CI工具是否提供分支构建。这应该以您在功能分支中进行的每项检查为基础，但要在合并开发分支之后进行。

#8 楼

这里有一些潜在的问题。合并问题很可能不是您的错，更常见的是不良做法的征兆。

1）理想情况下，您每天都会将分支合并到开发中。尝试每天至少有一次通过所有测试的工作代码，以便您可以合并到development。

2）如果您在日常工作中的任何时候都没有工作代码，则可能是太多的代码无法使用。您需要将任务分解为可以更快地完成（理想情况下彼此独立）的较小任务，以便可以合并。

3）您的项目文件可能太大。如果一个文件存在许多合并冲突，则有太多人在处理一个文件。理想情况下，一个人正在从事的工作应该与其他人正在从事的工作分开。

4）您的团队可能太大了。如果您发现放弃整个功能并重新开始比较容易，则可能是有太多人将代码提交到同一存储库。

5）您可能没有一致的代码格式标准。如果不是所有人都一致地使用相同的代码格式，则对于相同的代码，您会遇到许多不同的冲突。取决于您git的设置方式，这些甚至可能归结为空格冲突（行尾，缩进，制表符与空格）。

6）人们可能会将其更改直接推送到developer分支。 br />
这是您可以做的事情：
1）如果您不能每天都合并到开发中，请每天（或更频繁地）将开发合并/重新设置到您的分支中。
2）尝试将您的代码与其他人的代码分开。
3）与团队其他成员讨论较小的功能，一致的编码标准和更好的代码组织（较小的文件，较小的功能）。

#9 楼

您应该从开发分支定期（每天）运行命令“ git fetch”（而不是git pull）。这将使其他人进行更改，并将其带入功能部件分支，而无需尝试将更改集成到您的分支中。

这是您应该与首席开发人员（不一定是您的经理）讨论的内容，因为您的公司可能有自己的标准或建议的处理此问题的方法；这很常见。不要等到下周-立即查找流程，并询问是否可以进行一些琐碎的工作（例如代码格式化或添加注释），以便可以测试流程。

#10 楼

显然，第一件事是首先避免让多个人同时处理同一个文件，至少要避免造成麻烦的冲突。只要使用良好的代码格式，就可以将内容添加到枚举中。以不同的方式更改控制流并移动代码非常棘手。有时候这是不可避免的。解决真正复杂的冲突时，您将需要提出问题。

那，我看到许多答案建议建议定期合并/调整为基础。对于那种建议我不会那么热心。您目前的目标是使解决冲突的过程尽可能简单和安全。可以极大地帮助该过程的一件事是立即拥有尽可能多的回归测试，包括作为新功能一部分的新测试。如果您非常定期地将分支与development同步，那么在实际完成功能的一半完成后，您将不可避免地不得不解决冲突。这就意味着，要弄清楚代码应该做什么，将变得更加困难，因为您还没有完成代码。在尝试合并之前，请确保您的分支是变更的一致单元。更好的是，在合并之前将其重新设置为单个提交。

我尝试不考虑通过合并进行rebase的优点，这可能是另一个问题。在这种情况下，工具并不重要。

#11 楼

到我准备合并分支以开发其他分支时，
已经进行了很多更改，以至于解决冲突变得势不可挡


这听起来像结对编程的理想方案！

有关好处和基本方法的更多信息：https：//gds.blog.gov.uk/2018/02/06/how-to-pair-program-分6步有效/

随着时间的推移，您自然会加快自己的工作速度，但是直到那个时候可能会令人生畏，而且有时也很漫长。此外，尽管人们可以在压力很大的环境中快速学习，而压力却总是要追赶，但在恒定压力下学习不好的其他人也会受到阻碍。

而不是自己独自从事分支工作，试图跟上明显比您快得多的其他开发人员，您应该直接与另一位开发人员（同一台PC）合作。这样，您将获得即时建议，并可能会获得如何加快速度的提示。

您将找出项目中特定代码的最佳方法，因为结对编程并不总是对于某些项目来说很有意义-尽管即使您只是坐下来观看比您更有经验的人，也可以说对于学习来说总是有意义的（只要他们是一个优秀的开发人员，经验并不一定意味着他们使用了良好的实践）。 br />
与一个更快，经验更丰富的开发人员坐在一起可以通过以下方式提供帮助：


将可能减少合并冲突，因为与经验丰富的人一起工作会增加完成时间，因为反对您独自工作
因为他们会教给您，他们可能会比单独工作要慢一些，因此可能仍然存在一些合并冲突，因此可以与经验丰富的人一起解决这些问题，所以也许选择节省时间的一些技巧等
帮助您了解潜在的技巧和方法，以提高速度（尽管有时慢只是由于缺乏经验而不是缺乏良好的实践）
在没有意义或不确定性100％的情况下可以立即提出问题
1：1的工作对学习很有价值，因为您会向其寻求帮助的人已经了解了他们工作时的确切代码和场景在此基础上，无需结对编程，您必须解释代码和方案，而这通常会带来问题，因此您会浪费他们的时间/精力，无法真正获得急需的建议
结识经验丰富且经验丰富的人的思维过程。经验丰富，并且拥有良好的沟通，您肯定会学到新东西。



除了“擅长编码”之外，还有没有其他我可以使用的策略？我打算下周和我的主管讨论这个问题。


我的建议是与其他开发人员讨论结对编程，然后与您的主管联系。如果他们很体面，他们将感谢您的主动性，这为您提供了更多机会来推荐结对编程的专家（如果他们需要，大多数人都知道它，并且它是常识，为什么会有帮助）。

#12 楼

实际上，取消我的工作并重新开始任务似乎更容易，
当然这不是可持续的解决方案）


大多数时候，这这是我的工作，第一次修复错误或对系统进行更改时，我正在学习如何做。下次我修复相同的错误时，按照我现在所了解的问题，仅需要1％的时间。

我还发现，当我重做一些工作时，我会编写更好的代码... ..

因此，从主节点创建一个新分支，在其中重做您的工作，同时使用“私有分支”来提醒您需要做什么，这没有错。

您还可能发现了一种将更改分为逻辑部分和正确部分的方法，完成后将每个部分合并到master分支中。例如，可以完成单元测试和对后端代码的更改，然后将其合并。然后，在单独的操作中，您可以使用它们进行UI更改，因此，别人编辑同一UI文件的风险较小。

#13 楼

如果您不想过于频繁地将development分支合并到您的分支中，则可以使用git pull --rebase获得更像svn的工作流程。这将拉出新的提交并将您的提交基于它们。这意味着，当您将分支合并到开发中时，它将是一种快速合并（就像您一次又一次地添加所有过去的提交一样）并且没有任何合并冲突，因为您在执行过程中解决了所有冲突git pull --rebase。

但是，在将分支合并到开发或开发到分支中之前，您进行的提交越多，下一个重新构建的基础将变得越复杂，并且这将颠覆功能分支的意义，因为您的分支仅在未合并的情况下存在。

#14 楼

当您使用公用文件时，无论哪种方式，您或您的队友都需要在合并完成之前解决所有冲突，因此，请不要打扰。您仍在从事项目工作，并为您的工作感到自豪。现在，要采取更明智的行动，您可以按照以下建议进行操作。



独立划分任务：

开始工作之前，请计划和以使每个团队成员分配的任务尽可能独立和模块化的方式划分整个任务（以避免在开发过程中发生潜在冲突）。您可以当初学者时与Scrum负责人联系，为他们分配一些独立的任务。

合并精细的频繁提交：

不要等待完整的任务完成最后的征途。当然，任何较大的任务都可以分为多个子任务。因此，更好的方法是经常合并较小的子任务的较小提交，以避免频繁的冲突解决。

经常对分支进行重新设置：

进行频繁的重新设置的做法您本地的远程分支机构。您可以使用以下命令频繁地使用远程分支重新建立本地分支，

git pull --rebase #or
git pull --rebase origin dev #when dev is remote branch

这是迄今为止对我的开发生命中最有用的git命令。 />

与队友紧密合作：

如果您确实需要在共同的任务中与队友并行工作，请进行协作。为了您的方便，她是专家，她可以等一段时间以避免复杂的冲突解决。


习惯git选项：

使用强大的git合并工具。有许多方便的方法可以解决合并时的冲突。合并策略有时可能会很有帮助。习惯于使用git命令并且毫不畏惧。