How do I establish a new central git repository containing simplified commits from my local?

Question

I would like to replicate my local git repository, (recently converted from svn), into my empty github account. I do not want to show every detailed commit, but rather larger aggregated changesets corresponding to the historical releases of the software. I do want to retain the more detailed commits locally. All commits are currently on master, (originally svn trunk).

I assume that going forward this will be made easier by doing all local work on branches, and merging only the publishable changesets to master, which I can then push to github. But I'm not sure how to get the process started. Also, do I want to publish changes by pushing to, or by pulling from github?

Answer 1

There are a few ways I can think of to do this, but a simple one is this:

Let's say you want to use master as the publishable branch - this is a common usage - and you'd like to retain the existing commits on a branch called dev , where you'll do continued development. Let's presume you're at the head of the master branch to start.

$ git branch dev

That drops a dev branch where master is. Now you'll want to interactively rebase to squash commits together. The easiest way to keep everything together on the branch, while allowing yourself to work iteratively is to just rebase all the way back to the first commit:

$ git rebase -i <hash of first commit>

This will open an editor with a 'playlist' of the commits starting at the commit after the one you gave it (which is why many (like me) like to have an inconsequential (eg empty or just a readme) first commit - see here ). This list reads from the top down. Starting with the second entry you can change pick to squash or fixup (or just s or f ), which both merge that commit with the one before (above) it. The former keeps the earlier commit's message, the latter the later's.

If you can handle it, you could go through and mark everything in the entire project's history that you want to squash together this way, leaving 'pick' commits as anchors, and following each with any number of 'fixup' commits to be squashed into them. When done, save and quit, and watch the whole thing collapse into the aggregate commits you want. If it's too hard to know which ones to squash together in one go, just do the ones you know. You can always squash more in a future rebase, and you can even keep squashing commits into the same commit.

I would probably investigate the first handful of commits, figure out which ones I wanted to merge - eg 'the first 7' - then choose to reword the first in the interactive rebase, typing up the aggregate message there, and choosing fixup for the next 6. This would stop to let me put in a new (aggregate) message on the first one, then squash the next 6 into it, keeping that message. Then I'd investigate the next handful after that one to squash and repeat until done. It's a bit tedious, but pretty easy.

Note that this will create all new objects, but the dev branch will still be pointing to the old line, so you'll now have both the full history in dev, and the squashed history in master. Now you can develop on dev , and use git rebase --squash dev from the master branch to squash all of the new development into a single, new commit on top of master.