Questions tagged «dvcs»

我试图了解分布式版本控制系统（DVCS）的好处。 我发现颠覆再教育和本文由马丁·福勒是非常有用的。 Mercurial和其他DVCS促进了使用变更集和本地提交的代码处理新方法。它防止合并地狱和其他协作问题 我们不受此影响，因为我练习持续集成，除非在进行实验，否则不能在私有分支中单独工作。我们为每个主要版本使用一个分支，其中修复了从主干合并的错误。 水星让你有中尉 我知道这对于像Linux这样的大型项目很有用，但是我看不到小型且高度协作的团队（5至7人）的价值。 Mercurial更快，占用磁盘空间更少，完整的本地副本允许更快的日志和差异操作。 我也不对此感到担心，因为即使我正在处理非常大的项目，我也没有注意到SVN的速度或空间问题。 我正在寻找您的个人经验和/或前SVN怪才的意见。特别是关于变更集的概念和整体性能的提高。 更新（1月12日）：我坚信值得尝试。 更新（6月12日）：我亲吻了Mercurial，我很喜欢。他的樱桃当地风味的味道。我亲吻Mercurial只是为了尝试。我希望我的SVN服务器不要介意。感觉很不对劲。感觉很好。并不是说我今晚恋爱了。 最终更新（7月29日）：我荣幸地复习了Eric Sink的下一本书，名为“ 版本控制示例”。他说服了我。我去Mercurial。

300 version-control  git  mercurial  dvcs  svn 

我知道提供DVCS浏览和管理的几种工具/服务，例如Bitbucket，Github，Kiln，SCM-Manager和Rhodecode。 但是，我正在考虑的用例是这样的： 任何源代码都必须位于雇主内部服务器上。 解决方案必须是开源的。 它应提供类似Bitbucket或Github的体验，包括项目Wiki，存储库浏览和管理以及社交编码方面（如代码审查）。 该解决方案应具有丰富的支持（如果不支持其他DVCS）。 其中只有SCM-Manager和RhodeCode可以接近，因为它们可以安装在您自己的服务器上并且是开源的。但是他们没有Bitbucket或Github经验。没有问题跟踪器或Wiki，并且用户界面虽然功能正常，但与Github或Bitbucket不相称。 我可以通过他们的存储库浏览器来接近Trac或Redmine，但不幸的是它们没有任何存储库管理功能。 是否有其他开源工具可以提供与Bitbucket，Github或Kiln类似的体验？

68 open-source  web-applications  dvcs  free-software 

使用DVCS的优点之一是编辑提交合并工作流（通常由CVCS强制执行的编辑合并提交工作）。允许将每个唯一更改记录在与合并无关的存储库中，可确保DAG准确反映项目的真实血统书。 为什么这么多网站谈论要“避免合并提交”？合并合并前合并或合并后合并是否会使隔离回归，还原过去的更改等变得更加困难？ 澄清点： DVCS的默认行为是创建合并提交。为什么有那么多地方谈论看到隐藏这些合并提交的线性开发历史的愿望？

67 version-control  git  dvcs  merging 

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

38 version-control  git  dvcs 

假设有一个由十个敏捷开发人员组成的团队。每天他们每个人都从董事会中挑选一项任务，并对它做出一些更改，直到（直到一天结束）他们已经完成了任务。所有开发人员都直接通过主干签入（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 

可能重复： 我是Subversion极客，为什么我应该考虑或不考虑Mercurial或Git或任何其他DVCS？ 有时，您会听到有人说分布式版本控制（Git，HG）本质上比集中版本控制（如SVN）更好，因为在SVN中合并非常困难且痛苦。关键是，我在合并SVN方面从未遇到任何麻烦，并且由于您只听说过DVCS倡导者而非实际SVN用户提出的主张，所以这往往使我想起电视上那些令人讨厌的广告，试图让演员冒充假装您已经拥有并且可以正常工作的东西很难卖给您，从而卖给您不需要的东西。 总是提出的用例是重新合并一个分支，这再次使我想起那些稻草人产品广告；如果您知道自己在做什么，则一开始就不应该（也永远不必）重新合并分支。（当然，当您从根本上做错和愚蠢的事情时，这很难做到！） 因此，撇开荒谬的稻草人用例，SVN合并中有什么比DVCS系统中合并更难？

28 git  svn  mercurial  dvcs  merging 

我一直都同意Mercurial的口头禅1，但是，既然Mercurial与rebase扩展捆绑在一起，并且它是git中的流行做法，我想知道它是否真的可以被视为“不良做法”，或者至少足以避免使用。无论如何，我都知道在推送之后重新部署基地很危险。 OTOH，我认为尝试将5个提交打包到一个文件中以使其看起来更整洁（尤其是在生产分支中）的意义，但是，我个人认为能够对部分功能进行部分提交会更好一些实验已经完成，即使它不是很漂亮，但是看到类似“尝试用X来做，但毕竟不如Y，以Y为基数做Z”这样的内容，恕我直言对那些学习的人来说具有很好的价值。代码库，并遵循开发人员的思路。 我非常自以为是（愚蠢，内脏，有偏见）的观点是，程序员喜欢重新设置基础以隐藏错误……而且我认为这根本不适合该项目。 所以我的问题是：您是否真的发现在实践中拥有这样的“有机提交”（即不受干扰的历史记录）很有价值？或者相反，您是否更喜欢遇到包装精美的提交，而无视程序员的实验过程？无论您选择哪个，为什么对您有用？（让其他团队成员保留历史记录，或者根据需要重新建立历史记录）。 根据Google DVCS分析的1，在Mercurial“历史为神圣”中。

26 git  mercurial  dvcs 

我搜索了git / mercurial / bazzr系统，使其优于集中式系统（subversion，perforce），但没有找到任何商业原因。 如果您试图将DVCS出售给非技术人员，您会为DVCS 增加利润提供哪些论点。 我将很快向我的经理介绍git，这将需要一些时间来转换出Subversion存储库，并花费一些费用来购买smartgit许可证。 编辑我试图使这个问题成为关于集中式与分散式的一般性讨论，但是不可避免地它变成了git vs subversion。当然，有比颠覆更好的集中式系统。

26 version-control  mercurial  dvcs  svn  git 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 5年前关闭。 看过我是Subversion极客之后，为什么我应该考虑还是不考虑Mercurial或Git或任何其他DVCS。 我有一个相关的后续问题。我阅读了该问题，并阅读了推荐的链接和视频，我看到了好处，但是我没有看到人们在谈论的整体思维转变。 我们的团队由8至10名开发人员组成，他们在一个由60个项目组成的大型代码库中工作。我们使用Subversion并有一个主干。当开发人员启动新的Fogbugz案例时，他们将创建一个svn分支，在该分支上进行工作，完成后，它们将合并回主干。有时它们可​​能会在分支上停留更长的时间，并将中继合并到分支以接收更改。 当我看着Linus谈论人们创建分支而不再做分支时，那根本不是我们。我们每周可能会创建50-100个分支，而不会出现任何问题。最大的挑战是合并，但我们在合并方面也相当出色。我倾向于通过fogbugz case＆checkin合并，而不是合并分支的整个根。 我们永远不会在远程工作，我们永远不会在分支机构之外建立分支机构。如果您是代码库中该部分中唯一的工作人员，则与主干的合并将顺利进行。如果其他人修改了同一段代码，则合并可能会变得混乱，您可能需要进行一些手术。冲突就是冲突，除非有足够的智能来理解代码，否则我看不出大多数系统在大多数情况下如何做到正确。 创建分支后，接下来要检出60k +个文件会花费一些时间，但这对于我们使用的任何源代码控制系统都是一个问题。 我们没有看到的任何DVCS是否有一些好处对我们有很大帮助？

22 git  svn  mercurial  dvcs 

尽管我在个人项目中使用并喜欢DVCS，并且可以完全看出它如何使其他人对项目的贡献进行管理（例如，典型的Github方案），但对于“传统”团队而言，似乎存在一些问题。 TFS，Perforce等解决方案采用的集中式方法。（“传统”是指办公室中的一组开发人员在一个项目上工作，没有一个人“拥有”，可能每个人都在使用相同的代码。） 我已经预见了其中的几个问题，但请考虑其他因素。 在传统系统中，当您尝试将更改签入服务器时，如果以前有人签入了冲突的更改，则您将被迫合并，然后才能签入。在DVCS模型中，每个开发人员都会签入他们的证书。本地更改，并在某个时候推送到其他回购。然后，该仓库中有一个由2个人更改的文件分支。看来现在必须由某人负责处理这种情况。团队中的指定人员可能没有足够的整个代码库知识，无法处理所有冲突。因此，现在增加了一个额外的步骤，即有人必须与这些开发人员之一联系，告诉他进行合并并再次推送（或者您必须构建一个自动化该任务的基础结构）。 此外，由于DVCS倾向于使本地工作变得如此便捷，因此开发人员很可能会在推送之前在其本地存储库中积累一些更改，从而使此类冲突更加常见和更加复杂。 显然，如果团队中的每个人都只在代码的不同区域工作，这不是问题。但是我很好奇每个人都在使用相同代码的情况。集中式模型似乎迫使人们快速而频繁地处理冲突，从而最大程度地减少了进行大型痛苦合并或让任何人“警惕”主仓库的需求。 因此，对于与办公室中的团队一起使用DVCS的那些人，您将如何处理此类情况？您是否发现您的日常（或更可能是每周）工作流程受到负面影响？在工作场所推荐DVCS之前，我还有其他注意事项吗？

20 version-control  dvcs  team 

现在，我在服务器上使用visual svn，并在个人计算机上安装了ankhsvn / totoise。它可以正常工作，我不需要更改，但是如果我看到使用DVCS的一些好处，那么我可以尝试一下。 但是，如果在没有其他人的情况下使用它没有意义或不同，那么我不会打扰。 我再问一遍，当您是唯一的开发人员时，使用DVCS有什么好处吗？

19 version-control  dvcs 

我认为这篇文章《成功的Git分支模型》在经验丰富的DVCS用户中是众所周知的。 我hg主要使用它，但是我认为这种讨论对任何DVCS都适用。 我们当前的工作流程是每个开发人员克隆主存储库。我们在自己的本地仓库上编写代码，运行测试，如果一切顺利，则推送给主服务器。 因此，我们希望设置诸如Jenkins的CI服务器，并通过将来的预配系统（厨师，木偶，ansible等）改善我们的工作流程。 实部 好了，以上介绍的模型很好用，但分支机构可以破坏CI。Feature分支应该与原点同步（根据文章，它将是development分支），以使CI和合并更加顺利，对吗？ 说爱丽丝和鲍勃正在研究两个功能。但是爱丽丝第二天就完成了。鲍勃的功能需要一个星期。到Bob完成时，他的更改已过期（也许Alice重构/重命名了某些类）。 一种解决方案是，每天早晨开发人员必须master/origin检查是否有任何更改。如果Alice提交了，Bob应该拉入并合并到他的工作区中，以便他的功能分支是最新的。 这是个好方法吗？ 这些分支是否应该存在于主存储库中（不是本地克隆？），这意味着每个开发人员都应向GitHub / Bitbucket上的主存储库授予特权，以便他们可以创建新分支吗？还是在本地完成？ 最后，如果分支未与同步，则本文介绍的模型应打破CI origin/master。既然我们要进行夜间构建，开发人员是否应该在离开工作之前进行合并和合并，并且CI也要在每个功能分支上运行？

18 git  continuous-integration  mercurial  dvcs  branching 

我为什么要写一个提交消息？我不想，而且我认为它每次都很愚蠢。 我使用的GUI前端将不具名，它将迫使您执行此操作。即使他们在命令行上使用VCS，我每次都会听到其他人在这样做。 如果我每天提交几次，但是还没有完成功能，那我在写什么呢？我只有在多次提交后才写一条消息，我觉得是时候使用微型标签了，还是当我做一个实际的标签时。 我是对的还是我错过了什么？我也在使用分布式系统

18 dvcs  version-control 

我们是一家软件咨询公司，为不同客户提供大量项目。传统上我们使用Subversion，但目前正在考虑迁移到Git。 我们生成的文档中有很大一部分与客户共享（需求，全局设计，测试规范等），我们使用MS Office生成这些文档。在Subversion中，我们可以使用其“锁定”功能来确保没有人同时编辑同一文档。在Git中，您无法执行此操作，因为git具有分布式特性，因此它没有锁。 锁实际上只是一种通信机制，但它是一种非常有效的机制。 当前，我们的代码和面向客户的文档通常位于不同svn存储库的不同子文件夹中。转到git时，您会建议我们做什么？我看到了一组选项： 我们将svn存储库移至git 1-on-1。我们不使用Office文件上的锁，而是执行git人们建议的操作，并以某种方式尝试更改工作流以对其进行修复。这可以在任何文档编辑的分支中进行，然后将其合并到审阅中。这种方法突破了例如包含项目管理信息的Excel工作表；他们很容易被团队成员编辑（我们鼓励这样做），但不受任何正式审查程序的约束 我们将git用于代码，将svn用于文档和项目管理。这样做的缺点是，某些更多具有设计意义的文档不会“靠近”其指定的代码，从而增加了人们忘记更新它们的机会。此外，每个人都必须使用和理解两组工具。就是说，对于非面向客户的设计文档来说，这可能是转向基于文本的文档工具（胶乳，降价，HTML等）的绝佳机会。 与1类似，但我们修改了一个git lock命令，该命令执行svn lock对我们所做的事情（适当地切换了只读标志并通过某种方式与服务器同步）。 我不赞成在DVCS中锁不起作用的说法，因为系统甚至在您完全脱机时也可以工作。SVN锁也可以被覆盖。他们是一种沟通机制。没有某种类型的网络连接，您将无法使计算机进行大量通信。 我们不能成为唯一一个对svn lock我们的工作流程适应性非常满意的商店，对吗？ 有什么想法或提示吗？ 我找到了/programming/119444/locking-binary-files-using-git-version-control-system，但是讨论的内容是技术性的；我正在寻找解决或避免两个团队成员同时编辑同一二进制文件的实际问题的方法。

16 git  svn  dvcs  excel  word