Git usage: "inserting" commits prior to HEAD

Question title might be meaningless, but I tried. :)

Here's开发者_开发技巧 my situation:

I have a repository with a single branch (master). (From that repository, when I "ship" builds, I add a tag at the commit that represents the shipped build, so I can get back to it.)

If I look at the timeline of commits, let's say it seems like this:

Start ----------> A --> HEAD

Where "A" is some commit in the recent past, but prior to HEAD. I'd like to "ship" a build that omits all of the changes since A. But I'd also like to make one or two tweaks to that version of the tree before shipping it. What I'm trying to do conceptually is rollback to point A, commit a couple changes, and then after shipping that, re-apply all the diffs that go from A --> HEAD, which would bring me back up to date and include the couple tweaks I made to A as well.

That's what I'd like to do conceptually. I'm not sure how to think about the best way of achieving this with git. Could someone offer some thoughtful guidance here?

Thanks!

git checkout -b release_A A; will give you a branch to play around with based off that release. (Assuming it is tagged release_A -- you can also use sha1sums to refer to particular commits).

Hack and git commit creating new commits.

git tag release_A_2 so you have a tag for this release.

Then choose exactly one of the following:

1. git rebase A master or git checkout master; git rebase A
2. git checkout master; git merge A

In either case, you may optionally follow with git branch -d A to eliminate the branch you're no longer using.

Choice 1 will do exactly what you ask. However, it's generally a bad idea if anyone else has used this branch for anything. Depending on your setup this might be what you want.

Choice 2 won't actually change the history -- all the commits represent actual history. Instead it will incorporate the changes in that branch into master. Merges often have a reputation for being painful, but this git should be about as smart as in case 1. If you have tagged or released anything since release_A, I strongly recommend using this method as it means those remain reproducible.

You can literally do what you're asking with git rebase -i. Commit your new changes, then use rebase -i to move them around.

However, if you have ever shared that tree with anyone it would be better not to replace those intermediate versions and instead do something like git checkout -b release_A A and then make your changes on that branch. You can then git merge or git cherry-pick them back onto your master.