Questions tagged «branching»

我是新开发人员-这是我的第一个编程职位。 我的问题是：我们使用git-我从develop分支中剪切了一个分支，然后开始处理已分配的次要任务。这很慢，因为我没有经验。到我准备将我的分支重新合并到develop其他分支时，已经进行了许多更改，以至于解决冲突变得不知所措（实际上似乎更容易取消工作并重新开始工作，这当然不是可持续的解决方案）。 我该如何克服呢？除了“擅长编码”之外，我还有其他策略可以使用吗？我打算下周与我的主管讨论。

222 git  software  branching  merging 

为什么我执行的每个严肃的Github回购请求都要求我将提交压缩为单个提交？ 我以为git日志在那里，所以您可以检查所有历史记录，并确切查看发生了什么更改，但是挤压它会将其从历史记录中拉出来，然后将其全部合并为一个提交。有什么意义？ 这似乎也违反了“尽早提交并经常提交”的口头禅。

199 git  github  branching  pull-requests  etiquette 

我目前正在通过阅读Pro Git学习使用Git。现在，我正在学习分支和标签。我的问题是什么时候应该使用分支，什么时候应该使用标签？ 例如，假设我为项目的1.1版创建了一个分支。完成并发布此版本后，是否应该离开分支以标记发布版本？还是应该添加标签？如果添加标签，是否应该删除版本分支（假设它已合并到master或其他分支中）？

140 programming-practices  version-control  git  branching 

当前，我们在共享存储库中为我们的PHP应用程序提供了一个主分支。我们有500多个客户是我们的软件的订户，其中大多数人针对不同的目的进行了一些自定义，每个客户都在一个单独的分支中。定制可以是不同的文本字段名称，全新功能或模块或数据库中的新表/列。 我们面临的挑战是，当我们维护这数百个定制分支并分发给客户时，我们会不时提供新功能并更新我们的主分支，并且我们希望将主分支更改推送到自定义分支以便更新他们到最新版本。 不幸的是，这通常会导致自定义代码中发生许多冲突，并且我们花费大量时间遍历每个分支来解决所有冲突。这是非常低效的，我们发现解决这些冲突时并不少见的错误。 我正在寻找一种更有效的方法来使我们的客户端发行分支与master分支保持最新，这将减少合并过程中的工作量。

140 version-control  git  github  versioning  branching 

首先，我知道已经问过许多关于VCS作为单独开发人员的问题，但是它们通常过于广泛。这仅涉及分支，并且仍然被标记为重复...假定的重复再次被标记为另一个问题的另一个重复，该问题过于广泛且与分支无关。这就是我的问题的独特之处。 使用分支作为单独开发人员有什么优势（如果有）？即使在单独开发环境中，我也经常看到它的建议，但是据我所见，除了使用“主”主干进行开发，并分支工作以准备发布版本的代码外，我还看不到我可以利用分支的力量（例如，划分新功能），而不会使整个开发过程过于复杂。

117 version-control  branching  solo-development 

直到最近，我的开发工作流程如下： 从产品所有者那里获得功能 进行分支（如果功能超过1天） 在分支中实施 合并从主分支到我的分支的更改（以减少向后合并期间的冲突） 合并我的分支回到主分支 有时合并存在问题，但总的来说，我喜欢它。 但是最近，我看到越来越多的想法的追随者不要建立分支机构，因为这使得实践连续集成，连续交付等变得更加困难。对于具有分布式VCS背景的人们，他们在谈论如此大的合并实现时尤其有趣。 Git，Mercurial等 所以问题是我们现在应该使用分支吗？

84 continuous-integration  branching  scm 

我们的产品有几个不同的版本。区别是微小的：这里和那里的字符串不同，一个字符串中几乎没有其他逻辑，另一个字符串中几乎没有逻辑差异。开发软件时，大多数更改都需要添加到每个版本中。但是，有一些不需要，有一些需要有所不同。如果我有release-editionA和release-editionB（..etc）分支，是否可以有效使用分支？有陷阱吗？好的做法？ 更新：感谢大家的见解，在这里有很多好的答案。普遍的共识似乎是为此目的使用分支是一个坏主意。对于任何想知道的人，我对该问题的最终解决方案是将字符串外部化为配置，并将不同的逻辑外部化为插件或脚本。

72 git  branching 

git如何帮助解决以下情况： 我的任务分为两部分：后端任务和前端任务。我提出合并请求，以合并后端更改并等待其合并（和地址反馈）。在等待期间，我无法真正处理前端更改，因为它取决于后端更改，而这些更改在master分支上尚不可用。 在仍在审阅中时，从后端更改分支将更改引入到前端更改分支的最佳方法是什么？

65 git  branching 

刚接到一个电话，开发人员对每个sprint中将其故事集成到master分支表示担忧。开发人员所有代码都在自己的分支中，并且在冲刺结束时，他们都合并到一个主分支中。 然后，让一名开发人员（通常是同一位开发人员）负责确保所有内容都与其他开发人员的代码很好地集成在一起（大多数更改都在同一页面上。例如，数据显示故事，数据过滤故事和SLA指标）。 我们如何减轻这种负担并使我们的代码更容易合并在一起？从我的角度来看，让PO或SM以更有效的方式对故事进行优先级排序，以便我们在同一sprint中没有此类依赖关系可能会解决某些问题。其他人如何解决呢？还是这只是过程的一部分？

42 agile  scrum  branching  stories 

要求仅提交工作代码是个好主意吗？ 此提交无需使存储库处于工作状态，如下所示： ...我们正处于早期设计阶段，代码尚不稳定。 ...您是该项目的唯一开发人员。你知道为什么事情不起作用。此外，您不会通过提交损坏的代码来停止任何人的工作。 ...该代码目前无法正常工作。我们将对其进行重大更改。让我们承诺，以便在事情变得丑陋时有一点可以还原。 ...链很长，如果本地分支中存在损坏的代码，则不会有任何麻烦。即 本地文件 暂存区 提交到本地分支 提交到远程个人功能分支 与远程develop分支合并 与远程master分支合并 与远程release分支合并 ...提早提交，经常提交。 因此，在上面链接的问题中，大多数答案都说，提交不可编译的代码在本地和功能分支中没有问题。为什么？提交失败的价值是什么？ 补充：有几条备受赞誉的评论，说在当地一家人可以做任何想做的事。但是，我对该问题的技术方面不感兴趣。相反，我想学习最佳实践-习惯，这些习惯在行业中已经工作了很多年，他们的工作效率最高。 我惊讶于大量的出色答案！他们得出的结论是，我不擅长使用分支来组织代码。

40 version-control  git  branching 

说多个分支正在开发中，A并且B，还有一个增量“错误修复”分支C。 现在C已经“完成”并合并到母版中。A并且B仍在开发中，并且不会在（可能）另一个错误修复分支合并到master中之前进行修复。 C尽快合并到新功能分支中是一个好主意吗？以便使新功能尽可能接近master？还是让新功能在自己的“世界”中开发，然后在完成后才合并到母版中更好？ 无论如何都会有冲突，因此需要花费时间来解决这些冲突。

40 version-control  branching  merging 

当前，每次必须向应用程序中添加新功能时，我都会创建一个新分支。 功能完成并可以正常工作后，我将其与master分支合并。 但是稍后，当我需要更新此功能（如改进）时，创建一个新分支会更好还是还是需要使用master重新建立以前的分支，然后进行更新然后再次合并？ 例如，我在Ruby on Rails应用程序中有一个名为modelling-member的分支。稍后，我需要向成员模型添加一些属性（在此分支中创建）。我该怎么办？使用母版对该分支进行基础设置，更新模型并再次合并，还是只是创建一个新分支？

36 git  branching 

假设有一个由十个敏捷开发人员组成的团队。每天他们每个人都从董事会中挑选一项任务，并对它做出一些更改，直到（直到一天结束）他们已经完成了任务。所有开发人员都直接通过主干签入（Google风格，每次提交都是候选版本，使用功能切换等）。 如果他们使用的是像SVN这样的集中式CVS，那么每当其中一个提交时，构建服务器就会针对其他9个开发人员的工作进行集成并测试其更改。构建服务器几乎将全天连续运行。 但是，如果他们使用的是git之类的DCVS，则开发人员可能会等到完成任务后，再将所有本地提交一起推送到中央存储库。直到一天结束，他们的更改才会被整合。 在这种情况下，SVN团队更加频繁地进行集成，并且比git团队更快地发现集成问题。 这是否意味着DVCS比老式的集中式工具更不适合连续团队使用？你们如何解决这个推迟推送的问题？

34 git  svn  continuous-integration  dvcs  branching 

我以前一直使用git，但是我想为python做贡献，所以现在我必须学习mercurial，我发现它非常令人沮丧。 因此，我做了几个小补丁，并希望将它们作为提交记录在本地Mercurial存储库中。显然，有四种方法可以处理水银的分支。1和4对我来说完全是荒谬的，命名分支似乎是重量级的，我觉得我不应该将它们用于快速1提交修复，所以我使用了书签。 现在，我的补丁程序被拒绝了，我想从存储库中删除我的一个书签分支。好的，在git中，我只是强行删除我的分支而忘了它，所以我删除了书签，现在出现以下问题： TortoiseHG hg log仍然显示commit和defaultbranch有2个头。如果我理解正确，那么没有其他插件您将无法删除hg中的提交。 Mercurial不仅具有散列，而且具有修订号。当我添加了一些自己的提交时，所有之后提交的提交都具有与主要中央存储库不同的修订号。 我hg update在拉动master书签后自动将其移动到最新提交，但是在TortoiseHG中找不到该方法。 我究竟做错了什么？这是正常现象吗？应该，我应该忽略这些问题吗？或者我应该如何与分支机构合作？

32 git  mercurial  dvcs  branching 

首先，在某些背景下，我们正在将所有项目团队转移到使用git的过程中，并且正在制定有关如何组织存储库的准则，以便还可以监视某些分支机构的持续集成和管理。自动部署到测试服务器。当前，正在开发两种模型： nvie.com文章对成功分支产生了重大影响，其中master分支代表最稳定的代码，最新分支用于前沿代码，而集成分支则可以进行质量检查。 替代模型，其中master分支表示最前沿的开发代码，集成分支用于代码的质量保证测试，以及生产分支，用于生产稳定的代码，可以部署。 在这一点上，有关master分支代表什么的部分语义上的问题，但是在master分支上进行主动开发实际上是一种好习惯还是不是那么重要？

32 git  branching