面向单个开发人员的Github工作流

我想要一些关于我的git工作流的反馈，因为这是我第一次使用它，尽管阅读了各种文章和堆栈溢出问题，但我不确定我的流程是否正确。这是我当前的工作流程（请注意，我正在使用Github for Windows应用程序进行所有git交互）：

决定我要实现的下一个特性是什么

为特征创建具有适当描述性名称的分支。我通过单击Github for Windows中的branch按钮并键入一个新名称来实现这一点

写一些代码

将这些更改提交到我的新分支

再写一些代码

将这些更改提交到我的新分支

我已经完成了功能的实现，所以我想将我的更改合并回主分支。因此，我单击分支标题下的“管理”按钮

将新分支合并到主分支中

删除新分支

在第7步之前，我对这个过程感到非常满意，在这一点上我有点困惑。我想我的困惑在于我试图使用Github for Windows应用程序，而不是使用命令行。该应用程序似乎使事情变得更容易，但在我的理解中，我看到提到的一些命令/指令与您将在该应用程序中执行的操作之间有一点脱节

让我问一些具体问题：

我的工作流程是否正确？如果没有，它有什么问题，我如何改进它

我是否应该“发布”对新分支的更改？我的理解是，这相当于在命令行中执行

gitpush

。这是真的吗？如果是这样的话，我想我只想在完成该功能的实现或者该功能处于良好状态时才这样做

我应该在将分支合并到主分支时删除它，还是应该永远保留它

我是否需要在完成合并后发布主分支，或者这是隐式的

我有时无法执行合并并获取以下错误消息： 无法合并

无法将“测试”合并到“主”中。您可能需要打开一个shell并调试此repo的状态

以前发生过这种情况时，我可以切换到主分支，并将新分支合并到主分支中，但这不再有效。无论我在哪个部门，我都不能合并这两个部门。两者都是同步的，我已经发布了测试分支的所有更改。我应该在shell中键入什么来找出为什么不能合并分支

以下是提示我的流程的主要链接，仅供参考：

---

您所描述的内容听起来像是一个常见的分支工作流，即使对于同一代码库上的多个开发人员来说也能很好地工作。它是git命令行的一个扩展，用于自动化某些步骤。值得一看

我不太喜欢git的UI工具。我大部分时间都在使用命令行。所以我对GitHub for Windows没有经验。但我敢打赌，你的问题是因为你的合并不再是快进的。这将需要一个手动合并步骤，该步骤（afaik）不包含在该工具中

在将分支合并到上游之后，没有充分的理由保留分支。但一个是跟踪提交进入某个特性的内容。如果你决定保留这些分支机构，我建议你将它们公布。您不依赖本地计算机上的代码。顺便说一句，保留分支不会让你的存储库变得更大，但会污染你的视线。大多数情况下，提交仍然存在于上游分支中

合并后，您必须发布（推送）主分支

为了熟悉git命令行工具，我建议从GitHub的家伙开始，并按照他们的链接参考了解更多细节

---

希望这能有所帮助

谢谢-很高兴知道我走上了正确的道路！我仍然对分支感到有点困惑，我想这就是我合并头痛的原因。当我在Github for Windows中创建一个新分支时，我是否应该期望它在某处创建一个新目录？因为如果没有，那么我不是在编辑主分支中的代码吗？Git将所有内容存储在.Git文件夹中的一堆增量中。因此，当您创建一个新分支时，就好像您正在处理主/克隆分支的副本。但它们都在同一个文件夹中（提交一些更改并翻转分支，然后重新打开文件以查看）。注意你签出了哪个分支，因为开始写一堆东西很容易，忘记了你没有切换分支，你最终承诺使用master而不是feature分支。这就是藏书非常方便的地方。很抱歉没有尽快接受这一点作为我问题的答案，我似乎错过了你上次回答我所有问题的评论。非常感谢！