While migrating code between version control systems (in my case SourceGear Vault to Git using an open-source c# program called vault2git), it’s sometimes necessary to pre-populate the first commit in the target system.
This yields an empty commit (
git commit -m "initial commit" --allow-empty) with a timestamp of today, which is chronologically out of order of the incoming change set migration.
After completing the migration, the second commit is actually the commit which I’d like to be the root.
It took me a while to figure this out, but thanks to
Greg Hewgill on Stack Overflow, I was able to replace the first commit of my branch with the second commit (and subsequently update the SHA1 hashes of all child commits) using this command:
git filter-branch --parent-filter "sed 's/-p <the__root_commit>//'" HEAD
So, You’ve developed this great new feature and you’re ready to submit the code for inclusion into the project. You hit “pull request,” and patiently wait for feedback.
Then it happens.
Someone says “Can you merge this into [insert parent branch name here’]. You get a sinking feeling in your stomach, and say “oh no! now I have to make all of my changes over again from that branch.
Never fear, this is what rebasing is for!
In this case, you need to tell git to take the commits you’ve added, and play them back against a different branch. The process goes something like this:
git rebase --onto master myNewFeatureBranch~1 myNewFeatureBranch
If all goes well, you’ll end up in the same branch, all of your changes will be intact, and the result of (diff to master) will be only your changes!!!
Also Collapse commits: http://stackoverflow.com/questions/6884022/collapsing-a-group-of-commits-into-one-on-git