当每个人都在学习master时，如何使git痛苦最小化？

#1 楼

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


从主人那里拉，以确保您是最新的
修改文件
进行更改（仅限本地）
再次从主服务器（这将导致出现冲突）
编辑所有文件，直到解决冲突为止，这意味着文件处于您要提交的适当状态（没有<<<<< HEAD and >>>> master原始文件中的消息）
进行合并更改
按

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

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

投入大量资金f使每个人都了解流程，否则他们可能会花一会儿，然后在实际拧紧master分支的同时感到不舒服，例如“使用我的文件而不是远程文件”来解决冲突只会消除所有更改

Git是一个很难学习的系统，特别是如果您是在Svn的陪伴下长大的，请耐心等待并给他们时间以适当的方式学习它，对于新用户，有时可以花一天的时间进行清洁搞砸了，那很正常。 ;）

#2 楼

当您与其他人在同一个分支中工作时，要记住三件事：


除非您真的知道自己在做什么，否则请不要使用--force。
commit或stash在每个pull之前进行中。
如果在pull之前push通常会更容易。无论您的“正式”回购是否使用分支机构。这与个人用户在其本地存储库中的操作无关。当我的公司使用完全不同的中央VCS时，我曾经使用git获取本地分支。如果他们为自己的功能创建本地分支并将错误合并到其本地master，则无需重新编写reflog或其他魔术就可以轻松解决很多问题。

#3 楼

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

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

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

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

#4 楼

有时，您的工作必须更改。

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


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

#5 楼

强调您可以重做合并
对您来说显而易见，但是前SVN用户可能不知道他们可以尝试多次解决合并问题。这可能会减少接收到的帮助标志的数量。
在SVN中，从trunk开始工作时，您会闲坐无休止地进行更改。然后，您将执行svn update。此时，您的更改将永远与其他人的更改混合在一起。无法撤消它（afaik），因此您别无选择，只能手动检查所有内容并希望回购处于良好状态。实际上，只要重做合并，您会更舒服。
即使我们搬到git，人们也会有相同的心态。导致许多意外错误。
幸运的是，有了git，有一种方法可以解决，特别是因为您可以进行本地提交。 （我稍后将在命令行中描述它的表达方式）。
尽管这样做的方式会因工具而异。我发现重做拉动并没有在许多GUI中作为单个按钮公开，但可能是可能的。我喜欢你用cygwin。我的同事使用sourcetree。由于您使用BitBucket，因此将其用作GUI是很有意义的，因为它是由同一公司Atlassian管理的。我怀疑有一些更紧密的集成。
关于拉动
我认为您是对的，pull中的合并真是使人搞砸了。一个pull实际上是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

#6 楼

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

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

它可能会解决您的构建机制问题，因为可能会指向构建工具

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

要确保在推入之前进行几乎所有需要的检查的地方钩子上的git book部分-https://git-scm.com/book/gr/v2/Customizing-Git-Git-Hooks-您可以使用pre-commit和pre-push钩子来执行诸如在建议的承诺，以确保工作有效，等等。-客户端挂钩的唯一问题是开发人员可以禁用它们或无法启用它们。

上游获取/合并和挂钩在TortoiseGit。

#7 楼

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

鼓励他们开始尝试git

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

对尝试玩东西的恐惧是学习git的最大障碍之一。它为您提供了对所有事物的太多控制，这令人生畏。现实情况是，您可以在日常使用中坚持一些非常安全的操作，但是要找出哪些命令需要一些探索。

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

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

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

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


在磁盘上，未提交
已暂存但未提交
在本地提交中
本地存储库
远程存储库（仅在不同存储库之间推送和拉取提交和标签）

与其鼓励一步一步地拉动和推送所有内容，不如鼓励它们利用它们5个不同的地方。鼓励他们：


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

决定如何处理获取的更改。选项包括：


提交其本地更改，然后在获取的更改之上重新放置它们。
提交其本地更改，然后与获取的更改合并。
/>
保存他们的更改，合并，然后取消保存并解决任何冲突。

还有其他内容，但是我在这里不做介绍。请注意，拉实际上只是一个获取和合并。不像他们是他们。 （将--rebase的更改从“提取+合并”转移到“提取+变基”。）




暂存其更改，然后对其进行审核。
提交其已进行的更改，然后进行审阅提交。
单独按下。

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

一旦他们习惯了这个主意了解它们的变化之后，他们便可以开始决定何时跳过步骤并合并某些操作（何时进行拉动，因为您已经知道要获取并合并，或者何时单击该“提交并推送”选项）。

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

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

鼓励他们使用本地分支

本地分支实际上减轻了处理共享文件的许多痛苦点。我可以在自己的分支中进行所有需要的更改，并且它不会影响任何人，因为我没有推送它们。然后，当时间到了时，我可以使用所有相同的合并和重新设置策略，只是更简单：


我可以重新设置我的本地分支，这使得将其合并为琐碎的母版。 />我可以在master中使用普通合并（创建新的提交）将本地分支的更改引入其中。
如果我认为我的分支也是如此，可以将整个本地分支合并到master上的单个提交中

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

总结

总而言之，git不是SVN，不能像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绕过配置），或者甚至可以暂时推迟合并我的更改并稍后再处理。我认为这个小小的减速将帮助您的团队避免对合并做出错误的决定。一旦他们能够更好地处理合并，就可以让您的团队将其关闭。

#8 楼

我在公司经历了完全相同的SVN-> git经验，而根据我的经验，唯一的补救方法就是时间。让人们习惯使用工具，让他们犯错误，向他们展示如何修复它们。您的速度将遭受一段时间的破坏，人们将失去工作，每个人都会变得有些麻木，但这就是改变像VCS这样基本的东西的本质。在过渡时期的初期，每个认为TortoiseGit都是障碍而不是帮助的人。 TortoiseGit在最好的情况下不是一个优秀的GUI，并且通过掩盖git的简单性实际上是如何工作的，这也使您的同事无法理解git的核心概念，例如两阶段提交。 br />
我们做出了一个（相当大胆的决定），迫使开发人员使用命令行（git bash或posh-git）一周，这对于理解git的实际操作方式和工作方式产生了奇迹。与SVN不同。听起来可能太过激烈了，但我建议您仅尝试一下，因为它可以创建对git模型的理解-一旦他们了解了这一点，您的同事就可以开始使用他们喜欢的git上的任何GUI外观。 />最后的提示：您的一些同事几乎会立刻抱怨git的工作原理，而有些人则永远不会。后者，您只需要教一些神秘的咒语，以使他们的代码从本地计算机获取到服务器，以便每个人都可以看到它。

#9 楼

好吧，最近我调整了以下工作流程，以确保永远不会建立master分支：

1）每个人都使用自己的分支，这实际上是master分支的副本。

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

我只是从master分支创建的，所以完全一样。我开始在自己的分支上开发一项新功能，完成后，请执行以下操作。

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

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分支将是干净的。

#10 楼

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

是的，这意味着每个人都在掌握工作。这还不错。和习惯了TFS或SVN的团队会发现这是最自然的。

使此过程尽可能无痛的常规程序：


每天早晨做git stash && git pull --rebase && git stash pop
经常提早提交（不需要立即推送；我们至少可以开始提早使用git）

为了推送，请执行以下循环：

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.

#11 楼

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

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

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

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