Git 流程初始提交

Question

我使用git-flow. 基本上，我已经完成了一些编码，然后我编写了这些确切的git命令：

git flow init (and a bunch of enters)
git remote add origin <my_repo_address>
git flow feature start Argparsing
git add .
git commit -m "<message1>"
git rm tests/*
git commit -m "deleted unused stuff"
git flow feature publish

好吧，我想在我的feature/Argparsing分支上看到两个提交。我转到我的远程存储库GitHub，我看到了这个：

所以在第二个提交消息中，我补充说Initial commit，这是我做的第一次提交。但是，我想我不必这样做，因为git-flow首先为我添加了单独的初始提交。

正如你所看到的，提交是空的：

所以我的问题是：我想这是一种理想的行为，那么它是否只会在我实际启动具有功能的回购时发生，还是总是这样？顺便说一句：初始化git-flowrepo的正确方法是什么？我的意思是，在git flow init我应该提交（并且可能推送）某些内容之后develop，master还是应该继续处理我的功能，然后合并到develop，然后有一天到master？

Answer 1

它只在我实际启动带有功能的存储库时发生，还是总是这样？

初始空提交作为if no 的一部分发生git flow initHEAD。如果您要创建一个全新的存储库，那是正常的。

曾几何时，对存储库中的第一个提交进行变基并没有得到很好的支持，因此许多开发人员养成了通过git commit --allow-empty. --rootGit 版本 1.7.12 中添加的 参数使得git rebase这个过程不再那么必要，尽管从空提交开始可能是一个很难打破的习惯。今天我仍然这样做。

由于最近一次提交是在 2012 年 9 月，与将参数添加到nvie/gitflow的时间大致相同，因此该工具保留旧的最佳实践也就不足为奇了。--rootgit rebase

初始化 git-flow 存储库的正确方法是什么？我的意思是，在 git flow init 之后，我应该提交（并且可能推送）一些东西到开发或掌握上，还是应该继续开发我的功能，然后合并到开发，然后有一天掌握？

这实际上取决于您的用例，但我将原始模型解释为新工作应该在功能分支 ( git flow feature start) 中完成，然后完成 ( git flow feature finish)。

该模型实际上并没有过多提及将更改推送到中央位置，这也是有道理的，因为 Git 是一个分布式版本控制系统，旨在与任意远程（或无远程）一起使用。如果您正在使用 GitHub（您已经包含了该标签，所以我假设您是），那么推送您的更改可能是有意义的。