Let\'s say I am about to implement 3 different features in 3 different files (fileA, fileB an fileC) for a new project of mine.
I thought I\'d just need to add my (c
I always init branch by commiting an emptyfile:
touch a
git add a
git commit -m'init'
then it create branch "master" automatically. After that you can delete the file 'a'.
You can do an empty initial commit with:
git commit --allow-empty
And then you can create your branches as you like.
Git represents branches as pointers to the latest commit in that branch. If you haven't created a commit yet, there's nothing for that branch to point to. So you can't really create branches until you have at least one commit.
Git represents commits as reference to one or more parent commits (or an all-zeros parent if this is the initial commit), a commit message and some other metadata, and a tree reference. A tree is basically a manifest of what is in each file in each directory. If your directory is empty, there is nothing to put in the tree. Now, it is actually possible to create an empty commit as your first commit; you can run git commit --allow-empty -m "initial commit"
. But that is not really a common way of using Git.
In Git, you're expected not to use branches unless you need them. There's no need to create several branches until you have some content to branch. If you create three branches at the very beginning of development, will you have no common ancestry between them? In that case, why not just create three repos? Or are you going to be updating all three of them in sync until they start to diverge? That seems like a lot of extra work to keep all of them up to date; you should just wait to create them until they need to diverge.
But if you want to use this workflow, you can run git commit --allow-empty -m "initial commit"
to create an empty initial commit.