Questions tagged «git»

关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，使它成为软件工程堆栈交换的主题。 5年前关闭。 几个月前，我钻研了Subversion和GIT，感到很失望。他们可以很好地处理源代码，但不能处理其他方面。例如，受版本控制的网站需要管理文件/目录所有权，文件/目录的读写访问权限，访问控制列表，时间戳，数据库内容。和外部链接。是否有一个版本控制系统可以像从一个月前的备份中重新加载一样完美地完成还原？

17 version-control  git  svn  backups  revisions 

我目前在一家使用VSTS管理git代码的公司工作。Microsoft合并分支的“推荐”方法是进行“挤压合并”，这意味着该分支的所有提交都被压缩为一个合并了所有更改的新提交。 问题是，如果我在一个分支中对一个积压项目进行了一些更改，然后立即开始在另一个分支中对另一个积压项目进行更改，而这些更改取决于第一个分支的更改集怎么办？ 我可以为该积压项目创建一个分支，并将其基于第一个分支。到目前为止，一切都很好。但是，当需要为我的第二个分支创建一个拉取请求时，第一个分支已经合并到master分支中了，因为它是作为壁球合并完成的，所以git会标记很多冲突。这是因为git看不到第二个分支所基于的原始提交，它只看到一个大壁球合并，因此为了合并第二个分支以掌握它，它尝试重播第一个分支的所有提交。壁球合并的顶部，引起很多冲突。 所以我的问题是，有什么办法可以解决这个问题（除了从不将一个功能分支从另一个功能分支上转移出去，这限制了我的工作流程），或者壁球合并只是打破了git的合并算法？

17 git 

我的办公室使用Git和SourceTree进行版本控制。之所以如此，是因为当我加入时，版本控制为零，而SourceTree是我曾经使用过的唯一系统。我绝对不是专家，但是我是同事中经验最丰富的人，因此我是事实上的专家，负责教会每个人正确使用Git并纠正他们犯的任何错误。 我正在制作一个教程文档，其中涉及Git和SourceTree，并解释了该过程的每个步骤。在“拉”过程中，“ SourceTree”对话框允许您选择“立即提交合并的更改”选项。我了解它的作用以及为什么有用。我不明白的是为什么会有人不希望使用此功能。 有人可以解释为什么您永远不想自动提交合并的更改吗？我试图理解其原因，以便可以更好地解释该功能的用途，并了解将来需要注意的陷阱。 编辑：我不认为我的问题是链接的问题的重复。链接的问题广泛地询问多久提交一次。我在问为什么不选择不使用与在SourceTree中提交合并有关的特定功能。

16 version-control  git  merging 

我与其他远程开发人员一起在Rails应用程序上与小型团队合作。我们开始修改我们的git工作流程。我们已经考虑过如下所示的分支结构： (dev) -> (qa) -> (stag) -> (master) 但是，一些开发人员认为，对于新开发人员而言，他们可能会自动将其推送到master上，这可能会减少混乱。他们反而想让每个人都在master上工作，并为生产创建一个单独的分支。 (master) -> (qa) -> (stag) -> (prod) 有人告诉我您要保持master的可部署性，而不是将其用作开发，并且从我曾经工作过的地方开始，master总是可以为生产而部署。 使用分支结构（其中主动使用master进行开发，而使用单独的prod分支进行部署）会带来哪些不利呢？

16 git 

我们是一家软件咨询公司，为不同客户提供大量项目。传统上我们使用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 

我们两个人在做某事。我们正在使用这种分支结构 主 dev-A dev-B 我们俩都在单独的分支（dev-A，b）上工作，并且每当完成时-我们将更改推广到master。 但是这样做的缺点是我们无法获得其他开发人员所做的更改。一切都存在于主树中-但是我们无法获得其他开发人员所做的最新更新。 有没有办法解决这个问题，还是我们应该更改分支结构（按功能）？

16 git 

我将我的Git回购基于一个成功的Git分支模型，并且想知道如果遇到这种情况会发生什么： 假设我在两个要素分支A和B上进行开发，并且B需要来自A的代码。X节点在要素A中引入了一个错误，该错误会影响分支B，但是在合并了要素A和B的节点Y上未检测到此错误，在再次分支并进行下一次迭代之前进行了测试。 结果，功能B的工作人员在节点Z上发现了错误。在此阶段，已确定需要进行错误修复。此修复程序应同时应用于两个功能，因为使用功能A的人员还需要修复该错误，因为该错误是其功能的一部分。 是否应该从最新的功能部件A节点（从节点Y分支的一个部件）创建一个错误修正分支，然后与功能部件A合并？在将这两个功能合并到一起之后，再进行开发和测试，然后再进行分支？ 问题是它需要两个分支合并才能解决此问题。由于功能部件B不接触功能部件A中的代码，是否有办法通过实施修订并仍允许功能部件B分支保持未合并但功能部件A具有固定代码的方式来更改节点Y上的历史记录？ 密切相关：Git错误分支约定

16 git  bug  branching 

使用拉取请求而不是简单地将分支合并到没有分支的master中有什么好处？特别是在所有开发人员都拥有完全掌握母版权限的团队中。

16 version-control  git  development-process  merging  pull-requests 

在我们的团队中，除了个别的工作单元（故事），我们还有工作时间更长的主题（史诗）。多个故事成为史诗。 传统上，我们为每个故事提供功能分支，并在它们通过质量检查后直接合并为母版。但是，我们希望开始阻止在Epic中发布已完成的故事，直到Epic被视为“功能已完成”为止。我们只会在整个Epic关闭时才将这些功能发布到生产环境中。此外，我们有一个每晚生成的服务器-我们希望所有封闭的Stories（包括那些不完整的Epics的故事）都将自动部署到该每晚的服务器。 关于如何管理我们的仓库来实现这一目标，有什么建议吗？我考虑过引入“史诗般的分支”，在这里我们将封闭的故事合并到相关的史诗分支中，而不是直接掌握。但我担心的是： 我担心如果史诗分支长时间保持开放可能会发生合并冲突 每晚构建需要将所有史诗分支合并为一个“每晚构建”分支。同样，可能会发生合并冲突，这将自动完成

15 version-control  git  maintenance  branching 

我目前正在与一个使用git工作流程的团队一起进行项目。这非常简单，master应该处于可部署状态，并且分支用于创建功能和修补程序。每当我们完成并测试了功能或错误修正后，我们就会尽快将其移交给母版。想法是分支应该尽可能小，以使其更易于合并回主节点。我们有一个政策，即任何推送到master分支的代码都应处于可部署状态并通过测试。 我们遇到这样的情况，其中一个开发人员在一个分支上做了很多工作（几个月的价值），而这个分支还没有被合并回master。现在，该分支上有一些单独的功能和大量提交，实际上，该分支确实应该已经合并了几次，但到目前为止还没有合并。大多数代码处于良好的状态，可以将单元测试合并回到主测试中，但是最近的更改肯定不应该如此，因为它们尚未完成且未经测试。 处理这样一个分支实际上与另一个分支相距甚远的情况的最佳方法是什么？将来，我们可以通过哪些方式避免分支从master获得大量提交？

15 git  workflows 

很抱歉，如果这是重复的，我看了看。 我们要搬到Git。在Subversion中，我习惯于使用\ trunk，\ branches和\ tags文件夹。 使用Git，在分支之间切换将替换工作目录的内容，因此我是否可以假设我们以前的工作方式不适用于Git？ 我的猜测是，我将拥有一个可能带有gitignore和readme.txt的repo文件夹，然后是组成该repo的项目的文件夹，仅此而已。

15 version-control  git 

在传统的VCS中，我可以理解为什么您不提交未解决的文件，因为您可能会破坏构建。但是，我不明白为什么您不应该在DVCS中提交未解析的文件（其中有些实际上会阻止您提交文件）。 相反，我认为你的版本库应该从被锁定推和拉，但不承诺。 在合并过程中能够提交有几个优点（如我所见）： 实际的合并更改在历史记录中。 如果合并很大，则可以进行定期提交。 如果您犯了一个错误，那么回滚会很容易（不必重做整个合并）。 在将文件标记为已解决之前，可以将其标记为未解决。这将防止推/拉。 您还可能有一组变更集充当合并，而不是一个变更集。这样一来，您仍然可以使用的工具git rerere。 那么，为什么要对未解决的文件进行提交以防止/阻止呢？除了传统之外，还有其他原因吗？

15 version-control  git  mercurial  dvcs 

我已经在这里和SO上进行了几次讨论，以至于DVCS存储库所使用的空间与其集中式对应部分的空间相同或更少。我可能已经错过了，但是我找不到很好的解释。有人知道吗

15 version-control  git  svn  mercurial  dvcs 

同事和我自己都遇到了一个我们有很多看法的问题。 当前，我们有一个git存储库，我们将所有cronjobs保留在其中。大约有20克朗，它们除了它们都是小型python脚本并且对于某些活动必不可少之外，并没有真正的关联。我们使用一个fabric.py文件来部署和requirements.txt文件管理所有脚本的要求。 基本上，我们的问题是，是否将所有这些脚本都保存在一个git存储库中，还是应该将它们分离到各自的存储库中？通过将它们保存在一个存储库中，可以更轻松地将它们部署到一台服务器上。对于所有脚本，我们只能使用一个cron文件。 但是，这感觉不对，因为20个cronjob在逻辑上不相关。此外，使用一个在requirements.txt文件中的所有脚本，这是很难搞清楚什么是依赖一个特定的脚本，它们都必须使用的软件包的版本相同。 我们可以将所有脚本分离到各自的存储库中，但这会创建20个需要记住和处理的不同存储库。这些脚本中的大多数都不是很大，解决方案似乎过大。 一个相关的问题是，我们是对所有cronjobs使用一个大crontab文件，还是对每个cronjobs使用单独的文件？如果每个人都有自己的设备，那么一个crontab的安装如何避免覆盖另一个19个？这似乎也很痛苦，因为随后需要20个不同的cron文件进行跟踪。 简而言之，我们的主要问题是将它们紧密地捆绑在一起作为一个存储库，还是将它们通过自己的require.txt和fabfile.py分离到自己的存储库中？我们觉得我们也可能正在寻找一些非常简单的解决方案。有没有更简单的方法来解决此问题？

15 python  version-control  git 

我想以免费许可证发布音频指纹识别软件项目，但是存储库包含受版权保护的音频文件。测试用例当前还使用这些文件。如何在不违反版权的情况下以最高版本历史向公众发布代码？ 细节： 该代码在git下进行了版本控制。在发布之前，我们会将其全部折叠回一个分支。 有400 MB的音频数据。有些文件是来自Jamendo的免费许可音乐，另一些是我们个人收藏中的MP3。 无论采用哪种方法，我们都将始终保留原始存储库的不变副本，以免破坏项目历史。 主要问题：如何处理公开发布？ 从git存储库中删除有问题文件的所有历史记录，并释放更改后的存储库。（v64 指出了执行此操作的方法。） 另外，也可以对代码的当前状态进行快照，甚至不必费心查看预发布代码的公开历史记录。 附带问题：鉴于项目的早期阶段有时需要私有代码或媒体，我们如何首先避免这种困境？

15 open-source  testing  git  release