最近，我对Golang非常感兴趣。 我在听GO TIME播客— GoLand IDE和管理Gopher Slack，关于IDE与编辑器的讨论很多。 引起我兴趣的是有关通过命令行使用Git以及使用IDE内置工具进行讨论的讨论。 这就是促使我撰写有关Git的工作流程的动机。
它既不是新的也不是独特的，但是我认为它可以帮助某些人在使用Git时决定使用什么工具以及何时使用。
自2012年以来，我一直在Git工作，与其他人相比，这已经是很长时间了，并且经历了所有的风风雨雨。 从使用autocrlf搞乱大型项目中的空白并重新将所有内容提交到存储库，到使用我的个人电子邮件地址将代码提交到客户端的存储库，宣誓提交消息，因为我将Git视为Git，而损失了一周的工作量我对待SVN，做了很多愚蠢的事情。 我也学到了很多东西。 这是我学到的几件事。
分支命名约定
这里没有魔术。 在过去的3年中，我一直在客户项目中使用以下约定-如果他们尚未使用以下约定。
- 手动GTD®检查清单
- Tipos de Beneficios que le puedes dar a tus Colaboradores。
- 使您在航站楼附近的生活更轻松
- 我的2017年三个词
- 一个日历黑客如何改变了我的生活
工作类型/ TICKET_ID-简短任务说明
我有点偷了《 Angular Commit Message Guideline》的命名约定，我也将其用于提交消息。
对于工作类型，我只有4种类型： feature ， bug ， docs和chore 。 我也倾向于为接触dockerfiles或其他面向基础架构的文件的任务引入基础架构。
TICKET_ID也是非常重要的。 我对此非常虔诚，因为大多数Git服务都与所选的问题跟踪器进行了某种形式的集成。 因此，如果客户使用的是外部问题跟踪器，则在分支名称中使用工单ID会帮助很多。 它为业务增加了一层额外的透明度，使他们能够看到正在执行任务，打开和关闭拉取请求等。 实际上，使用票证ID的最大好处实际上与代码审查有关。
例如，当前客户端使用BitBucket和Jira组合。 单击Jira中的“票证”列中的票证，单击票证所附的提取请求链接，然后直接转到BitBucket中打开的PR并查看更改，这非常有用。 相反，在完成检查后，假设不需要进行任何更改，则可以单击分支名称/ PR描述中的Jira票证ID，这将打开Jira票证的模态。 然后，我可以将其状态更改为“准备进行质量检查”，并将其分配给适当的人员。
这是一个实际示例： feature / MBS-44-add-facebook-login 。
合并请求/拉取请求实践
这里也没有幻想。 今天，大多数Git服务都在命令行中提供自定义链接，当您推送更改时，单击该链接时会自动告诉系统为您创建PR，并使用分支机构名称和提交消息中的详细信息预填充PR。
唯一的区别是，我没有使用斜杠和破折号来分隔所有内容，而是仅使用斜杠。 因此，前一个分支的拉取请求消息如下所示： Feature / MBS-44 / Add Facebook login 。 在请求请求标题中包含票证ID的目的与在分支命名约定部分中提到的目的相同。
提交讯息
对于这一部分，我比较自由，因为我不太愿意只使用《 Angular Commit消息准则》。 大多数情况下，我的提交消息都是这样构造的，在提交消息中还添加了工单ID。 这主要是因为我建议将每次提交都与问题跟踪卡绑定在一起，因此工作是100％透明的。 如果您在合并之前将更改拉入master分支中，那么在提交之前就压缩提交也很有帮助。
但是有时候我只需要一个描述性的提交消息，而该消息不符合上述样式指南，因此我去了。
命令行
啊，可怕的命令行。 与Vim一起，命令行比禽流感造成的受害者更多！ 实际上并非如此，我只是弥补了这一点，但这在一定程度上支持了我的主张。
当我开始使用Git时，我学会了直接从命令行使用它。 这就是为什么我不能全职使用任何编辑器/ IDE内置的Git管理工具。 感觉就像我缺乏控制力。
每当需要做一些易于产生多个冲突，空提交等的合并/变基操作时，我都会使用命令行。就像我说的那样，这完全是在控制事物。 如果我不知道幕后执行的命令是什么，以什么顺序执行，那么我只需手动运行它们即可。
如果我觉得比较容易，我也可以通过在Vim或当时打开的任何编辑器中直接编辑文件来求助于解决冲突。
编辑器/ IDE Git集成
使用编辑器的内置Git集成的第一件事是diff。 如果我有很多更改或冲突需要检查和解决，请跳到编辑器中，然后打开diff工具。 如果我对所发生的事情一清二楚，而且对即将要做的事情的正确性没有任何再思考，那么我也将在那里解决冲突。 否则，我将切换到命令行以完成任务。
GitHub桌面
我使用此工具的唯一原因是在给定文件中提交特定的代码行。 假设我处理一个文件并修改了3个功能。 我想创建三个单独的提交，每个函数一个。 尽管用于提交Git所谓的“笨蛋”的命令行语法非常易于使用git commit -p但是选择代码进行git commit -p的经验并不正确。 我知道我很容易使事情复杂化，但是我不喜欢的一件事就是用无用的东西弄乱我的记忆。 我认为从命令行暂存大块是没有用的。
放在一起
我从使用Git并犯错误的6年中得出的结论是，您不应该专注于使用单个工具来完成这项工作。 利用您的工具擅长的领域。 您的IDE的Git集成在差异和冲突解决方面令人惊讶，但在提交单独的行时却很烂吗？ 使用GitHub桌面，它是免费的，并且效果很好！
使用正确的工具完成正确的工作。 把它做完！ 移至下一个。 重复。
资源资源
我只会添加我认为是了解Git的最佳资源。 自2013年以来，我一直推荐它：git-简单指南。 请享用！
干杯!
这最初发布 在我的网站上 。
