Git 流程初始提交
Git flow initial commit
我使用 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-flow 回购的正确方法？我的意思是，在 git flow init 之后，我应该将某些内容提交（并可能推送）到 develop 或 master 上，还是应该继续开发我的功能，然后合并到 develop，然后有一天 master?
does it only happen when I actually start the repo with a feature or is it always like this?
初始空提交happens as part of git flow init if there is no HEAD。如果您正在创建一个全新的存储库，那将是正常的。
曾几何时，rebase 存储库中的第一个提交 wasn't well-supported 因此许多开发人员养成了通过 git commit --allow-empty 创建初始空提交的习惯。 git rebase 的 --root 参数被添加到 Git 版本 1.7.12 中，尽管从空提交开始可能是一个很难改掉的习惯，但此过程的必要性降低了。我今天仍然这样做。
由于 most recent commit on nvie/gitflow 是在 2012 年 9 月，与 --root 参数添加到 git rebase 的时间大致相同，因此此工具保留了旧的最佳实践也就不足为奇了.
What is a proper way to initialize git-flow repo? I mean, after git flow init should I commit (and probably push) something onto develop or master or should I should continue working on my feature, and then merge to develop, and then someday to master?
这实际上取决于您的用例，但我将 original model 解释为新工作应该在功能分支 (git flow feature start) 中完成，然后完成 (git flow feature finish ).
该模型实际上并没有说太多关于将更改推送到中央位置，这也是有道理的，因为 Git 是一个分布式版本控制系统，旨在与任意远程（或 none).如果您正在使用 GitHub（您已经包含了该标签，所以我假设您是），那么推送您的更改可能是有意义的。
我使用 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-flow 回购的正确方法？我的意思是，在 git flow init 之后，我应该将某些内容提交（并可能推送）到 develop 或 master 上，还是应该继续开发我的功能，然后合并到 develop，然后有一天 master?
does it only happen when I actually start the repo with a feature or is it always like this?
初始空提交happens as part of git flow init if there is no HEAD。如果您正在创建一个全新的存储库，那将是正常的。
曾几何时，rebase 存储库中的第一个提交 wasn't well-supported 因此许多开发人员养成了通过 git commit --allow-empty 创建初始空提交的习惯。 git rebase 的 --root 参数被添加到 Git 版本 1.7.12 中，尽管从空提交开始可能是一个很难改掉的习惯，但此过程的必要性降低了。我今天仍然这样做。
由于 most recent commit on nvie/gitflow 是在 2012 年 9 月，与 --root 参数添加到 git rebase 的时间大致相同，因此此工具保留了旧的最佳实践也就不足为奇了.
What is a proper way to initialize git-flow repo? I mean, after git flow init should I commit (and probably push) something onto develop or master or should I should continue working on my feature, and then merge to develop, and then someday to master?
这实际上取决于您的用例，但我将 original model 解释为新工作应该在功能分支 (git flow feature start) 中完成，然后完成 (git flow feature finish ).
该模型实际上并没有说太多关于将更改推送到中央位置，这也是有道理的，因为 Git 是一个分布式版本控制系统，旨在与任意远程（或 none).如果您正在使用 GitHub（您已经包含了该标签，所以我假设您是），那么推送您的更改可能是有意义的。