Questions tagged «version-control»

如果我在代码中遇到了非关键性的拼写错误（例如，print（error）语句中出现了错误的撇号），是否值得做出承诺来解决该错误，还是应该将其单独放置？ 具体来说，我很好奇如何权衡提交日志的解决方案与解决这些非关键错别字的价值。我倾向于解决它们。我是在学脚吗？

67 version-control  grammar 

我曾在多个地方听到过“不要做大的提交”，但我从未真正理解过什么是“大的”提交。如果您处理一堆文件（即使有关联），它会很大吗？您应该一次处理多少个项目？ 对我来说，我很难做出“小的承诺”，因为我忘记或创建了会创建其他东西的东西。然后，您将得到如下内容： 制作自定义传出队列 机器人 -新字段msgQueue，无非就是SingleThreadExecutor -sendMsg阻止直到发送消息为止，并在消息获取之间添加等待时间 已发送 -adminExist调用已更新（请参阅控制器） -删除被调用方的sendMessage 控制者 -新字段msgWait表示消息之间等待的时间 -开始将服务插件移至reloadPlugins -adminExists由于全局管理员而从服务器移出。检查频道 服务器和全局级别 管理员 -获取适当对象Admin的新方法getServer和getChannel 属于 BotEvent -toString（）还显示了extra和extra1 渠道 -channel字段重命名为name -修正频道（int）中的错字 服务器 -将adminExists存在到控制器中 插件执行器 -增加了次要测试，稍后将删除 JS插件 -更新为框架变更 -用Controller.instance替换InstanceTracker.getController（） -VLC现在在自己的文件中交谈 各种NB项目更新和更改 --- 受影响的文件 修改/trunk/Quackbot-Core/dist/Quackbot-Core.jar 修改/trunk/Quackbot-Core/dist/README.TXT 修改/trunk/Quackbot-Core/nbproject/private/private.properties 修改/trunk/Quackbot-Core/nbproject/private/private.xml 修改/trunk/Quackbot-Core/src/Quackbot/Bot.java 修改/trunk/Quackbot-Core/src/Quackbot/Controller.java 修改/trunk/Quackbot-Core/src/Quackbot/PluginExecutor.java 修改/trunk/Quackbot-Core/src/Quackbot/info/Admin.java 修改/trunk/Quackbot-Core/src/Quackbot/info/BotEvent.java 修改/trunk/Quackbot-Core/src/Quackbot/info/Channel.java 修改/trunk/Quackbot-Core/src/Quackbot/info/Server.java 修改/trunk/Quackbot-GUI/dist/Quackbot-GUI.jar 修改/trunk/Quackbot-GUI/dist/README.TXT 修改/trunk/Quackbot-GUI/dist/lib/Quackbot-Core.jar 修改/trunk/Quackbot-GUI/nbproject/private/private.properties 修改/trunk/Quackbot-GUI/nbproject/private/private.xml 修改/trunk/Quackbot-GUI/src/Quackbot/GUI.java …

65 version-control 

我一直在阅读Martin Fowler关于持续集成的说明，他将其列为“每个人每天都致力于主线”。 我不喜欢提交代码，除非正在处理的部分完成并且在实践中我每三天提交一次代码：一天用于调查/重现任务并进行一些初步更改，第二天完成更改，以及第三天编写测试并清理^以提交。我不愿意早日提交代码。 现在，我通常每天两次从存储库中提取更改并将其集成到本地，但是除非我能完成较小的工作，否则我不会经常提交更改。 问题：每天做这样一个好习惯，是否应该更改工作流程以适应它，还是不建议这样做？ 编辑：我想我应该澄清一下，我在CVS中的意思是“提交”（也称为“推送”），因为这可能是Fowler在2006年撰写此书时的意思。 ^顺序更加随意，并取决于任务，我的意思是说明时间跨度和活动，而不是确切的顺序。

63 version-control 

更新 我在一个由4个人组成的小型开发团队中工作。他们都使用了源代码控制。他们中的大多数人不能忍受源代码管理，而是选择不使用它。我坚信源代码控制是专业发展的必要部分。有几个问题使得说服他们使用源代码管理非常困难： 该团队不习惯使用TFS。我进行了2次培训，但只分配了1个小时，这是不够的。 团队成员直接在服务器上修改代码。这样可以使代码不同步。要求比较只是为了确保您正在使用最新的代码。并出现复杂的合并问题 开发人员提供的时间估算不包括解决这些问题所需的时间。因此，如果我说诺诺，则需要花费10倍以上的时间...我必须不断地解释这些问题并冒险冒险，因为现在管理层可能会认为我“慢”了。 服务器上的物理文件超过100个文件以未知的方式有所不同。合并需要了解手头的项目，因此需要我无法获得的开发人员合作。 其他项目不同步。开发人员继续对源代码管理不信任，因此不使用源代码控制使问题更加复杂。 开发人员认为，使用源代码控制很浪费，因为合并容易出错并且很困难。这很难辩驳，因为当源代码控制被严重滥用而源代码控制被不断地绕开时，它确实容易出错。因此，证据在他们看来是“不言而喻”。 开发人员认为，绕过TFS直接修改服务器代码可以节省时间。这也很难争论。因为开始同步代码所需的合并非常耗时。乘以我们管理的10多个项目。 永久文件通常与Web项目存储在同一目录中。因此，发布（完全发布）会删除这些不在源代码管理中的文件。这也加剧了对源代码控制的不信任。因为“发布破坏了项目”。解决此问题（将存储的文件移出解决方案子文件夹）需要花费大量时间和调试时间，因为这些位置未在web.config中设置，并且通常存在于多个代码点中。 因此，文化会持续存在。不良做法会导致更多不良做法。不良的解决方案会驱使新的黑客“更正”更深层次，更耗时的问题。服务器，硬盘空间极难获得。然而，用户的期望正在上升。 在这种情况下可以做什么？

62 version-control  teamwork  team-foundation-server  cowboy-coding 

我听说Google拥有一个巨大的私有（内部）所有代码存储库，其员工可以访问它，因此在开发事物时，他们不必重新发明轮子。我想了解更多！ Google上有没有人可以更详细地描述它，或者您是否对此有所了解？我感兴趣的是主要了解它的组织方式以及它们如何使员工轻松找到必需的庞大代码库中的内容。

62 version-control  google 

如果您是独立开发人员，您认为使用版本控制是否值得？如果是，为什么？您是否将存储库保留在自己的计算机上或其他可以用作备份的计算机上？

60 version-control  solo-development 

当在项目上工作时，可以在几天或一点点的时间内，以相当快的速度开发代码，并持续数周/月/年。随着代码提交已被视为衡量项目开发的标准，这并不意味着编写的代码要比提交次数少的项目多。 所以问题是什么时候真正对存储库进行提交，以便提交是合理的？ 作为附加组件：根据提交的数量来衡量项目的开发是否正确？

59 programming-practices  version-control  coding 

我们正在与一些需要为我们的项目之一做出贡献的非程序员（作家）合作。 现在，他们只是不喜欢使用Git（或与此相关的任何东西）进行版本控制其工作的想法。我认为这是因为他们只是觉得不值得把头放在版本控制的扭曲概念上。（当我第一次向他们介绍分支和合并时-他们看起来像是冒犯了他们。） 现在，我们无法对他们进行教育或说服他们使用它。我们只是在尝试寻找替代方案，以便我们对他们的所有工作进行版本化（这是我们所需要的），并且他们可以轻松地进行工作流并专注于自己的工作。 我想出了一些主意... 告诉他们每次进行不重要的更改时都将工作另存为单独的文件，然后在我们这边使用diff来跟踪更改。 用Python编写一个以某种方式实现CSSEdit中“里程碑”的程序。 关于该项目： 它是一种自然语言处理系统（用C + Python编写）。我们已经聘请了一些作家来用不同的语言为系统准备输入。随着软件的发展，我们需要那些作者来更改他们的输入（文章）。有时变化很小（一两个字），而其他时候变化很大。 我们需要对这些更改进行版本控制的原因是，输入中的每个小/大更改都有可能显着更改系统的输出。

57 programming-practices  version-control  teamwork 

数据库文件（脚本等）应该在源代码控制中吗？如果是这样，保留它并在那里更新的最佳方法是什么？ 甚至需要数据库文件进行源代码控制，因为我们可以将其放在开发服务器上，每个人都可以使用它，并在需要时对其进行更改。但是，如果有人把它弄乱了，我们就无法取回它。 哪种方法最适合源代码控制数据库？

57 database  version-control 

一位开发人员已经着手开发新的Drupal项目，并且sysadmin建议他们只应将sites / default子目录放在源代码管理中，因为它“将使更新易于编写脚本”。撇开这个有点可疑的说法，这又引出了另一个问题：哪些文件应在源代码控制下？是否存在应排除一些大文件的情况？ 我的观点是，该项目的整个树都应受到控制，这对于Drupal项目，Rails或其他任何项目都是正确的。这似乎不费吹灰之力-您显然需要为框架编写版本控制，以及为编写的任何自定义代码所做的操作一样多。 也就是说，我很乐意就此发表其他意见。是否有任何理由不控制一切？

54 version-control  drupal 

我想知道我处理需要从版本控制中删除的源文件的方式是否被视为不良做法。 我想根据该示例向您解释： 最近我非常生气，因为我必须在程序中将Java类繁琐地整理出来，这些类基本上是无效的代码，但是在这些Java类中都没有文档记录和注释。当然，需要删除它们，但是在删除这些多余的东西之前，我有一个-有些人可能说奇怪-习惯： 我不会立即通过SVN-> Delete（用您选择的版本控制系统的delete命令替换）来删除这些冗余文件，而是将注释放置在这些文件中（这些文件的开头和结尾处都是引用）被删除+我的名字+日期，以及-更重要的是- 为什么被删除（在我的情况下，因为它们已经死了，代码令人困惑）。然后保存并提交给版本控制。下次当我必须在项目中提交/签入版本控制时，我按SVN-> Delete，然后最终将它们在版本控制中删除-当然仍然可以通过修订来恢复，这就是为什么我采用了这种习惯。 为什么要这样做而不是立即删除它们？ 我的理由是，我至少要在存在那些冗余文件的上一个修订版本中要有显式标记，为什么应该删除它们。如果我立即删除它们，它们将被删除，但是没有地方记录为什么删除它们。我想避免这样的典型情况： “嗯...为什么删除了那些文件？我以前工作得很好。” （按“还原”->还原然后再消失的家伙将在下个星期永远消失或不可用，下一位受让人必须像我一样单调乏味地找出这些文件的内容） 但是您没有注意到为什么这些文件在提交消息中被删除了吗？ 我当然可以，但是同事有时看不到提交消息。在您试图理解（在我的情况下为死机）代码时，首先使用所有关联的提交消息检查版本控制日志的情况并不常见。与其查看日志，不如立即看到该文件无用。这样可以节省她/他的时间，并且她/他知道此文件可能已恢复为坏文件（或至少引起了一个问题。）

53 version-control  svn  evidence-based 

我是一个成长中的程序员，他最终将我存储在GitHub上的库的单元测试付诸实践。 在我看来，我可能会在测试库中包含测试套件，但是当我环顾其他项目时，包含测试似乎是命中注定的。 这是不好的形式吗？是不是用户只对工作代码感兴趣，是否仍将在自己的框架中进行测试？

50 version-control  unit-testing 

大约三个月前，我的公司从Subversion切换到Git。切换之前，我们已经提前了数周的通知。由于我以前从未使用过Git（或任何其他DVCS），因此我读了Pro Git，花了一些时间来整理自己的存储库并玩耍，这样当我们切换时，我将能够以最小的痛苦继续工作。现在，我默认为“ Git guy”。 除了几个例外，我的大多数团队仍然不知道Git的工作方式。例如，他们仍然将分支视为源代码的完整副本，甚至将克隆仓库克隆到多个文件夹中（每个分支一个）。他们通常将Git视为一个可怕的黑匣子。 鉴于源代码管理在我们日常工作中的基本本质（更不用说Git赋予我们的可笑的力量了），我认为任何未达到一定熟练程度的开发人员都应该承担责任。 我是否应该期望我的团队至少对Git的内部工作以及如何在最基本的拉/合并/推操作之外使用它有所了解？还是我只是一无所有？

48 version-control  professionalism 

我的团队使用Team Foundation Server进行源代码控制，今天我在签入之前修复了一些错误和冒烟测试应用程序，但是我忘了注释一些代码。（此代码使UI有点奇怪。） 我想在签入代码之前先知道有什么好的做法-我不想再犯这种错误。

47 version-control  team-foundation-server  configuration-management 

假设我正在编写同一软件/程序/应用程序/脚本的两个不同版本，并将它们存储在版本控制下。第一个版本是免费的“基本”版本，而第二个版本是付费的“高级”版本，它采用了免费版本的代码库，并在其上扩展了一些额外的增值功能。任何新的补丁程序，修补程序或功能都需要找到进入两个版本的方式。 我目前正在考虑使用master和develop分支作为主要代码库（免费版本），以及使用边master-premium和develop-premium分支作为付费版本。对免费版本进行更改并合并到master分支（develop当然，在进行了彻底的测试之后），develop-premium通过cherry-pick命令将其复制到分支以进行更多测试，然后合并到中master-premium。 这是处理这种情况的最佳工作流程吗？有潜在的问题，警告或陷阱需要注意吗？是否有比我已经提出的更好的分支策略？ 非常感谢您的反馈！ PS：这用于存储在Git中的PHP脚本，但是答案应适用于任何语言或VCS。

45 version-control  workflows