Questions tagged «version-control»

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

1
构建脚本和构建服务器的职责
我需要对构建脚本和构建服务器的职责进行一些说明。 我在网上阅读了几篇有关持续集成和构建的文章。包含 F5密钥不是构建过程 构建服务器：项目的心脏监护仪 每日构建是您的朋友 我和我的顾问就软件的构建过程进行了交谈。因为他很有经验，所以我相信他的发言，但是我感到困惑。 据我了解，根据我的研究（由于这是我要提出的问题，请在此处对我进行纠正），理想应该如下： 每个项目都有其构建脚本 这个脚本建立了项目 该脚本确保依赖项是先前构建的 由于依赖关系可能是其他项目，因此使用自己的构建脚本会产生树状层次结构。可能会有一个顶级构建脚本来构建所有项目和应用程序。 但是，构建服务器的职责是： 签出仓库 触发构建 触发测试和其他质量检查工具 使工件可用 可以手动，每晚或每次存储库更改时触发 据我所知，我的顾问的目标是使一个构建脚本变得不灵活且不可维护（除了为我们的旧代码库创建一个构建脚本会花费很长时间的事实）。此外，构建服务器还应维护依赖关系，例如在创建新依赖关系时使用较旧的依赖关系。特别是Ant因为它是一个具体的主题，因此无法构建代码库中使用的所有各种技术，并且无法维护依赖性。 您能否详细说明目标并明确职责？
1
小型项目的Git工作流程/实践（PNG流程图）
我正在尝试提出一个个人工作流程。我整理了一个发行版的假设生命周期的流程图：一个开发人员推向公开的github repo +一个帮助提供某些功能并修复bug的朋友。 这是版本控制的合理方法吗？ 主要思想是保持公共仓库整洁： 每个新版本都会进入自己的分支，直到完成后最终在master分支中对其进行标记。 为了防止异常，所有工作都在“功能”或“修补程序”分支上进行，而不是在实际的发行分支上进行。 合并到更高级别的分支总是要重新设置基础或进行压缩（以避免混乱）。 如果这太过猛烈，我不介意，因为对我而言，重点就在于学习大型项目可能需要的技能。唯一的问题是，如果我在做完全错误或不必要的事情。 编辑2：修正原始流程图中的错误主意，并使它更易于浏览。
4
开发经理应如何处理代码“ Goal Tending”？
首先让我创造一个名词： 代码目标：早上检查代码，然后静静地检查其他开发人员前一天在文件中所做的所有更改（尤其是您最初开发的代码文件），并修复格式，逻辑，重命名变量，重构长方法等），然后将更改提交给VCS。 我已经确定了这种做法的优点和缺点： Pro：经常保持代码质量/可读性/一致性 Pro：由于其他开发人员对原始代码不太熟悉，因此已修复了一些错误。 缺点：经常是那些追求目标的开发人员的时间浪费。 缺点：偶尔会引入一些错误，这些错误会引起开发人员的愤怒，他们以为他们前一天编写了没有错误的代码。 骗局：其他开发人员对过多挑剔的行为感到恼火，并开始不喜欢为目标投标人的代码做出贡献。 免责声明：公平地说，我实际上不是开发经理，而是实际上正在执行“目标管理”的开发人员。 在我的辩护中，我认为这样做是有充分理由的（为了使我们的超大型代码库保持良好运转），但我非常担心它还会带来负面气氛。我也绝对担心我的经理将需要解决这个问题。 那么，如果您是经理，您将如何解决这个问题？ 更新：我并不是说这个问题太过本地化，但是有人问过，所以也许会有一些启发性的背景。三年前，我被分配了一个巨大的项目（200K LoC），直到最近（一年之前），该项目中才添加了其他开发人员，其中一些人不熟悉体系结构，其他人仍在学习该语言（C＃）。我通常必须回答产品的整体稳定性问题，当对代码库的核心体系结构部分进行令人惊讶的更改时，我尤其紧张。养成这种习惯的原因是，起初我对其他开发人员的贡献感到乐观，但是他们犯了太多错误，这些错误导致了严重的问题，直到几周后才发现。通常这些“
6
允许客户参与项目的最佳方法是什么？
我们一直在为客户建立CRM。既然第一个主要阶段已经完成，并且第二个阶段已经达成共识，那么客户希望承担一些工作，在我们构建第二个阶段的同时，对数据库模式和业务流程进行较小的修改。 我不确定这是否完全可行，但是假设是这样，我想指出一些指针，可以针对这些指标采取措施以使其完全可行。到目前为止，这是我得到的： 到目前为止，客户大多从用户的角度看项目。显然，应该分两部分进行讨论，向我们介绍内部工作原理： 首先，显示现有的数据库架构，并通过示例的方式对其进行扩展， 然后，显示一些示例代码，并为架构增强编写新的业务流程。 该代码当前位于内部Subversion存储库中。虽然我们可以在他的网络上建立一个或多个公共网络（我们可以通过VPN连接到它），但我觉得分布式系统会更好。但是，我似乎是唯一这样的人，因此我可以使用一些令人信服的论点。 我不确定如何授权/确保在生产环境中运行的代码已提交。好像“灾难发生之前，x进行了关键的，无记录的更改；现在y正在试图弄清楚此错误自此以来一直在发生”灾难是不可避免的。理想情况下，在部署之前，所有更改将： 在问题跟踪系统中记录下来， 首先在单独的测试环境中进行，并且 必须通过自动化测试。 las，我怀疑其中任何一种纪律都会盛行。 假定插件体系结构或单独的项目不是可行的选择，因为1）前者不存在，并且2）后者将禁止客户查看并可能修改现有代码，我相信他会坚持。
6
共享库的分支和版本控制策略
这些 帖子似乎相关，但是我的大脑开始融化，试图通过：P来思考 我的雇主刚刚开始使用源代码控制，主要是因为在雇用更多开发人员之前，“存储库”是唯一的开发人员的硬盘驱动器，该开发人员主要在家中工作。所有他写的.NET代码的检入集体，并有大量的重复（读：复制粘贴）功能。现在，我们的SCM系统是光荣的备份。 我想将某些重复的代码放入共享库中。我将单独保留原始存储库，以便我们不会破坏任何内容，我们可以在需要时移动和/或重构现有代码。因此，我为新代码（包括库）设置了一个仓库。 我的问题围绕着对库进行版本控制而没有过多的时间来烦恼我们：承认我们需要一种更一致的方法，更多的开发人员都编写非常相似的代码，管理人员和其他开发人员都愿意进行重组，但可能不会如果解决方案开始影响生产效率，则下降得很好。 在我的痴迷心中，理想的解决方案是分别构建库，而每个从属项目都是针对故意选择的兼容版本构建的。这样，我们就可以准确地知道哪些客户端具有哪个库的哪个版本，可以更可靠地重现错误，维护产品和库的独立发行分支，并且在更改共享代码时不会破坏彼此的项目。 但是，这使得更新库很麻烦，尤其是对于在家工作的开发人员而言。我希望这些库能快速变化，至少在最初（最终）将这些通用位组合在一起时会如此。我完全有可能对此进行全面考虑，并且可以根据最新的库提交构建所有内容，但我至少要做好准备，以便我们决定某些组件必须独立版本化并分散式。必须在GAC中安装某些库这一事实使得版本控制特别重要。 所以我的问题是：我想念什么？我觉得我已经专注于一种解决方案，现在正在尝试寻找可以使更改更平滑的变体。您以前使用过哪些策略来解决此类问题？我意识到这个问题无处不在。我会尽力清理并澄清所有不确定性点。 尽管我很想使用Mercurial，但我们已经在集中式商用SCM（Vault）上花了钱，并且切换不是一种选择。此外，我认为这里的问题比版本控制工具的选择更深。
4
为什么大型金融/保险公司应使用git和/或github
我为金融/保险行业的一家大型企业（雇员3万）工作。虽然“ IT”不是我们的主要重点，但老实说，这些都是信息驱动的行业，具有更好技术优势的公司似乎能更快地取得发展。 我公司有很多软件开发团队。它们遍布整个版本，具有版本控制功能，更不用说使用的语言/框架了。有些人不使用任何（我知道），一些人使用PVCS，一些人使用VSS，最开明的人使用SVN。 我想将git带入我的企业。更具体地说，我想引入GitHub（私有存储库）。我知道合适的人可以谈论这个话题，但老实说，由于诸如安全隐患或我们的竞争对手都没有使用它这样的大举动作，通常在大型企业环境中会被击落。仅引用jQuery，Ruby on Rails，Facebook等作为参考）。 所以我的问题是这个。大型企业为何应缓慢而有意识地从PVCS / VSS / SVN切换到托管git解决方案（如GitHub，私有仓库）的最令人信服的原因是什么。当然，我的计划的一部分涉及到一个不必要的开发项目的POC。
6
我们如何每隔一周在生产版本中仅包含准备发布的功能？
我是一个相当大的敏捷团队的软件开发人员（我们有8个开发人员积极地对单个代码存储库进行更改）。每隔两周，我们会将软件的新版本投入生产。这是我们当前的工作流程： 在开始新任务时，开发人员在主开发分支（我们使用git）的基础上创建一个“功能分支”，并在此新分支上工作 开发人员完成任务后，将其功能分支合并回开发分支 开发人员将开发分支合并到质量检查分支。 质量检查分支会触发构建。此构建的输出已部署到我们的QA环境中，以允许测试人员开始其测试。 对于我们的测试人员来说，发现这些已合并到QA分支中的新功能的问题很常见。这意味着在任何给定的时间，QA环境都可能包含一些新功能-一些经过测试且没有错误，还有一些已损坏。这使得发布变得困难，因为很少有QA版本处于生产就绪状态。 为了减轻这种情况，我们一直试图启动“质量检查冻结”，这意味着开发人员在发布前几天不会将我们的开发分支合并到质量检查分支中。质量检查环境的错误修复程序直接在质量检查分支中进行，并合并到开发分支中。从理论上讲，这使新的，已损坏的功能无法进入质量检查，同时仍使我们能够解决质量检查中已有的问题。 虽然“质量检查冻结”的概念已部分成功，但很难进行协调，人们常常对是否允许其合并到质量检查中感到困惑。设置“ QA冻结”截止日期也很困难-每个人都喜欢在冻结和发布之间留出一些喘息的想法，但是实际上，他们宁愿在下一个发行版中发挥自己的功能，也不愿遵守截止日期。 是否有更好的方法来确保我们每两周发布一次新版本？
2
多个团队的Git工作流程
我们将开始使用Git（尚未使用它），我想定义工作流程。 我们在全球4个不同地点拥有4个团队，共同开发同一产品。每个团队都拥有产品代码的一部分，但是有时他们也必须更改其他团队所拥有的代码。 是否有针对这种环境的Git工作流程的建议？ 我已经看过这篇文章，但是这里的方法是“我们尽可能少地创建其他分支”，并且我相信“为每个用户故事分支”方法更多。 另外，本文提出了一种不错的方法。 我想到的是拥有一个master分支，每个团队的一个永久分支，定期合并到master，以及每个用户故事的分支合并到这些团队的分支。有道理还是行不通？
2
当不再存在缺少元数据的情况时，v1.5之前的SVN中的合并带来的不便现在是否已经过时？
我开始使用SVN，因此有很多消息来源说，与DVCS工具相比，SVN中的合并非常困难。在最近的问题，我能找到这里SE是从2012年开始。 有时会提到原因是v1.5之前的SVN没有元数据，但是SVN现在是1.8.9版本。 鉴于SVN现在比v1.5更加成熟，尤其是我们没有使用SVN 1.5，所以我们不会因为提到的元数据不足而受苦- 这些反对SVN的论点是否仍然有足够的有效性？ 我知道DVCS有一种完全不同的方法，通常更可取，但是对于出于某些原因“必须”使用SVN的用户，合并不再是真正的“地狱”，对吗？
3
小型团队的Git工作流程
我正在制作一个git工作流程，以在一个小型团队中实施。工作流程中的核心思想： 有一个共享的项目主管，所有团队成员都可以写 所有开发仅在功能分支上完成 功能分支由分支作者以外的团队成员审阅的代码 功能分支最终合并到共享母版中，并且循环再次开始 本文详细解释了此循环中的步骤： https://github.com/janosgyerik/git-workflows-book/blob/small-team-workflow/chapter05.md 这有意义还是我错过了什么？
3
单一开发人员GIT工作流程（从简单的FTP迁移而来）
我正在尝试确定迁移到VCS对我来说是否明智。我是一个小型组织（5人）中的单个Web开发人员。由于以下原因，我想到了VCS（Git）：版本控制，异地备份，集中式代码存储库（可以从家里访问）。 目前，我通常在实时服务器上工作。我进入FTP，进行修改并保存，然后重新上传并刷新。编辑通常是针对CMS的主题/插件文件（例如，concrete5或Wordpress）。这很好用，但不提供备份，也不提供版本控制。 我想知道如何最好地将VCS集成到此过程中。我打算在公司的Web服务器上设置一个Git服务器，但是我不清楚如何将更改推送到客户帐户（通常是同一台服务器上的VPS）-现在，我只需使用其详细信息登录到SFTP，直接更改。 我也不确定什么将明智地表示一个资源库-每个客户的网站都会得到自己的资源库吗？ 任何见解或经验都将非常有帮助。我认为无论如何我都不需要Git的全部功能，但是基本的版本控制和事实上的云访问将非常有用。 编辑：我已经将其范围缩小到似乎最明智的两个选项。第一个基于ZweiBlumen的答案，即在实时服务器上进行编辑，然后将其提交到（外部）Git服务器。这样做的好处是我的工作流不会有太大变化（有额外的提交步骤，但其他方面是相同的）。 第二个选项是使用XAMPP在本地工作，然后从本地计算机提交更改。仅当站点上线时，我才将完成的文章从本地计算机上传到Web服务器（在最终提交到Git之后立即）。从理论上讲，这似乎还可以，但是如果该站点随后需要修改，并且我将它们放置在实时服务器上（通常这样做），那么我将需要手动复制本地存储区中已更改的文件，然后将这些更改提交给Git服务器。这似乎过分复杂，可能与我当前的工作流程相去甚远。 我认为总的来说，我会给＃1选项一个机会，然后看看我如何继续。
6
为发行版选择正确的分支策略
从新项目的新开发团队开始，我们必须为源存储库（例如Microsoft Team Foundation Server 2010）定义分支策略。关于是否要...我们进行了激烈的讨论。 一。有一个Release分支，我们可以从中进行生产构建，然后在实际发布某些内容时添加Label 要么 乙。每个投入生产的新版本都有一个新的Release分支（例如，版本1、2、3等） 选项A看起来很简单，但是我们不确定从长远来看是否会导致问题。选项B似乎只是创建了许多长期存在的分支，并且随着时间的推移不断积累。 有人有任何经验可以帮助我们做出决定吗？具体来说，我想听听任何一种选择的痛点所在。随时提供有关TFS和/或发布管理含义的特定经验。
4
在提交消息中引用错误/问题是否被视为良好做法？
我正在一个项目中，在该项目中我们设置了源代码控制，可以在Bug跟踪器中自动编写注释。我们只需在提交消息中写入错误问题ID，然后将提交消息作为注释添加到错误跟踪器。 我只能看到这种做法的一些弊端。如果将来某个时候源代码与错误跟踪软件分离（或者报告的错误/问题以某种方式丢失）。或者，当某人正在查看提交历史记录但无法访问我们的错误跟踪器时。 我的问题是在提交消息中包含错误/问题引用是否被认为是一种好习惯？还有其他缺点吗？
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.