Questions tagged «version-control»

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

11
如何为自己设置源代码控制系统？
我可以在办公室的台式机上进行编程，有时也可以在笔记本电脑上的其他房间在家中进行编程，甚至可以不在家里。我需要的是一个可以根据需要自动或按需将我的工作从一个同步到另一个的系统。 我没有家庭网络设置，尽管我想我可以做到，但是这可能是另一个委员会的问题。我已经考虑过某种可以将源代码保存在云中的系统，但是我对此并不足够了解。我需要一种免费或廉价的方式来执行此操作。 我在.NET（实际上是Windows Phone 7）中工作。
5
重新格式化和版本控制
代码格式很重要。甚至缩进也很重要。一致性比微小的改进更为重要。但是，项目通常从第一天起就没有清晰，完整，可验证和强制的样式指南，并且重大改进可能会在任何一天出现。也许你发现 SELECT id, name, address FROM persons JOIN addresses ON persons.id = addresses.person_id; 可以更好地写成/比 SELECT persons.id, persons.name, addresses.address FROM persons JOIN addresses ON persons.id = addresses.person_id; 同时在查询中添加更多列。也许这是代码中所有四个查询中最复杂的查询，或者成千上万个简单查询。无论过渡有多困难，您都认为值得。但是，如何跟踪主要格式更改中的代码更改？您可以放弃并说“这是我们再次开始的地方”，也可以重新格式化整个存储库历史记录中的所有查询。 如果您正在使用像Git这样的分布式版本控制系统，则可以还原到有史以来的第一次提交，然后从那里重新格式化为当前状态。但这是一项艰巨的工作，其他所有人都必须在工作进行期间暂停工作（或为所有合并的母亲做好准备）。有没有更好的方法可以更改历史记录，从而获得最好的结果： 所有提交中的样式相同 最少的合并工作 ？ 需要澄清的是，这与启动项目时的最佳实践无关，而是在大型重构被视为Good Thing™却又想获得可追溯的历史时应该怎么做？如果这是确保您的版本始终保持相同工作的唯一方法，则永远不要重写历史记录，这是伟大的，但是对于开发人员而言，全新重写的好处是什么？特别是如果您有方法（测试，语法定义或编译后的相同二进制文件）可以确保重写后的版本与原始版本完全一样？
5
我们应该在线托管代码吗？
我们正在我的工作场所中寻找良好的源代码控制和项目管理解决方案，我建议创建一个GitHub组织和私有存储库。我之所以喜欢GitHub有很多原因，但这并不是关于GitHub的事实（事实上，我的同事们会提出支持竞争平台的观点），而是关于在线存储我们的私有代码。 我试图了解这是否是一个好主意。这显然是有优势的，因为它消除了服务器成本（至少直接），并且使代码搜索（所有内容都在线）更加容易。 但是我们的团队还没有定论，这使我想到我的问题，为了做出这个决定，我们应该考虑什么？
2
在VCS中存储软件版本号是一种好习惯吗？
产品版本（例如）v1.0.0.100不仅代表软件的唯一生产版本，而且还有助于识别该产品的功能集和修补程序阶段。现在，我看到两种方法来维护产品的最终程序包/内部版本/二进制版本： 版本控制。一个文件存储着版本号。持续集成（CI）构建服务器将具有脚本来构建软件，该脚本使用此签入的版本号将其应用于所需的软件的所有区域（二进制文件，安装程序包，帮助页面，文档等）。 环境和/或构建参数。这些在版本控制之外进行维护（即，它们不依赖于快照/标签/分支）。构建脚本以相同的方式分配和使用数字，但是它们只是以不同的方式获取值（将其提供给构建脚本，而不是让脚本知道相对于源树在何处获取该值）。 第一种方法的问题在于，它会使跨主线分支的合并变得复杂。如果您仍然维护同一软件的2个并行发行版，并且自上次合并以来两个主版本的版本均已更改，则将在合并两个主干之间时解决冲突。 第二种方法的问题是和解。回到1年前的发行版时，您将仅依靠标签信息来标识其发行版号。 在这两种情况下，版本号的某些方面可能在CI生成之前是未知的。例如，CI构建可能会以编程方式放入第4个组件，该组件实际上是自动构建编号（例如，分支上的第140个构建）。它也可能是VCS中的修订号。 跟上软件版本号的最佳方法是什么？是否应始终在VCS中维护“已知”部分？如果是这样，主线分支之间的冲突是否成为问题？ 现在，我们通过CI构建计划（Atlassian Bamboo）中指定和维护的参数来维护版本号。在合并到我们的master分支机构之前，我们必须小心一点，即在开始构建CI之前已正确设置了版本号。关于Gitflow工作流程，我认为，如果在源代码管理中跟踪了版本号，我们可以保证在创建release分支以准备发布时正确设置了版本号。质量检查人员将在该分支机构上执行最终的集成/烟熏/回归测试，并在签收后进行合并，master这表示发布承诺。
5
仅在本地计算机上使用git是否合理？[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 仅在本地使用git可以吗？我不想为提供私有存储库的服务付费（例如Github），但我认为git是组织我的封闭源代码项目的好方法。
6
仍然使用Subversion的特定原因？[关闭]
按照目前的情况，这个问题不适合我们的问答形式。我们希望答案会得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 7年前关闭。 我想为我的公司选择一个版本控制系统。到目前为止，我知道我有Git，Subversion和Mercurial。 这些天来，我发现Git是最常用的，所以我不禁要问：仍然有任何特定的原因仍然需要使用Subversion，还是应该直接使用Git？
8
为什么源代码控制系统仍大多以文件为后盾？
似乎更多的源代码控制系统仍将文件用作存储版本数据的手段。Vault和TFS使用Sql Server作为它们的数据存储，我认为这对于数据一致性和速度会更好。 因此，为什么SVN，我相信GIT，CVS等仍然将文件系统用作本质上的数据库（我问这个问题，因为我们的SVN服务器只是在正常提交期间损坏了自己），而不是使用实际的数据库软件（ MSSQL，Oracle，Postgre等）？ 编辑：我想问我的问题的另一种方式是“为什么VCS开发人员推出自己的结构化数据存储系统而不使用现有的结构化数据存储系统？”
6
如何鼓励采用版本控制
我最近开始在没有版本控制的团队中工作。大多数团队成员都不习惯任何版本控制。我一直在私下使用Mercury跟踪我的工作。我想鼓励其他人采用它，并且至少在开发变更时开始对他们的代码进行版本控制。任何人都可以给我一些建议，以鼓励我采用诸如Mercurial这样的分布式版本控制。任何有关如何赢得包括DVCS经理在内的人员的建议，将不胜感激。
13
仅针对生产代码的Subversion /源代码控制？
我一年前毕业于计算机科学学院，现在在一家小型Web开发公司（我和另一个开发人员，加上经理，客户服务和测试人员）工作。直到我开始之前，还没有源代码控制系统。我们现在正在缓慢地开始实现SVN，但是另一位（高级）开发人员（此后称为Joe）坚持认为，应该提交给我们的SVN存储库的唯一代码是经过测试并被批准可以投入生产的代码。这意味着，在较大的项目中，可能一次甚至几周都没有提交。 这是正常的做法吗？在我看来，我们失去了很多源代码控制的好处，包括： 细粒度跟踪项目进度 跟踪出现和解决的问题 轻松回滚错误 轻松备份代码，因此如果工作站发生故障，我们也不会损失太多 更容易识别到底是什么代码运行在生产基地，假设我们盖章的版本到可执行文件所描述的在这里 轻松的协作（尽管我们不做任何团队合作；这都是个项目） 等等。 编辑：我应该强调，从历史上看，这家公司没有真正的团队合作；只有两个开发人员从事不同的项目。另外，许多项目规模很小，因此可以在几周内完成。该公司已经经营了十多年，并且在没有源代码控制的情况下相处得很好。项目通常在其估计的时间范围内完成。
4
处理长期项目的产品版本控制和分支的最佳方法是什么？
一般而言，对于在产品生命周期中可能有多个版本并且需要先前产品支持的长期项目，处理产品版本和代码分支的最佳方法是什么？ 从更具体的意义上说，假设适当的分布式版本控制在位（即git），并且团队的大小由小到大，并且开发人员可能同时从事多个项目。面临的主要问题是，有合同义务支持当时存在的旧版本，这意味着新开发无法修补旧代码（Microsoft Office产品可能就是其中的一个示例，您只能获得针对您拥有的功能年份）。 结果，当前的产品版本控制令人费解，因为每个主要产品都具有多个依赖项，每个依赖项都有其自己的版本，这些版本可能会在年度版本之间发生变化。同样，尽管每个产品都有其自己的存储库，但大部分工作不是在主要源主干上完成，而是在该年产品发布的分支上完成，而在发布产品时将创建一个新的分支，以便对其进行支持。反过来，这意味着获得产品的代码库并非易事，因为使用版本控制时可能会想到。
4
如何组织个人Git存储库？
我正在建立一个GitHub帐户，并计划将我作为一些近期iOS项目的一部分开发的库免费提供给其他iOS开发人员使用。 我目前大部分代码都没有异地备份，因此，我最初以为我会将所有个人项目或至少所有iOS项目上载到私有GitHub托管的存储库中。但是，我有很多项目，其中很多都是低价值的（即从书本改写而来的学习经验）。GitHub不仅由私有存储库收取费用，而且似乎没有任何分层组织存储库的方法。 我是否缺少某些东西，可以让我使用具有层次结构的git存储库，并在需要时/根据我目前的SVN方式检出碎片？ GitHub（或像BitBucket这样的竞争对手）是否具有某些我缺少的项目组织功能？ 如果失败了，处理这种情况的普遍接受的“ Git方式”是什么（丢弃不打算发布的项目，将其离线存储，以某种方式将它们捆绑在一起，等等，等等）？ 据我所知，我的选择是： 将库放到GitHub上，继续为所有其他项目托管我自己的SVN，使用非VCS解决方案进行异地备份（崩溃）， 将我计划在GitHub上发布的库和软件（分别作为公共和私人版本）放置，继续为我不太关心的项目托管我自己的SVN，并且仅可能重新访问以刷新关于如何实现XYZ的记忆，决定如果我的房屋爆裂（双声），我愿意注销它们， 将所有内容放到[GitHub和/或BitBucket]上，通过搜索我需要的内容/在我的[GitHub和/或BitBucket]帐户中维护一些脱机指针集来处理一些可笑的存储库（三重问题）
6
传统团队使用分布式版本控制的头痛？
尽管我在个人项目中使用并喜欢DVCS，并且可以完全看出它如何使其他人对项目的贡献进行管理（例如，典型的Github方案），但对于“传统”团队而言，似乎存在一些问题。 TFS，Perforce等解决方案采用的集中式方法。（“传统”是指办公室中的一组开发人员在一个项目上工作，没有一个人“拥有”，可能每个人都在使用相同的代码。） 我已经预见了其中的几个问题，但请考虑其他因素。 在传统系统中，当您尝试将更改签入服务器时，如果以前有人签入了冲突的更改，则您将被迫合并，然后才能签入。在DVCS模型中，每个开发人员都会签入他们的证书。本地更改，并在某个时候推送到其他回购。然后，该仓库中有一个由2个人更改的文件分支。看来现在必须由某人负责处理这种情况。团队中的指定人员可能没有足够的整个代码库知识，无法处理所有冲突。因此，现在增加了一个额外的步骤，即有人必须与这些开发人员之一联系，告诉他进行合并并再次推送（或者您必须构建一个自动化该任务的基础结构）。 此外，由于DVCS倾向于使本地工作变得如此便捷，因此开发人员很可能会在推送之前在其本地存储库中积累一些更改，从而使此类冲突更加常见和更加复杂。 显然，如果团队中的每个人都只在代码的不同区域工作，这不是问题。但是我很好奇每个人都在使用相同代码的情况。集中式模型似乎迫使人们快速而频繁地处理冲突，从而最大程度地减少了进行大型痛苦合并或让任何人“警惕”主仓库的需求。 因此，对于与办公室中的团队一起使用DVCS的那些人，您将如何处理此类情况？您是否发现您的日常（或更可能是每周）工作流程受到负面影响？在工作场所推荐DVCS之前，我还有其他注意事项吗？
7
每日构建的重要性如何？[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 乔尔测试的标准之一是日常构建。想法是，如果构建已损坏，则无论谁破坏了它，都可以修复它。如果无法修复该版本，则每个人都必须签出旧版本并进行处理。我可以理解，这对于集中式版本控制而言可能是非常糟糕的，在集中式版本控制中，尽可能避免合并和分支很重要，但这听起来像是分布式版本控制的一个小麻烦。你同意吗？还有其他原因使每日构建很重要吗？
2
在git中，创建与已删除分支同名的标记是个坏主意吗？
我有一个带有git分支模型的项目，该模型大致遵循nvie的git-flow的模型。 我们的发行分支以SemVer格式命名，例如v1.5.2 一旦发布分支允许生产，我们就关闭该分支，方法是将其合并到master中，应用标签，然后删除该分支。 当我们立即删除发布分支时，我们一直在使用相同的标识符来标记分支，例如 v1.5.2 这是我们用于关闭发布分支的命令： $ git checkout master $ git merge v1.5.2 $ git tag -a v1.5.2 -m "Version 1.5.2 - foo bar, baz, etc" $ git branch -d v1.5.2 $ git branch -dr origin/v1.5.2 $ git push origin :v1.5.2 $ git push $ git push --tags 这似乎在大多数情况下都可行，但是在git …
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.