![]() That will recreate the commits from the feature branches, from the new (rebased) dev branch. 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. ![]() Git rebase -committer-date-is-author-date -preserve-merges -onto master tmp^ 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 rebase -preserve-merges -onto master -root dev Git commit -allow-empty -m 'root commit master' Git branch tmp $(git rev-list -max-parents=0 HEAD) 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 temp Īnd that's it! Keep in mind that you should not rebase on a branch that you're collaborating on with someone else. Replace with the sha1 of the commit on the newly created develop branch where the topic branch should branch off of. For each topic branch, follow these steps. To do this, we're going to follow the steps outlined in another question ( Git: How to rebase to a specific commit?). If you had no branches coming off of the develop branch, then you're done.Įach topic branch is going to have to be rebased onto the new develop branch. This is because those branches (we'll call them topic branches) are still pointing to the old develop branch before it was rebased. If there were any branches coming off of the develop branch, they would've been "majorly messed up". # Rebase the entire develop branch onto the new master branch $ git commit -allow-empty -m "Initial commit" # Clear the working directory (we want the initial commit to be empty) 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. 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.įirst 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 This is a simpler, manual approach to VonC's answer. 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.Īfter some fiddling, this is what I came up with. 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. So, how can I create the master branch as if it was created from the start? 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. The repository is entirely local and hasn't been pushed. Keep in mind that the develop branch has multiple feature branches coming off of it. 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. ![]() However, the initial commit on the repository was made on the develop branch and there is no master branch to be seen. I'm working with a repository that in theory should be following the Gitflow Workflow (see A successful git branching model by Vincent Driessen).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |