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 首先为我添加了一个单独的初始提交。

如您所见，提交是空的:

所以我的问题是:我想这是一种理想的行为，那么它只会发生，当我实际启动带有功能的 repo 协议(protocol)时，还是总是这样？顺便说一句:什么是初始化 git-flow repo 的正确方法？我的意思是，在 git flow init 之后，我应该将某些内容提交(并可能推送)到 develop 或 master 上，还是应该继续开发我的功能，然后 merge 到 develop，然后某天 merge 到 master？

Answer 1

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 创建初始空提交的习惯. --root git rebase 的参数，它是在 Git 1.7.12 版中添加的，虽然从空提交开始可能是一个很难打破的习惯，但它使这个过程变得不那么必要了。我今天仍然这样做。

自 most recent commit在 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 是一个分布式版本控制系统，旨在与任意远程(或没有)一起工作。如果您使用的是 GitHub(您已经包含了该标签，所以我假设您是)，那么推送您的更改可能是有意义的。