Git flow initial commit

Question

I've created some new project using git-flow. Basically, I've done some coding, then I wrote those exact git commands:

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

Well, I would suppose to see two commits laying on my feature/Argparsing branch. I go over to my remote repository on GitHub and I see this:

So in the second commit message, I added Initial commit to stress the point that it was the first commit I made. But well, I guess I didn't have to do that since git-flow firstly added a separate Initial commit for me.

And as you can see, the commit is empty:

So my question here is: I guess it is a desirable behavior, so then does it only happen, when I actually start the repo with a feature or is it always like this? And by the way: 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?

Answer 1

does it only happen when I actually start the repo with a feature or is it always like this?

The initial empty commit happens as part of git flow init if there is no HEAD. That would be normal if you're creating a brand new repository.

Once upon a time rebasing the first commit in a repository wasn't well-supported so many developers got in the habit of creating an initial empty commit via git commit --allow-empty. The --root argument to git rebase, which was added in Git version 1.7.12, made this process less necessary though starting with an empty commit can be a hard habit to break. I still do it today.

Since the most recent commit on nvie/gitflow was in September, 2012, roughly the same time that the --root argument was added to git rebase, it's no surprise that this tool retains the old best practice.

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?

That really depends on your use case, but I interpret the original model to say that new work should be done in a feature branch (git flow feature start) and then finished (git flow feature finish).

The model doesn't actually say very much about pushing changes to a central location, which also makes sense since Git is a distributed version control system, designed to work with arbitrary remotes (or none). If you're using GitHub (you've included that tag so I'll assume you are) it probably makes sense to push your changes.