Questions tagged «version-control»

跟踪，存储和检索源代码修订的编程学科。

6
我什么时候应该停止致力于掌握新项目？
每当一个新项目开始时，通常首先要直接向master提交，直到获得“稳定”的东西，然后再开始在分支中工作才有意义。 至少，这是我通常的做法。有没有办法立即从第二次提交开始分支？以这种方式这样做有意义吗？显然，“ Initial Commit”将始终处于主状态，但是在那之后，我何时才知道是为新功能创建分支的合适时间？
8
Git-直接在master上工作会出现什么问题？
我已经看到了很多有关git分支模型的建议，最普遍的观点似乎是直接在master分支上进行更改是一个坏主意。 我们的一位同事很高兴直接在主分支上进行更改，尽管进行了几次交谈，但他们似乎不太可能更改此更改。 在这一点上，我无法说服一个不擅长直接在师傅上工作的同事，但我想了解会与他的工作方式相抵触的事物，知道何时需要重新访问这个问题。
6
如何处理复杂的合并
这是一笔交易，我加入了一家新公司，并被要求完成在已经近一年没有碰过的分支机构上的工作。同时，主分支机构也在稳定增长。理想情况下，我希望将master分支中的所有更改合并到feature分支中，然后从那里继续工作，但是我不太确定该如何处理。 如何在保留分支两侧的重要更改的同时安全地执行此合并？
6
TDD和版本控制
我目前正在学习TDD，并试图在我的个人项目中将其付诸实践。在许多这些项目中，我还广泛使用了版本控制。我对这两个工具在典型工作流程中的相互作用感兴趣，尤其是在使提交保持较小的原则上。以下是一些示例： 我开始一个新项目，并编写一个简单的测试以创建一个尚不存在的类。即使测试甚至无法编译，我也应该在编写类之前提交测试吗？还是应该在提交之前编译测试所需的最少代码量？ 我找到一个错误并编写测试以重新创建它。我应该提交失败的测试还是实施错误修复然后提交？ 这是两个立即想到的例子。随时在您的答案中提供其他示例。 编辑： 我在两个示例中都假设，在编写测试之后，我将立即编写代码以使测试通过。可能还会出现另一种情况：我在使用TDD的项目上工作了几个小时而没有提交。当我最终提交内容时，我想将我的工作分解成小块。（即使您只想在单个文件中提交某些更改，Git也会使此操作相对容易。） 这意味着，我的问题是一样关于为什么承诺，因为它是何时提交。
7
当构建几乎总是被破坏时如何保持效率
我在一个中型团队中工作，该团队共享相同的源代码，并且有持续的集成，但是由于我们所有人都必须在同一个分支中工作，因此构建几乎总是被破坏。 我们还有一条规则，该规则最近被引入以减轻损坏的构建，该规则指出在构建为红色时不允许任何人签入。 话虽这么说，一天中每个人都只有几个10-15分钟的窗口，我们可以在那里办理登机手续。 并且随着团队的成长，签到机会的窗口会进一步缩小。这迫使开发人员在本地积累他们的更改，从而导致更大的更改集，这甚至更加难以确保更改不会破坏任何内容。您可以看到恶性循环。 您能推荐什么使我在这样的环境中保持有效的工作。另外，请记住，我是开发人员，而不是经理，并且不能改变流程或其他人的行为。
6
编程学生更容易使用哪种DVCS（git或hg）？[关闭]
关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，使它成为软件工程堆栈交换的主题。 5年前关闭。 有一点背景：我正在上大学三年级。学生分为4人一组。几乎每个人都将在Windows下工作（除了像我这样在Linux上的一些人）。作为学校课程的一部分，我们将很快开始为一个真正的客户开发项目，但是我和另一个团队想知道哪种方法最适合彼此共享我们的代码。 我从事兼职工作已有3年，并且在不同项目上同时使用git和mercurial有丰富的经验，因此使用一个或另一个系统没有任何问题。但是，我的队友以前从未使用过版本控制系统。还有另一个团队尝试使用SVN但遇到了重大问题，并且希望尝试其他尝试，因此他们征询了我的意见。 我的想法：听说Mercurial + TortoiseHg在Windows下具有更好的集成，但是我想知道即使我解释了匿名头的概念是否也可能使他们感到困惑。另一方面，我发现git分支对于初学者来说更容易理解（每个程序员的工作分离清晰），但在Windows下效果不佳。
8
如何管理封闭源高风险项目？
我目前正计划开发一个J2EE网站，并希望邀请1个开发人员和1个Web设计师来为我提供帮助。该项目是利基市场中的金融应用程序。 我计划保持源关闭。但是，我担心我的潜在员工会轻易复制代码库并使用它或将其出售给第三方。该应用程序的开发将需要4到6个月的时间，也许还要更长的时间，并且在该应用程序上线后，我可能会增加其他员工。 但是，我该如何保持来源自负。公司是否使用技术来保护其来源？ 我预见到将在开发计算机上禁用USB驱动器和DVD刻录机，但是仍然可以上传数据或将代码附加到电子邮件中。 我的问题不完整。但是遇到我这种情况的程序员请指教。我应该怎么做？建立团队，维护代码保密性等。 我也期待与员工签订保密合同。（请添加相关标签） 更新资料 感谢您的所有答案。我当然不会现在禁用所有USB端口和DVD刻录机。但是我认为我应该记录活动（我应该怎么做？）我对那些会加入现有代码并随后跑掉的黄牛警惕。我什么都没见，但建议我要警惕他们。我会包含一个保密条款，但是鉴于这是一家几乎没有资金的初创公司，并且在竞争激烈的业务利基市场中，该领域有较大的参与者，我怀疑我是否能够发现或追捕黄牛。 当我本人不认识我时，我该如何雇用他们信任的人。他们的简历会有所帮助，但是信任只会随着时间的推移而发展。 但是最后，即使他们确实使用了代码，销售后的服务也很重要。因此，我从长远来看并不真正担心。
4
如何使用github，分支机构和自动发布进行版本管理？[关闭]
已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 5年前关闭。 到目前为止，我已经了解了大多数基本的Git / Github概念，但是仍然很难理解全局。 到目前为止，我已经设法使这些事情起作用： 推送提交 与分支机构合作 将Github与Travis CI（一个持续集成系统）集成 通过Travis CI，可以自动构建对master的每次提交，并将该发行版作为ZIP放在Github上的发行版之下。 但是到目前为止，我只从事项目的alpha / beta版本工作，因此我还从未见过实践中的版本发布。 因此，我想了解更多有关版本控制，维护单独的版本，修复版本等信息。 我将如何确保发生以下情况： 我的项目有不同的版本，例如版本1.1.0和2.0.0 能够在版本上推送修补程序，将版本提高到1.1.1或2.0.1，等等。 使一个持续集成系统在提交时自动构建该版本，如果成功，则发布该特定版本的发行版。 我怀疑以下选项之间： 每个版本都需要使用标签吗？如果是这样，一个持续集成系统如何构建自动发布？ 我应该为每个版本创建分支吗？如果是这样，那将不会创建大量的分支（例如1.1和2.0分支，修补程序当然会进入该分支） 我将如何指定版本号？是否可以使用一个指定版本号的配置文件，还是可以使用更智能的方法？在这种情况下，这很重要，这将是一个Java项目。
6
量化现代版本控制系统的优势[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 5年前关闭。 在过去的三年中，我一直在大型金融企业环境中担任团队负责人/开发人员。我们的产品发布过程是一场噩梦，因为它围绕Clearcase展开。我们有一个变更管理小组，负责执行所有版本，并且只允许将代码从生产中带入生产。 加入时，我要做的第一件事就是与Git建立团队。每个人都同意，Clearcase太糟糕了，对于处理日常源代码控制事务不切实际。因此，我们在本地计算机上建立了一种“非官方”存储库，并编写了一个脚本以在发布时同步git和Clearcase存储库。 这句话传给其他团队，有几个团队采用了相同的过程。以“非官方”方式使用git进行日常活动，以“官方”方式使用Clearcase进行发布。对于Git的任何问题，我都非常喜欢。 因此，本周我将与基础架构变更高级副总裁开会，他特别希望我向她解释Git的优点。显然，我在Clearcase上听到了我的常识。如果她接受我的论点，我将真正帮助我的雇主摆脱这种可憎的事情。 我与高管的经验告诉我，他们a）想要对所有事物进行极为简洁的解释b）只对涉及美元数据的事实感兴趣 我可以向开发人员解释Git优于Clearcase的优点（或针对此问题的Clearcase的任何其他版本控制系统），但是我正在向没有技术背景的技术主管说明如何做到这一点（她有一个工商管理硕士（MBA），并取得地理学本科学位。 我觉得我对她的任何争论要么听起来像是胡言乱语，要么是我在宣扬自己的个人喜好。 我要查找的是具体事实，这些事实表明开发人员可以更有效地使用Git或任何现代源代码控制系统。 我认为其他团队已经开始在内部使用Git是一个有意义的信号，但是它仍然不够强大，因为它仍然可以作为个人喜好而忽略。 我真正需要的是一个足以突破“这个过程已经工作了20年，为什么我们要改变它呢？”的功能。论点。
4
如何将库的不同版本置于版本控制之下？您是否使用标签？还是分支机构？还是其他方法？
我最近开始将代码置于版本控制下（在实验室中，我正在SVN下工作，而我自己的代码在github中（显然是git））。在使用版本控制之前，我曾经做过类似的事情。我有一个带库名称的文件夹，其中有许多带版本号的文件夹。每当我想开始使用新版本时，我都会复制上一个版本，将名称更改为新版本并开始实施。 但是，当将文件夹置于版本控制下时，这似乎是多余的。除了冗余之外，如果有人想获得最新版本，那么只要他import/ 她就可以下载所有版本clone。 现在，我看到了使用版本控制执行此操作的许多方法，但是由于我是新手，所以我不知道哪种方法更可维护。 方法1：使用标签 如果我正确地理解了标签，那么您将拥有主分支，您可以进行所做的任何更改并使用版本进行标签。然后，当您想要获得它的工作副本时，您将获得带有特定标签的副本。（如果我错了纠正我） 方法2：分支版本 在这种方法中，主要分支将是开发分支。时不时地制作一个稳定的版本（例如v1.2.0），您为该版本创建一个分支，并且永远不要提交它。这样，如果您要下载某个版本，则可以从该分支获取代码。尽管我说过您从未承诺过这样做，但有可能进行错误修复并承诺到旧版本的分支以保持旧版本运行。例如，如果当前版本为v2.0，但是有些人想要使用v1.2，则可以从中获取另一个分支v1.2，即v1.2.1提交错误修复程序，或者仅将版本保持不变，v1.2然后提交错误修复程序。 所以分支看起来像这样： v1.2.1 v1.2.2 / / v1.0.0 v1.2.0--------- v2.0.0 / / / -------------------------------------- dev 这样，您可以为每个次要版本更新创建分支。（请注意，在上图中，v1.2.1和v1.2.2或在v2.0.0发布之后创建的，因此它们不是v1.2.0和v2.0.0之间的开发的一部分。可以将其视为对较早版本的支持） 方法3：分支发展 此方法与以前的方法相反。主分支将是最新的稳定版本。每当使用新版本时，都将创建一个分支（用于开发），使用您的代码，并在代码稳定后将其与主分支合并。 在这种情况下，分支看起来像这样： ________ ____ ________________ _____ dev / \/ \/ \/ ---------------------------------- latest_version 可能需要结合标签一起执行此操作吧？ 问题！ 无论如何，我的问题是，根据您的经验，这些方法中的哪一种被证明更实用？有没有已知的最佳方法（可能我没有弄清楚自己）？这些事情通常是怎么做的？
9
在企业环境中使用Git [关闭]
已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 5年前关闭。 Git是一个出色的版本控制系统。如果我们排除这一事实，它没有出色的GUI支持，那么它确实很好并且速度很快。但是像Clearcase这样的源代码控件为企业客户提供了大量支持。公司为源代码控制服务器和licesense投入了大量资金。 最近，像Google这样的大多数大公司都在其他版本控制系统上采用了Git。但是该公司有一个强大的开源团队，他们始终为该工具提供开发和支持（他们甚至可能拥有自己的Git定制版本）。同时，大公司并没有真正在意采用开源项目并使之与它们相关。 对于企业环境，尤其是在Windows平台上，Git真的是可靠的工具吗？ 对Git的支持存在疑问，因为它是一个开源产品。 是否有提供解决方案和支持的公司？与其他版本控件（如Clear-case）相比，服务器成本如何？
5
当所有开发都在分支机构上时，如何重构？
在我公司，我们所有的开发（错误修复和新功能）都在单独的分支机构进行。完成后，我们将其发送给质量检查人员（QA），由该人员在该分支机构对其进行测试，当他们给我们开绿灯时，我们会将其合并到我们的主分支机构中。这可能需要一天到一年的时间。 如果我们尝试压缩分支上的任何重构，我们将不知道它会“退出”多长时间，因此在合并回它时会引起许多冲突。 例如，假设我要重命名一个函数，因为我正在使用的功能正在大量使用此功能，而我发现它的名称确实不符合其用途（再次，这只是一个示例）。因此，我四处寻找该函数的每种用法，并将它们全部重命名为新名称，并且一切正常，因此将其发送给质量检查人员。 同时，正在进行新的开发，并且我的重命名函数在main分支的任何分支上都不存在。当我的问题重新合并后，它们都会崩溃。 有什么办法解决吗？ 并不是说管理部门会批准仅重构的问题，因此必须将其与其他工作联系在一起。它不能直接在main上进行开发，因为所有更改都必须经过质量检查，而且没人愿意成为打破main的混蛋，以便他可以执行一些不必要的重构。
6
将编码进度拆分为有意义的提交而无需太多开销
当处理修订或功能时，有时我会偶然发现其他细微的问题，这些问题可以在几秒钟内即时得到改善。当我立即执行它们，然后提交完成的功能/修复程序时，提交包含不止一件事。例如"add feature X and code clean up"或"fix bug X and improved logging"。最好将其分为两个提交。万一这两个更改发生在同一个文件中，我不能简单地添加一个文件，提交，添加另一个文件然后再次提交。因此，我看到以下三个选项： 在处理某些事物时故意忽略无关的事物。 复制具有两个更改的文件，将其还原，包括一个更改，提交，包括另一个更改，然后再次提交。 不要更改无关紧要的小东西，而是将它们添加到待办事项列表中，然后再做。 我不太喜欢这三个选项，原因如下： 如果不能解决小问题，则代码质量可能会受到影响。如果我有意识地错过了一次不费吹灰之力就可以改善的机会，那我就会感到难过。 这会增加人工工作，并且容易出错。 这对于不太小的待办事项很好，但是将一个微小的项目添加到待办事项列表中并稍后再访问通常比立即修复要花费更长的时间。 您如何处理这种情况？
7
我可以暂时使用GPL库进行原型制作，并使以后的代码封闭源吗？
我正在开发一个软件系统的原型，该原型（至少在开始时）将是封闭源代码。 为了节省时间，我正在考虑使用（即静态链接）在GPLv3下获得许可的库，因此我可以快速测试设计。如果在此阶段分发软件，则必须随同分发源代码。 如果我不这样做，但是让自己确信我的系统可以运行，然后在分发之前用我自己的代码替换GPL库，该怎么办？结果会被GPL“污染”吗？ 我感觉是否在我的Git历史记录中保留GPL库可能会有所作为。
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.