我们大约十个人的文档团队最近从SVN迁移到Git。在SVN中，每个人都在研究master。这是我一直讨厌的模型，但我无法带来这种改变。作为迁移到Git的一部分，我们已经同意解决此问题，但我们还不能做到这一点（等待构建更改，以允许从任意分支进行构建）。同时，每个人都在研究大师。是的，我知道这很可怕，相信我。

与使用SVN相比，我们现在看到的麻烦更多，其中一些是由Git的两阶段模型（本地和远程）引起的。有时人们会做出承诺但无法推动，或者他们会与即将发生的本地更改产生冲突。昨天有人以某种方式破坏了最近的更改，但合并失败了，我认为这是Git在您进行合并并进行出色更改时所做的合并。（他无法确切地告诉我他做了什么，并且因为他使用的是GUI，所以我不能只检查他的shell历史记录。）

作为最熟练的Git用户（请阅读：我以前使用过，尽管没有做过任何复杂的事情），我是制定策略，教授工具和清理混乱的人。在我们可以切换到分支上进行开发之前，我如何对使用工具的方式进行更改，以使共享的活动主数据库不易出错？

该小组正在Windows上使用Tortoise Git。我们使用Tortoise Git是因为我们之前使用过Tortoise SVN。（我个人使用Cygwin下的命令行进行某些操作，但是团队已经明确表明他们需要GUI，我们将使用此GUI。）答案应该与此工具一起使用，而不是建议替代工具。

Tortoise Git可以通过一次操作“提交并推送”，我已经告诉他们一定要这样做。但是，它不是原子的-可能会发生提交（毕竟是本地的）的工作，但推送没有（例如，由于冲突或网络问题）。当发生这种情况时，他们会得到一个模棱两可的错误。我已经告诉他们检查BitBucket提交日志，如果他们对最近的提交有任何疑问，如果看不到，则进行推送。（如果那是问题，可以解决冲突，或者如果他们不知道该怎么办，请寻求帮助。）

团队已经有“提早并经常拉”的好习惯。但是，拉力似乎会引起冲突，我认为这是新的吗？如果不是新的，则比SVN中的频率要高得多。我听说我可以更改Git的拉动方式（重新设置基数而不是合并），但是我对那里的权衡（或在我们的环境中如何做到）没有很好的了解。

服务器是BitBucket（不是Github）。我对我们的存储库拥有完全的管理控制权，但更一般而言，服务器上没有。这些都不是可变的。

源文件是XML。还有一些图形文件，每个人都知道您无法合并，但是我们几乎也从来没有冲突。合并冲突来自XML文件，而不是图形。

我可以对Git的使用进行哪些​​更改，以使共享主控团队更加顺畅，直到我们可以使用已审阅，经过测试验证的请求请求的功能分支为止？

到目前为止，SourceTree是学习该概念的最佳IDE，因为它显示了每个阶段上所有相关的对话框和选项，默认选项通常很好，不要搞乱rebase等。只需遵循正常流程即可：

• 从主人那里拉出来，只是为了确保您是最新的
• 修改文件
• 提交更改（仅在本地）
• 从主机再次拉动（这将导致出现冲突）
• 编辑所有文件，直到解决冲突为止，这意味着该文件处于您要提交的适当状态（原始文件中没有<<<<< HEAD和>>>>主消息）
• 提交合并更改
• 推

如果每个人都遵循此食谱，则应该没事。

每次有人进行较大的更改或中央更改时，通知其他用户在本地进行提交并从主用户那里拉回，这样他们以后就不会发生太多冲突，并且第一个人仍然可以与他们一起解决冲突。

花很多时间让每个人都了解流程，否则他们可能会花一会儿时间，然后在实际拧紧master分支的同时就对它感到满意，例如“使用我的文件而不是远程文件”来解决冲突就可以了排除其他人所做的所有更改。

Git是一个很难学习的系统，特别是如果您在Svn的陪伴下长大，要有耐心并给他们一些时间来正确学习它，对于新用户，有时您可能会花一天的时间清理一些混乱，这很正常。;）

与其他人一起在同一分支机构工作时，要记住三件事：

• --force除非您真的知道自己在做什么，否则不要使用。
• 无论是commit或stash您的进展之前，每一个工作pull。
• 如果您pull刚来之前，通常会更容易push。

除此之外，我将指出，使用分布式版本控制，您的“正式”回购是否使用分支都无关紧要。这与个人用户在其本地存储库中的操作无关。当我的公司使用完全不同的中央VCS时，我曾经使用git获取本地分支。如果他们为自己的功能创建本地分支并将错误合并到本地master，则无需重新编写reflog或其他魔术就容易得多。

每个人都可以花一天时间学习git吗？

确实应该期望计算机使用专业人士学习一种新工具，尽管可能在任何VCS中犯很多错误，但他们应按设计使用的方式使用该工具。

引入此方法的最佳方法是，使每个人在进行更改时（尽可能短）在各自的分支上工作，并进行变基，然后在完成后合并回master。这与当前的工作方式相差不远，并引入了一个简单的工作流程，使他们习惯了，直到他们有足够的信心进行更复杂的操作为止。

我不使用Windows，但是如果Tortoise基本上是在其中隐藏git并假装它是SVN，那么也许Tortoise是错误的工具。

有时，您正在做的事情必须改变。

最大的问题是每个人都在研究master。这在代码开发中并不常见，在您的情况下也可能是错误的模型。如果您可以更改此内容，则通过要求/要求在单独的分支上进行更改，您将处在更好的状态。使用分支机构，您可以获得：

• 强制禁止直接推送master。
• 通过Bitbucket强制创建合并请求，并至少获得一个批准。这样可以确保有人正在查看更改，并且还可以减轻合并本身的痛苦，因为UI将显示与远程版本代码的冲突，而不是用户在桌面上拥有的版本。这样可以防止提交但推送失败的情况。
• 在合并之前，针对您的存储库执行“构建”。我意识到这是一个文档库，但也许可以在此版本的基础上进行拼写检查，legalese抓取甚至自动翻译（将STRING_DEF内容导出到csv文件）。也许不是，取决于您的工作。
• 允许人们更轻松地同时从事多种不同的工作。是的，这也可以使用存储来完成，但是有点杂乱无章，并且有些信息告诉我您也没有使用它们。

如果您不能使用分支，则可以考虑编写一个merge-and-push脚本，该脚本可以自动消除某些痛点。也许它将检查用户是否不在master上，进行提取和拉取，然后尝试合并（可能使用--no-commit --no-ff），依此类推。

强调您可以重做合并

对于您来说，这可能很明显，但是以前的SVN用户可能不知道他们可以尝试多次解决合并问题。这可能会减少您收到的帮助标志的数量。

在SVN中工作时，trunk您会无休止地进行更改。然后你会做一个svn update。此时，您的更改将永远与其他人的更改混合在一起。无法撤消它（afaik），因此您别无选择，只能手动检查所有内容并希望回购协议处于良好状态。当确实要重做合并时，您会更舒服。

即使我们迁移到git，人们也会有相同的心态。导致很多意外错误。

幸运的是，有了git，有一种方法可以解决，特别是因为您可以进行本地提交。（我稍后将在命令行中描述它的表达方式）

尽管完成的方式会因工具而异。我发现重做拉动并没有在许多GUI中作为单个按钮公开，但可能是可能的。我喜欢你用cygwin。我的同事使用sourcetree。由于您使用BitBucket，因此将其用作GUI是有道理的，因为它由同一公司Atlassian管理。我怀疑还有一些更紧密的集成。

关于拉

我认为您是对的，合并pull真是一团糟。pull实际上是A ，git fetch它从服务器检索更改，然后是git merge origin/<branchname>*，它将远程更改合并到您的本地分支中。（https://git-scm.com/docs/git-pull）

结果是所有标准合并命令都与pull一起使用。如果该合并有冲突，则可以通过终止git merge --abort。您应该在合并之前回到哪个位置。然后，您可以使用git pull或再次尝试git merge origin/<branchname>。

如果您能以某种方式使用所选的同事的GUI工具学习如何执行上述操作，那么我认为这将解决您的大多数问题。抱歉，我不能更具体。

*我了解起源并非总是如此。

使用git reflog诊断问题

我和您一样，必须诊断出大多数由滥用GUI工具造成的问题。我发现git reflog有时这会有所帮助，因为这是存储库中动作的相当一致的痕迹。虽然有时很难阅读。

替代

由于您的情况只是暂时的，因此您可以返回SVN，直到有适当的流程可以推出为止。我会犹豫要这样做，因为很多地方会继续说“我们尝试过git，但它只是行不通...”而从未真正将其备份。

其他一些常见的过渡问题

• 人们通常会确信回购处于无法使用的状态，因此通常会删除并重新获得其回购。通常，这是由于找不到本地和远程差异造成的。GUI工具和CLI都无法很好地显示这一点。在CLI中，我找到git log --decorate了概述差异的最简单方法。但是，如果事情太繁琐（例如），您可以git reset --hard origin/master

许多开源团队都采用的一种可能的机制是使用派生模型-https: //www.atlassian.com/git/tutorials/comparing-workflows （在讨论派生git工作流程时，请务必明确说明） ）。

在这种情况下，每个开发人员或子团队都有自己的存储库分支，他们从BitBucket签出确实为此提供了一种机制，除了默认的远程服务器外，还设置了“上游”来源-他们将必须记住“向上游获取” ”和“合并远程/上游/主服务器”。

它可能会解决您的构建机制问题，因为构建工具可能会指向另一个项目（即fork）上的主数据库。

然后，您可以从大多数人中删除直接推送到主项目的能力，并减少具有审核和批准角色的较小人员组成的团队。参见https://www.atlassian.com/git/tutorials/making-a-pull-request

在这里您可以阅读了关于确保几乎任何理想的检查推前所做的是在挂钩混帐书节- https://git-scm.com/book/gr/v2/Customizing-Git-Git-Hooks -您可以使用pre-commit和pre-push钩子来执行类似的操作，例如对建议的提交进行一些测试以确保工作是有效的，等等。-客户端钩子的唯一问题是开发人员可以禁用它们或无法启用它们他们。

TortoiseGit中提供了上游提取/合并和挂钩。

这听起来似乎违反直觉，但请听我说：

鼓励他们开始尝试git

git有趣的事情之一是，使任何本地操作完全安全非常容易。刚开始使用git时，我发现自己做的一件事是将整个目录压缩为一个备份，以防万一我搞砸了。后来我发现这是一个巨大的麻烦，实际上几乎不需要保护您的工作，但是它的优点是非常安全，非常简单，即使您不知道自己在做什么和如何做也是如此。您想要尝试的命令将显示出来。执行此操作时唯一需要避免的是push。如果您不进行任何操作，这是一种100％安全的方法来尝试您想要的任何东西。

害怕尝试东西是学习git的最大障碍之一。它给你这样过的一切，它是一种令人生畏的太多的控制。现实情况是，您可以在日常使用中坚持一些非常安全的操作，但是要找出哪些命令需要一些探索。

通过给他们的感觉安全，他们会更愿意尝试找出如何做自己的事情。他们将更有能力在自己的本地计算机上找到适合他们的个人工作流程。如果不是每个人都在本地做同样的事情，那很好，只要他们遵守所推动标准。如果在进行操作之前需要压缩整个存储库，这样就可以了；他们可以随时随地尝试更好的做事方式。让自己开始尝试并观察其作用的任何方法。

这并不意味着培训是毫无价值的。相反，培训可以帮助您介绍功能，模式和规范。但这并不是坐下来在日常工作中实际做事的替代品。git和SVN都不是您可以去上一堂课，然后就知道了一切的东西。您必须使用它们来解决问题，以熟悉它们以及哪些功能非常适合哪些问题。

停止阻止他们学习git的来龙去脉

我提到没有推动任何事情，这实际上与您一直在教他们的一件事相反：始终“提交并推动”。我相信您应该停止告诉他们这样做，并告诉他们开始相反的事情。Git基本上有5个“位置”，您可以在其中进行更改：

• 在磁盘上，未提交
• 上演但未落实
• 在本地提交
• 在当地藏匿
• 远程存储库（仅在不同存储库之间推送和拉取提交和标记）

不要鼓励他们一步一步地推动和推动一切，而要鼓励他们利用这5个不同的地方。鼓励他们：

• 在提交更改之前先获取更改。

• 做出决定如何处理所取得的变化。选项有：

  • 提交它们的本地更改，然后在获取的更改之上重新设置它们的基础。
  • 提交其本地更改，然后与获取的更改合并。

  • 存储它们的更改，合并，然后存储并解决所有冲突。

    还有其他东西，但我在这里不介绍。请注意，拉实际上只是获取和合并。它不喜欢他们。这是他们。（将--rebase更改从fetch + merge拉到fetch + rebase。）

• 进行他们的更改，然后进行检查。
• 提交他们的阶段性更改，然后查看提交。
• 单独推动。

这将鼓励他们在将工作公开发布给所有人之前检查其工作，这意味着他们将更快地发现错误。他们将看到提交并思考：“等等，这不是我想要的。”与SVN不同，他们可以回去再尝试，然后再进行推送。

一旦他们习惯的理解的想法，其中的变化，那么他们就可以开始决定何时跳过步骤，并结合某些操作（当拉，因为你已经知道你要取+合并或当单击提交与推送选项） 。

实际上，这是git相对于SVN的巨大好处之一，而git在设计时就考虑了这种使用模式。相比之下，SVN假定使用中央存储库，因此，如果git的工具没有针对同一工作流程进行优化，就不足为奇了。在SVN中，如果您的提交是错误的，那么您唯一真正的求助就是撤消错误的新提交。

这样做实际上自然会导致下一个策略：

鼓励他们使用当地分支机构

本地分支机构实际上减轻了处理共享文件的许多痛苦点。我可以在自己的分支中进行所有所需的更改，并且由于我不推动它们，因此它永远不会影响任何人。然后，当需要时，我可以使用所有相同的合并和变基策略，只是更简单：

• 我可以重新建立本地分支的基础，这使得将其合并为琐碎的母版。
• 我可以在master中使用纯合并（创建新的提交）将本地分支的更改引入其中。
• 如果我认为我的分支太麻烦了，可以将我的整个本地分支合并成一个对master的提交。

使用本地分支机构也是确定系统分支策略的良好起点。它可以帮助您的用户更好地了解他们自己的分支需求，因此您可以根据需求和团队当前的了解/技能水平来选择策略，而不仅仅是因为大家都听说过Gitflow而已。

摘要

简而言之，git不是SVN，不能像它一样对待。你需要：

• 通过鼓励安全实验来消除恐惧。
• 帮助他们了解git有何不同，以便他们了解如何改变其正常工作流程。
• 帮助他们了解可用的功能，以帮助他们更轻松地解决问题。

所有这些都将帮助您逐步采用更好的git使用方法，直到达到可以开始实施一套标准的地步。

具体特点

从近期来看，以下想法可能会有所帮助。

变基

您提到了变基，而您在问题中并不真正了解它。因此，这是我的建议：尝试一下我刚刚描述的内容。在本地进行一些更改，而其他人则进行一些更改。在本地提交更改。压缩您的存储库目录作为备份。获取其他人的更改。现在尝试运行一个rebase命令，看看您的提交会发生什么！您可以阅读无休止的博客文章，也可以接受有关变基以及如何使用或不应该使用它的培训，但是这些都不能替代它的实时运行。所以尝试一下。

merge.ff=only

这将是个人喜好的问题，但是由于您提到您已经在处理冲突方面遇到麻烦，因此我至少会暂时推荐它。我建议设置merge.ff为only：

git config --global merge.ff only

“ ff”代表“快进”。快速前进合并是git不需要合并来自不同提交的更改的情况。它只是将分支的指针沿着图中的直线向上移动到新提交。

实际上，这样做是为了防止git自动尝试创建合并提交。因此，如果我在本地提交某些内容，然后再进行其他人的更改，而不是尝试创建合并提交（并可能迫使用户处理冲突），则合并只会失败。实际上，git只会执行fetch。如果没有本地提交，则合并将正常进行。

这为用户提供了一个机会，使用户有机会在尝试合并不同的提交之前先进行查看，并迫使他们做出如何最好地组合它们的决定。我可以重新设置基础，继续进行合并（使用git merge --no-ff绕过配置），或者甚至可以暂时暂不合并所做的更改，然后再进行处理。我认为这个小小的减速将帮助您的团队避免对合并做出错误的决定。一旦他们能够更好地处理合并，就可以让您的团队将其关闭。

我在公司经历了完全相同的SVN-> git经验，而根据我的经验，唯一的补救方法就是时间。让人们习惯使用工具，让他们犯错误，向他们展示如何修复它们。您的速度将遭受一段时间的折磨，人们将失去工作，每个人都会变得有些棘手，但这就是改变像VCS这样基本的东西的本质。

就是说，我同意所有人的意见，即在过渡时期的早期，TortoiseGit是一个障碍而不是帮助。TortoiseGit在最好的情况下不是一个出色的GUI，并且通过掩盖git的简单性实际上是如何工作的，这也使您的同事无法理解git的核心概念，例如两阶段提交。

我们做出了（相当大胆的）决定，迫使开发人员使用命令行（git bash或posh-git）进行一周的工作，这使人们理解git的实际操作方式以及与SVN的不同之处。听起来可能太过激烈了，但我建议您仅尝试一下，因为它可以创建对git模型的理解-一旦他们了解了这一点，您的同事就可以开始使用他们喜欢的git上的任何GUI外观。

最后说明：您的一些同事几乎会立即了解git的工作原理，并且有些人永远不会。后者，您只需要教一些神秘的咒语，以使他们的代码从本地计算机获取到服务器，以便每个人都可以看到。

好吧，最近，我调整了以下工作流程，以永不结束master分支：

1）每个人都使用自己的分支，该分支最初是master分支的副本。

让我们将master分支命名为“ master”，将我自己的分支命名为“ my_master”。

我只是从主人那里取得分支，所以完全一样。我开始在自己的分支上开发新功能，完成后，请执行以下操作。

Currenly在我的分支上，刚完成编码

git add . && git commit -m "Message" && git push

回到主分支

git checkout master

如果不是最新则拉

git pull

回到我自己的分行

git checkout my_master

将最新的母版合并到我自己的分支中

git merge master

解决冲突和合并

再次测试一切

当所有内容合并并固定在我自己的分支上后，将其推送

git push

回到主分支

git checkout master

与我的分支合并

git merge my_master

由于先前合并在您自己的分支上解决了冲突，因此不可能

推大师

git push

如果每个人都遵循此规则，则master分支将是干净的。

因此，我们有一个从TFS转到git的团队，并保留了旧的思维方式。一般的操作规则大致相同。

是的，这意味着每个人都在学习大师。这还不错。熟悉TFS或SVN的团队会发现这是最自然的。

使此过程尽可能轻松的一般程序：

1. git stash && git pull --rebase && git stash pop每天早上做
2. 尽早并经常提交（不需要立即推送；我们至少可以尽早开始利用git的这种优势）

3. 用于推送执行以下循环：

   git add git commit git pull --rebase fix any merges compile git push loop until you don't get the can't fast forward error message.

如果每个人都在研究Master，那么您无能为力。事情不可避免地会变得混乱。

您应使用master作为完成产品的发送给客户。你应该用发展的不断发展，你应该不会允许任何人来推动发展。标准是每个人都从dev分支，进行更改，将其从本地推送到服务器上的分支，然后发出推送请求。然后有人检查更改并将其合并到开发中。

为了避免冲突，每个人在推送之前都会将开发合并到自己的分支中，并在该阶段解决冲突（因此它只影响本地的一名开发人员）。如果合并到开发中会引起冲突，则不会合并-开发人员将开发再次合并到其分支中，然后再次推送到服务器，然后再次进行审查。

例如，您可以使用sourcetree轻松完成这项工作。