Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Git usage: "inserting" commits prior to HEAD

Tags:

git

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!

like image 709
Ben Zotto Avatar asked Jun 22 '26 04:06

Ben Zotto


1 Answers

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.

like image 110
wnoise Avatar answered Jun 25 '26 01:06

wnoise



Donate For Us

If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!