Questions tagged «version-control»

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

2
大项目布局：在多个子项目上添加新功能
我想知道如何使用版本控制管理系统来管理具有许多组件的大型项目。 在我当前的项目中，有四个主要部分。 网页 服务器 管理控制台 平台。 Web和服务器部分使用了我编写的2个库。总共有5个git存储库和1个mercurial存储库。项目构建脚本位于平台存储库中。它使整个构建过程自动化。 问题是当我添加一个会影响多个组件的新功能时，我必须为每个受影响的存储库创建分支。实施功能。合并回去。我的直觉是“出事了”。 那么我应该创建一个单一的仓库，并将所有组件放置在那里吗？我认为在这种情况下分支会更容易。或者我只是做我现在正在做的事情。在那种情况下，我该如何解决在每个存储库上创建分支的问题？
5
如何最好地管理公司机密研究代码的开放源代码发布？
我公司（简称为Acme Technology）拥有大约一千个源文件库，这些文件最初来自其Acme Labs研究小组，在一个开发小组中孵化了几年，最近已提供给少数客户。非公开。Acme已准备好向开源社区发布大约75％的代码。其余25％将在以后发布，但是目前，要么尚未准备好供客户使用，要么包含与未来创新相关的代码，他们需要将这些创新保持在竞争对手的控制之下。 目前，该代码已使用#ifdefs格式化，该代码库允许相同的代码库与预生产平台一起使用，一旦开源，该研究平台将可供大学研究人员和更广泛的商业客户使用，同时可用于实验和原型设计以及与未来平台的向前兼容性测试。对于我们小组的经济（和理智）而言，保持单一代码库被认为是至关重要的，因为他们很难同时维护两个副本。 当前库中的文件如下所示： > // Copyright 2012 (C) Acme Technology, All Rights Reserved. > // Very large, often varied and restrictive copyright license in English and French, > // sometimes also embedded in make files and shell scripts with varied > // comment styles. > > > ... …
2
一个产品的不错的git分支模型，该模型应该与另一个第三方产品的版本（以及一个建议的优缺点）一起提供
注意： 我的问题集中在我的特定问题（涉及Liferay）上，但是我希望它对需要在git上维护同一项目的各种版本的人有用。 我在一家为Liferay Portal编写很多插件的公司工作。这些插件（portlet，主题等）通常是可重用的，当然，应该为门户的新版本进行更新。 但是，通常必须将Portlet迁移到Liferay的新版本并维护其先前版本。同样，我们经常必须为某些客户端创建非常特定的自定义，将其添加到“主版本”中没有意义。 这些要求使我们的工作复杂化，但是幸运的是，我们可以进行一些简化。例如，一次只能由一位程序员频繁更新插件。同时在插件中添加两个或多个功能的情况很少见。 现在，我们正在迁移到Gitorious。我们正在尝试为这种情况设想一个分支模型。 我的模特 我建议的是： 每个插件在项目内部的Gitorious中都有自己的存储库。例如，用于显示小猫的portlet将kittens-portlet在liferay-portlets项目内部具有一个存储库。 创建新插件时，请在根据Liferay版本命名的分支（例如lf5.2）上创建它。 每次对插件进行更新时，都会批准该更新并将其部署到生产环境中，并用一个版本（例如lf5.2v1，lf5.2v2等）标记该插件* 每次将插件移植到Liferay的新版本时，我们都会分支最新版本（例如，创建branch lf6.0）。 一旦投入生产，新分支的负责人将收到诸如的标签lf6.0v1。 每次我们必须以客户端特定的方式自定义插件时，都会使用客户端名称创建一个分支（例如，我们将为lf5.2clientcorp客户端“ ClientCorp Inc.” 创建一个分支）。 这是一个不寻常的模型：它没有master分支并且没有很多分支。这就是我假设具有这种模型的存储库的样子： 一位朋友发现此系统相当复杂且容易出错。他提出了出色且受欢迎的Vincent Driessen模型，我发现该模型仍然难以管理和严格遵守纪律。当然，它很棒（并经过测试！），但对于我们的情况似乎太复杂了。 我朋友的模特 然后，他提出了另一种模型：我们将为Liferay版本中的每个插件提供一个存储库（因此，我们将开始创建kittens-lf5.2-portlet，然后再创建kittens-lf6.0-portlet），每个插件都有一个master分支和一个develop分支。该master会随时进行部署。（或者，master和Steve Loshstable所建议的相反）。 这很简单，但是我不喜欢这个系统： 它可能会在一个项目中导致大量的存储库，从而使Gitorious难以浏览。 项目目录的名称是相关的。如果有人将存储库克隆到kittens-lf6.0-portlet目录并使用ant生成WAR（通常），则WAR名称也将是kittens-lf6.0-portlet。kittens-portlet在升级的门户网站中，此portlet的旧版本（例如命名）将被视为不同的portlet（并且可能会丢失）。稍加注意可以避免它，但我宁愿避免它。 同一插件的不同版本将分开维护。我伤了我的心:( kittens-lf6.0-portlet 我认为，这是存储库的丑陋名称。 我怀疑最后两个要点-也是两个更主观的要点-是我不愿意的主要原因。尽管如此，所有四个反对意见仍然成立。 太太，我自己的建议对我自己来说似乎很奇怪，我想知道上面是否有隐藏的错误。OT3rdH git非常强大和灵活，我认为探索它的可能性不应该感到羞耻。 所以，我问： 最好的模型是什么？我的建议？我朋友的模特？现在是传统的Vincent Driessen系统？ 您还建议其他什么分支模型？ 如果您认为我的模型不好，为什么会这样呢？我很想了解缺点和盲点。 *实际上，我更喜欢用这样的版本标记提交，例如，v1但显然git中的标记不在分支范围内-也就是说，我不能在其中添加1 v1标记，lf5.2而在其中另一个标记lf6.0-因此我必须命名科。它是正确的BTW吗？
6
SVN使用不佳-Mercurial是答案吗？
在工作中，我们使用SVN，但仅是名称。我们不分支或合并。我们保留该存储库的两个副本，其中一个充当“标签”分支，在进行部署时会被复制，并保留用于错误修复和立即“必须尽快上线”的功能。我们必须记住将一个副本中所做的更改复制到另一副本（“主干”）中。我们在存储库中的一个文件夹中有十二个项目，而不是将它们分开。简而言之，我们使用SVN的唯一目的就是能够提交。其他所有操作都是手动完成的。 我一直在评估Mercurial；我过去曾经使用过Git（我是团队中唯一使用过DVCS的人），而且我正在迅速接手Mercurial。我正在讨论将Mercurial作为一种“更好的做事方式”介绍给团队的其他成员，因为分支很容易，合并更容易，而且我们可以将内容本地化为我们的核心内容，而只将它们推送到中心准备好后分支。我们将获得SVN的所有好处（而且由于没有人真正了解SVN，我们现在并没有得到太多好处），而且对于新功能，我们不必拥有大量未版本化的文件，因此，如果我们必须回滚我们搞砸了。工作流程似乎更简单-我们只需要记住“ Commit”是本地的，“ Push”就像SVN的提交， 这是一个好方法吗？请记住，团队非常灵活，将与一切能够改善我们的工作质量并使我们的工作变得更轻松的事情一起工作-CIO甚至问我，当我提到我们不充分利用SVN的潜力时，有更好的东西可以使用吗？” 所以他也同意。
5
解决由于重构引起的合并冲突
最近，我参与了有关如何处理重构的讨论（这本身就是一个有趣的话题）。最终提出了以下问题： 一个人如何处理由于某人对一部分代码进行重构而其他人在为同一段代码开发功能时发生的合并冲突呢？ 基本上，我不知道如何有效地处理这一问题。在这方面是否应遵循任何最佳做法？对于具有大量旧代码的系统，应该如何处理呢？
15
在没有源代码控制的情况下与多人一起开发应用程序的最有效/最有效的方法是什么？
我的情况简介 我在一家小型Web开发公司工作。我们有一个由四个ASP.NET开发人员组成的团队，其中包括我。我们几乎所有项目（> 98％）都是一个人的项目，大约需要1-4周才能完成。我们不使用源代码或版本控制。我们唯一拥有的是本地服务器上的共享文件夹，其中包含所有项目的最新源（==实时应用程序的源）。 在极少数情况下，我们确实需要与一个以上的人一起从事同一个项目，我们使用...超越比较。开发人员每天一两次询问彼此是否有可编译的版本，然后使用Beyond Compare同步其代码。当只有两个人在一个项目上工作时，这“相当好”，但是一旦第三个开发人员进入流程，它就变成了难以处理的垃圾。尤其是当每个人都开始对数据库进行更改时。 我（和我的一两个开发人员）已经多次告诉我的老板，我们应该开始使用某种形式的源代码和版本控制，例如Git，Mercurial或TFS（我们的老板非常注重Microsoft）。不幸的是，我的老板没有看到切换到源代码和版本控制系统的优势，因为在他看来，现在一切都很好，并且他不想花费时间和金钱来建立新系统并确保每个人都知道如何使用它。即使在我向他解释了优点（例如简化的协作，应用程序的不同版本，更安全的代码更改方式……）之后，他仍然不认为这是我们所需要的。 在这四个开发人员中，只有两个（包括我在内）具有源代码控制（Git）的经验。而且这种经验非常有限。我知道如何将Github存储库克隆到我的计算机上，进行一些更改，提交它们并将其推回到Github。而已。 我的问题/担忧的解释 几周后，我们将开始为我们的标准开展一个相当大的项目。可能需要2-3个开发人员几个月才能完成。我将担任项目负责人（项目经理和首席开发人员），我将负责所有工作。我在使用“超越比较”方法时遇到了很多问题，并且我不想走这个大项目，这是我的责任。 由于我怀疑我们是否能够 设置我们自己的Git服务器， 教大家与Git合作 在这个大项目中成功雇用了Git， 我很感兴趣，如果你们中有人知道一些允许多人在不使用源代码或版本控制的情况下就同一项目进行协作的好方法。 更新资料 我要感谢大家的回答和评论。这是计划： 与开发人员举行会议，以确保所有技术人员对实现源代码控制的感觉相同。当所有人都支持时，我们会提出一个更强的观点。 向老板介绍这个想法，并告诉他我们确实需要源代码控制。 尽快实施。
7
吸引非程序员（例如设计师）使用版本控制的简便方法？
使团队参与开发，Web开发或其他过程中使用版本控制的一些主要方法是什么？ 我拒绝没有它的工作，这意味着参与该项目的任何人也必须使用它。这只是个好习惯。 像Tower这样的GUI有所帮助，但是它的概念要么激怒（“不是我的工作！”，有点怯，），要么胆怯，或者直接不使用它（改用FTP，绕开了诸如开发，部署之类的版本控制） ）。 编辑：我应该澄清一点，我不仅仅是指图像/ PSD。
8
小团队的版本控制[关闭]
已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 5年前关闭。 我们正在引导一个非常小的团队（例如2-5），我的问题是：哪种类型的版本控制最适合集中式或分布式的这类团队。
4
将多GB SVN存储库移至Git
当前，我的公司在SVN存储库中具有Visual Studio隔离，其组织如下： SolutionFolder (~3.5 GB) |-> SolutionName.sln |-> .. Some source code folders... (~250 MB) |-> ThirdParty (~3 GB) |-> Tools | -> Tool1 | -> Tool2 Tool1和Tool2是独立构建的（具有自己的解决方案），但是会生成在主要构建中使用的可执行文件。ThirdParty文件夹包含项目的所有依赖项，包括一些预编译的100+ MB .lib文件和大型库（如boost）。 将所有功能都包含在一个SVN存储库中非常方便，这样（1）开发人员只需执行一次签出操作，（2）我们就无需跟踪每个版本的构建所需的依赖项版本。另一方面，要花些时间检查此仓库。 将这个项目结构转移到git的最佳方法是什么？大概最好是从主存储库中排除ThirdParty以及可能的工具，但是我们希望一步就可以轻松下载ThirdParty，并且我们希望对其进行版本控制（并且主存储库和ThirdParty / Tools之间的版本不匹配会很糟糕）。 在这一点上，我对保存历史不感兴趣，只是对如何组织这样的项目不感兴趣。
1
共享部分monorepo
当前，我们有一个复杂而效率低下的构建系统，其中包含许多SVN和Git存储库（每个约50％），其中包括一个git子模块存储库。我们也有自制脚本，可以或多或少地管理整个事情。 我们的（封闭源代码）代码库的一个主要要点是紧密耦合，并且每个项目都在同一版本下同时发布。 我们希望将其迁移到更简单的系统和单个VCS，并正在考虑几个选项，包括：git子模块，google repo和monorepos。最终的VCS尚未定义（强制使用的选项除外），并且如果更适合我们的情况，则可以是svn，git甚至其他名称。 我们试图列出每种解决方案的优缺点，而monorepos当前面临的主要问题之一是，这似乎并不容易，甚至可能只与外部实体共享某些模块。我们希望这些人员能够检出并在这些模块上正常工作，但不能访问回购其余部分的代码或历史记录。目前，这不是我们经常或广泛进行的事情，但将来可能会发生，并且我们不希望这成为噩梦，因为我们在这里做出了错误的决定。 VCS系统中是否存在这样的特权管理系统？ 还是有什么办法可以减轻这个问题？
2
使用gitignore连续部署
使用Git进行连续部署时，如何处理gitignore中被忽略的文件？这些文件出于隐私原因而被忽略（即，不希望它们被推送到其他远程存储库，例如GitHub），但是由于这些被忽略的文件没有被推送到连续部署存储库中，因此它们的应用程序将无法运行（因为被忽略的文件是该软件才能正常运行。 人们通常如何做到这一点？在这种情况下，由于文件被忽略，Git是否不是连续部署的最佳选择？
2
工作流程，编辑当前任务中没有的内容
通常，当我编程时，我要完成一个明确的任务，但是会发现我想继续进行的烦人的事情要清理。 在这里，我看到三个选项： 以后再做（可能会忘记/不得不花费时间添加票证） 现在就做，并将其与我当前的工作一起提交（不清楚） 现在执行并分别提交（必须找到它，可能会犯一个错误，无意中选择了选项2） 这可能是相当基本的，但是有什么方法可以使用svn / git / other来规避呢？
4
阻止开发人员在DVCS上提交错误的分支
问题 我在一个大约有10个开发人员的软件项目中，我们通过Mercurial共享源代码。每个版本都有一个开发和生产分支。在项目进行过程中，我们反复从一个分支（即v1）获取源代码，以进入补丁和维护分支以获取早期版本的软件（即v2）。 如果我们没有注意到代码进入错误的分支，则这将导致花费时间来撤消错误的提交，或者导致错误的代码（可能是非QAd）到达并部署在错误的分支中。 我们的分支和合并设计/方法 v1-test v1-patch1 v1-patch2 ^---------^-----------^ v1-prod / / \ \ -----------------------/ \ \ v1-dev \ \ \ --------------------------\ v2-dev \ \ \ ^-------^------------- v2-prod v2-test v2-patch1 因此，我们将在发布开发分支上工作，直到它准备就绪为止，然后将其分支到一个测试/ UAT /生产分支，在此完成所有发布和维护。标签用于构建该分支的发行版。在测试v1时，将为v2建立一个分支，并且开发人员将开始开发新功能。 趋于发生的事情是，开发人员将由于v2-dev分支而提交的工作提交到v1-dev或v1-prod中，或更糟糕的是，他们将v2-dev合并到v1-prod中（或类似的错误）。 我们告诉大多数开发人员不要访问-prod分支，但是代码仍然会潜入。一组更高级的开发人员“照看” -prod分支。 应该注意的是，尽管v2才刚刚开始开发，但v1中可能仍然有一些相当大的补丁程序可以解决问题。即v1可能不仅获得了奇怪的小补丁。 到目前为止我们尝试过的 有一个单独的-prod分支，带有网守。-prod分支应通过其名称发出警告，并且大多数开发人员不必永远都位于该分支中。这并没有真正减轻问题。 在开发人员中提高了对此问题的意识，以使他们更加警惕。再次，这不是很成功。 我认为开发人员承诺使用错误分支的可能原因 过于复杂的分支机构设计 在多个分支并行发展中。（该项目确实表现出使用雪崩模型的症状。） 开发人员对DVCS的了解不够充分 我读过的与某些问题相关的问题 我读过这个问题上不承诺到错误的分支，我觉得对于视觉线索的答案可能会有所帮助。但是，我并不完全相信，我们所遇到的问题不是更根本问题的征兆。 通过视觉线索，我们可以轻松地将它们合并到命令行中，但是大约有一半的团队使用Eclipse，我不确定如何合并视觉线索。 题 我们可以使用什么方法，以软件，项目管理或治理的形式来减少（理想地停止）错误的分支，从而占用我们的时间或弄脏我们已部署的代码？ 对于我认为可能会做出上述贡献的原因的具体评论，将不胜感激，但这不应该限制您的答复。
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.