Questions tagged «version-control»

从技术角度来看，可以添加一些前/后推钩，以在允许某些特定的提交合并到远程默认分支之前运行单元测试。 我的问题是-最好将单元测试保留在构建管道中（因此，将损坏的提交引入仓库），还是最好不要允许“不良”的提交发生。 我确实意识到我不受这两种选择的限制。例如，在将合并提交提交到仓库之前，我可以允许所有提交分支和测试。但是，如果您必须在这两种解决方案之间进行选择，那么您将选择哪种解决方案，以及出于哪些确切原因？

43 version-control  continuous-integration  hooks 

我们被要求在我们对代码进行的每个更改中添加带有开始标签，结束标签，描述，解决方案等的注释，作为修复错误/实现CR的一部分。 我担心的是，这会带来任何附加值吗？实际上，我们具有版本控制历史记录中的所有详细信息，这将有助于我们跟踪每个更改？ 但是我的领导者坚持将注释作为一种“好的”编程习惯。他们的论据之一是，当必须对CR进行范围界定/更改时，如果没有评论，那将很麻烦。 考虑到这些更改将主要在代码之间进行，是否真的有助于为我们所做的每一个更改添加注释？我们不应该把它留给版本控制吗？

42 version-control  bug  comments  change 

与实际确定“最佳”尝试相比，这更是一个讨论问题，因为这显然会因组织的需求而异。我对支持不同类别（集中式，分布式，开放式与专有等）的不同系统的论点感到好奇。 那么，您认为最好的版本控制系统是什么？

41 version-control 

我正在为处理PDF文件的功能编写一些测试代码。测试背后的基本思想是，将它们指向我专门选择的一些PDF，它们会对其进行处理，然后检查输出是否符合我的期望。 我的问题是：我应该在哪里存储这些大尺寸的PDF？我应该将它们与代码一起检查到版本控制中吗？还是将它们放在其他地方？显然，没有PDF（甚至不同的PDF）的测试代码是没有用的，但是仍然将它们放入我们的存储库中仍然感觉不对。

40 testing  version-control  data 

将错误号放在文件本身的标题注释中是一种好习惯吗？ 评论看起来像这样： MODIFIED (MM/DD/YY) abc 01/21/14 - Bug 17452317 - npe in drill across in dashboard edit mode cde 01/17/14 - Bug 2314558 - some other error description 似乎有帮助，但是否认为这是不好的做法？

40 version-control  development-process  source-code  comments 

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

40 version-control  git  branching 

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

40 version-control  branching  merging 

在Git中，可以设置并强制执行良好的提交模板。 您能推荐（最好是带有论点的）好的提交模板/准则在公司中执行吗？

38 version-control  git  dvcs 

有时，当我们检查软件的提交历史时，我们可能会发现确实有一些提交是非常大的-它们可能会更改10或20个文件，其中包含数百个更改的源代码行（增量）。我记得有一个用于BIG提交的常用术语，但是我不记得确切的含义。谁能帮我？程序员通常用来指代这种BIG和巨型提交的术语是什么？ 顺便说一句，一起做出很多更改是一种好的做法吗？ 更新：谢谢你们的启发性讨论！但是我认为“代码炸弹”是我想要的术语。

37 programming-practices  version-control  terminology 

我们的项目使用特定于用户的配置文件。该文件当前不在版本控制中，因为每个用户都不同。问题是，每当开发人员添加需要配置的新模块或更改现有模块的名称时，其他开发人员都会因未更新其私有配置文件而出错。 为了解决该问题，我们考虑使用两个配置文件：一个默认/全局配置文件，该文件将在版本控制中，并由添加新模块的每个开发人员定期更新；一个私有配置文件将被排除在外版本控制，将仅包含用户特定的更改。 但是，这似乎仍然是临时解决方案。 您可以提出更好的解决方案吗？ 专业人士做什么？

36 version-control  configuration-management 

我是自己的唯一开发人员，并且我了解VCS的好处；我发现很难坚持良好做法。目前，我正在使用git开发主要是Web应用程序（由于我的工作，该应用程序永远不会开源）。 我当前的工作流程是对开发站点进行大量更改，测试，修改，测试，满意并提交更改，然后将提交推送到实时站点（因此，如果我正在进行新的大更改；我可能只每周提交一次；但是我的IDE对于未提交的内容具有良好的撤消历史记录）。 基本上，我仅在机器之间切换时才使用git（例如，从工作开发计算机到家用开发计算机或在运行中的计算机），但是在白天，我并没有真正看到它的好处。这导致我的更改清单很长（而且我很难为每次提交找到合适的msg；而且每当我匆忙时-我往往会留下一些糟糕的消息，例如“对管理员和模板的其他更改”）。 我应该多久提交一次？每个单行更改都应该提交吗？我应该在任何测试之前提交（例如，至少针对语法/编译错误，然后必须完全撤消它；因为该想法行不通或消息是谎言）？ 我应该确定每天早晨/下午都下班之前，还是在仍然新鲜的时候停止吃晚饭吗？不良的VCS习惯让我错过了什么？

36 version-control  solo-development 

在我们的团队中，我们使用Git作为源代码控制。我们有几个几乎独立的代码区域，但是有一些重叠。最近，我们一直在讨论使用源代码管理的工作流程和方法。当我使用功能分支工作流进行升级时，出现的一个抱怨是人们经常遇到复杂的合并冲突，而他们无法正确解决。复杂地说，我的意思是“解决方法不明显”。鉴于此，正在更加积极地使用其他工作流程，例如基于“拉底”的工作流程。 作为功​​能分支方法的倡导者，我并没有真正抱怨过。是的，您必须保持本地要素从master或任何地方分支最新，但这是我所看到的唯一真正的问题。我在想，如果您的合并总是很复杂并且可能会产生辅助影响，那么这更多是团队合作问题，而不是Git问题。 我认为正确吗？复杂的合并冲突是好事还是坏事的征兆？

35 version-control  git  teamwork 

我们正在尝试将项目文档流程从Google文档移至一组自托管的Git存储库。 文本文档对Git足够友好，因为我们通常不需要任何精美的格式，因此我们仅将所有内容转换为multimarkdown，并可以在复杂情况下嵌入LaTeX。 但是电子表格的故事大不相同...是否有一种类似于版本控制系统的扩展格式（最好与Markdown一样易于阅读）？ “友好格式”：Git与格式兼容（不适用于XML），并且生成易于理解的差异（可以进行涉及外部工具的额外配置）。 显然，Markdown风格允许建立静态表，但我希望能够使用诸如此类的东西SUM()（请注意CSV也存在相同的问题。）没有所见即所得的功能，但是可以提供不错的编辑器/工具支持很好 更新：请仅提供Linux友好的答案。没有MS Office资料。

35 version-control  documentation  tools  linux 

我正在考虑使用sourceforge，bitbucket或github管理我的业务的源代码控制。我有开放项目，并且参与过gcc等开放项目。但是我也有一家公司，我为自己的生活开发开源软件。 Sourceforge，github或bitbucket在保持软件安全以防窥视方面值得信赖吗？在防止数据丢失方面，主机的稳定性如何？有没有人以这样的服装来建立他们的业务逻辑？有没有人调查过几种托管解决方案？

32 version-control  github  project-hosting  code-security  bitbucket 

我很好奇，程序员团队通常是如何在80年代和90年代初期管理软件开发的。是将所有源代码简单地存储在每个人都在使用的计算机上，还是将源代码通过软盘传递并手动复制并手动合并，还是像我们那样通过网络（例如CVS）实际使用版本控制系统？现在？还是正在使用离线CVS之类的东西？ 如今，每个人都依赖于源代码管理。但是在80年代，计算机网络并不是那么容易设置，并且诸如最佳实践之类的东西仍在研究中…… 我确实知道在70年代和60年代编程非常不同，因此不需要版本控制。但是到了80年代和90年代，人们开始使用计算机编写代码，并且应用程序的大小和范围开始扩大，所以我想知道那时人们是如何管理所有这些的。 此外，这在平台之间有何不同？说Apple vs Commodore 64 vs Amiga vs MS-DOS vs Windows vs Atari 注意：我主要是在谈论当今微型计算机上的编程，而不是大型UNIX 计算机上的编程。

31 version-control  history