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

我是新开发人员-这是我的第一个编程职位。

我的问题是：我们使用git-我从develop分支中剪切了一个分支，然后开始处理已分配的次要任务。这很慢，因为我没有经验。到我准备将我的分支重新合并到develop其他分支时，已经进行了许多更改，以至于解决冲突变得不知所措（实际上似乎更容易取消工作并重新开始工作，这当然不是可持续的解决方案）。

我该如何克服呢？除了“擅长编码”之外，我还有其他策略可以使用吗？我打算下周与我的主管讨论。

如果您在分支中所做的更改接近同事在develop分支中所做的更改，即您和同事更改了同一行代码或同一文件中的相邻行，则您将发生合并冲突。

因此，为减少合并冲突的可能性，您可以尝试更早地进行合并，以便您的同事同时更改更少的行，或者您可以尝试自己更改更少的行。

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

如果您需要尝试不同的方法来实现自己的目标，那么也许您的某些实验改变了您确实不需要更改的行？合并之前撤消这些更改。

还有一些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）。

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

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

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

我是一位经验丰富的开发人员，但要花上一些时间才能加快新项目的开发速度。在您的情况下，听起来好像有几个人同时在同一个项目上工作，所以它要么是一个很大的项目，要么是一个快速发展的新项目。无论哪种情况，都不要担心是否需要花费几个月的时间才能进入流程。如果我将项目切换2到3周，然后又切换回去，则可能要花几个小时（甚至一两天）才能完全“回到”我自己写了100％的项目！

简而言之，不要担心现在变慢。变得更好的方法就是继续练习。不要害怕向其他开发人员询问您不了解的项目方面。

编辑：

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

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

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

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

在我的团队中，我们倾向于高度的任务所有权。
通常，我通常一次完全拥有两个或三个文件的所有权，并在分支机构中最多处理一两天。
通常，如果其他任何人触摸了这些文件，则只有在绝对必要时才可以完成他们自己的任务，我们通常根本不会一起处理同一任务块！

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

综上所述，作为一名新开发人员，您可能无力执行，请求甚至根本不建议进行任何形式的重组。
我期望的是，您的任务已被分配为“学习型”的东西，在您的技能水平上应该可以合理接近，以使您轻松进入团队。他们可能是从仍在同一地区工作的同事的任务中剔除的，因此您的合并冲突。
解决此问题的方法是：尽一切努力，解决问题，尽最大可能处理合并冲突，而不必担心太多，只要您尽力而为，就取决于您的经理来担心你的进步。
您将在旅途中变得更快，更自信，

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

只要开发分支发生更改，它就会合并，因此您总是很接近它，并且不会有大量冲突。

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

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

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

最坏的情况：您不会放弃工作，而是使用一个出色的diff工具来准确地找出所做的更改，再次从开发分支出来，并应用所有手动更改，而不是重新键入。

到我准备将分支合并回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也会将其视为冲突。只有功能非常强大的语言感知编辑器才能建议冲突仅与格式化有关，并自动合并最佳格式的片段。但我没有任何此类工具的证据。

毕竟，童子军规则并没有要求您清理他人的混乱状况。只是你的。

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

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

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

为了避免将来

• 定期将开发分支合并到功能分支是一个很好的做法。

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

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

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

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

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

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

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

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

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

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

与其独自工作一个分支并试图与显然比您快得多的其他开发人员保持同步，不如直接与另一个开发人员（同一台PC）合作。这样，您可以获得即时建议，并且可能会获得有关如何加快速度的提示等。

您已经为项目中的特定代码找出了最佳方法，因为结对编程对于某些项目而言并不总是很有意义-尽管可以说，即使您只是坐着看一个比您更有经验的人，结对编程始终对学习有意义（只要他们是一个优秀的开发人员，经验并不一定意味着他们会使用良好的做法）。

与更快，经验更丰富的开发人员一起坐下可以通过以下方式提供帮助：

• 与有经验的人一起工作将增加完成时间，而不是您独自工作，这可能会减少合并冲突
• 当他们要教你时，它们的速度可能会比单独工作的速度慢，因此可能仍然存在一些合并冲突，因此可以与经验丰富的人一起解决它们，因此也许可以节省时间等一些技巧。
• 帮助您发现潜在的技巧和方法，以加快速度（尽管有时缓慢只是缺乏经验，而不是缺乏良好的习惯）
• 当没有意义或不确定性100％清晰时，可以立即提出问题
• 1：1的工作对学习非常有价值，因为您将向他们寻求帮助的人已经了解他们正在工作的确切代码和方案，而无需进行配对编程，则您必须解释代码和方案，这常常会导致问题并因此，您会失去他们的时间/注意力，而他们实际上并不需要太多的建议
• 了解经验更丰富，经验丰富的人的思维过程，通过良好的沟通，您一定会学到新东西

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

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

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

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

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

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

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

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

6）人们可能会将其更改直接推到开发部门。

您可以执行以下操作：1）如果您不能每天都合并到开发中，请每天（或更频繁地）将开发合并/重新设置到您的分支中。
2）尝试将您的代码与其他人的代码分开。
3）与团队的其他成员讨论较小的功能，一致的编码标准和更好的代码组织（较小的文件，较小的功能）。

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

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

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

因此，在使用“专用分支”提醒您需要做的事情时，从主节点创建一个新分支，重做其中的工作并没有错。

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

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

但是在将分支合并到开发或开发到分支中之前您提交的提交次数越多，下一个重新部署的基础就会变得越复杂，并且它会稍微破坏功能分支的意义，因为只要分支没有合并就存在。

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

1. 独立划分任务：

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

2. 合并精细的频繁提交：

   不要等待完整的任务完成再进行最后的攻击。当然，任何较大的任务都可以分为多个子任务。因此，更好的方法是同时合并较小的子任务的较小提交，以避免解决大量冲突。

3. 经常重新建立分支机构：

   经常将数据库重新部署到具有远程分支的本地分支。您可以使用以下命令频繁地将本地分支与远程分支建立基础，

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

   到目前为止，这对我来说是我开发生涯中最有用的 git命令。

4. 与队友紧密合作：

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

5. 习惯了git选项：

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