I'm working with a repository that in theory should be following the Gitflow Workflow (see A successful git branching model by Vincent Driessen). However, the initial commit on the repository was made on the develop
branch and there is no master
branch to be seen. It's nearing release time and I need to create a master
branch that reflects the production-ready state of the project which should've been there from the start. Keep in mind that the develop
branch has multiple feature branches coming off of it. The repository is entirely local and hasn't been pushed.
My idea was to create an orphan branch master
and rebase the develop
branch onto it, but I don't know how I'd go about doing that.
So, how can I create the master
branch as if it was created from the start?
Update: In my case, the first commit on develop
is not a commit that should be considered suitable for production, so using this as the initial master
commit would be unwise. The reason that the project is in this state is because it was originally not using a VCS when it was decided to use Git.
To rebase, make sure you have all the commits you want in the rebase in your master branch. Check out the branch you want to rebase and type git rebase master (where master is the branch you want to rebase on).
After some fiddling, this is what I came up with. This is a simpler, manual approach to VonC's answer.
Let's assume you have a branch develop
which contains the initial commit of your repository, and you'd like to rewrite history such that a master
branch contains the new initial commit instead.
First off, if the inital commit on your develop
branch is suitable as the initial commit on the new master
branch, then you can simply create the master
branch there and you're done:
$ git branch master <sha1-of-initial-commit-on-develop>
If you don't have that luxury, then you'll need to create a new empty commit that will serve as the initial commit of master
.
# Create the new master branch
$ git checkout --orphan master
# Clear the working directory (we want the initial commit to be empty)
$ git rm -rf .
# Create the initial commit on master
$ git commit --allow-empty -m "Initial commit"
# Rebase the entire develop branch onto the new master branch
$ git rebase --onto master --root develop
If there were any branches coming off of the develop
branch, they would've been "majorly messed up". This is because those branches (we'll call them topic branches) are still pointing to the old develop
branch before it was rebased. If you had no branches coming off of the develop
branch, then you're done.
Each topic branch is going to have to be rebased onto the new develop
branch. To do this, we're going to follow the steps outlined in another question (Git: How to rebase to a specific commit?). For each topic branch, follow these steps.
Replace <common-ancestor>
with the sha1 of the commit on the newly created develop
branch where the topic branch should branch off of.
$ git branch temp <common-ancestor>
$ git checkout <topic-branch>
$ git rebase temp
$ git branch -d temp
And that's it! Keep in mind that you should not rebase on a branch that you're collaborating on with someone else.
Ideally, you would need to rewrite the full history of dev
by adding a commit at the start:
# remember the first dev commit (before rebase)
git branch tmp $(git rev-list --max-parents=0 HEAD)
# first you need a new empty branch
git checkout --orphan master
git rm -rf .
# then you apply the same steps
git commit --allow-empty -m 'root commit master'
git rebase --preserve-merges --onto master --root dev
However, as illustrated in "Rebasing a branch including all its children", that would leave all the feature
branches pointing at their old dev
origin (before rebase).
git branch --contains tmp | \
xargs -n 1 \
git rebase --committer-date-is-author-date --preserve-merges --onto master tmp^
That is: any branch that was accessible from the old dev
first commit (tmp
) needs to be rebased on master
: any common commits already rebased on master won't be repeated. That will recreate the commits from the feature
branches, from the new (rebased) dev
branch.
Original answer:
You could simply have created the master
branch from the first commit of the dev
branch.
git branch $(git rev-list --max-parents=0 HEAD) master
(See "How to reference the initial commit?")
That means the first commit done on dev
is also considered part of the master
, which isn't entirely accurate, but easier than to rewrite the entire history of dev
.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With