While helping a friend with a git problem today, I had to introduce a
branch that needed to be totally separate from the master
branch.
The contents of this branch really had a different origin from what
had been developed on the master
branch, but they were going to be
merged into the master
branch at a later time.
I remembered from reading John Wiegley's Git from the bottom up how branches are essentially a label to a commit that follows a certain convention and how a commit is tied to a tree of files and, optionally to parent commits. We went to create a parentless commit to the existing repository using git's plumbing:
So we got rid of all files in the index ...
$ git rm -rf .
... extracted directories and files from a tarball, added those to the index ...
$ git add .
... and created a tree object ...
$ git write-tree
(git-write-tree
told us the sha1sum of the created tree object.)
Then, We committed the tree, without specifying parent commits...
$ echo "Imported project foo" | git commit-tree $TREE
(git-commit-tree
told us the sha1sum of the created commit object.)
... and created a new branch that points to our newly created commit.
$ git update-ref refs/heads/other-branch $COMMIT
Finally, we returned to the master
branch to continue work there.
$ git checkout -f master
This seems to have worked as planned. But this is clearly not the kind of procedure I would recommend to someone who is just getting started using git, to put it mildly. Is there an easier way of creating a new branch that is entirely unrelated to everything that has happened in the repository so far?
Although the solution with
git symbolic-ref
and removing index works, it might be conceptually cleaner to create new repositorythen fetch from it
Now you can delete /path/to/unrelated
Found this script at http://wingolog.org/archives/2008/10/14/merging-in-unrelated-git-branches and it works very fine !
From Git Community Book:
If your existing content was already committed, you now (Git 2.18 Q2 2018) can extract it into its own new orphan branch, since the implementation of "
git rebase -i --root
" has been updated to use the sequencer machinery more.That sequencer is the one now allowing to transplant the whole topology of commit graph elsewhere.
See commit 8fa6eea, commit 9c85a1c, commit ebddf39, commit 21d0764, commit d87d48b, commit ba97aea (03 May 2018) by Johannes Schindelin (
dscho
).(Merged by Junio C Hamano --
gitster
-- in commit c5aa4bc, 30 May 2018)Sometimes I just want to create empty branch in project instantly then start doing work, I will just excute following command :
There is a new feature (since V1.7.2) which makes this task a little more high-level than what's in any of the other answers.
git checkout
now supports the--orphan
option. From the man page:git checkout [-q] [-f] [-m] --orphan <new_branch> [<start_point>]
This doesn't do exactly what the asker wanted, because it populates the index and the working tree from
<start_point>
(since this is, after all, a checkout command). The only other action necessary is to remove any unwanted items from the working tree and index. Unfortunately,git reset --hard
doesn't work, butgit rm -rf .
can be used instead (I believe this is equivalent torm .git/index; git clean -fdx
given in other answers).In summary:
I left
<start_point>
unspecified because it defaults to HEAD, and we don't really care anyway. This sequence does essentially the same thing as the command sequence in Artem's answer, just without resorting to scary plumbing commands.