CODEWITHSUNDEEP
gitgit-tag
user797963
user797963

Reputation: 3027

Git - how to keep a change in a tag, but revert the change in the branch that was tagged?

I have a Jenkins job that does the follow steps.

  1. Checkout release branch
  2. Modify a few files on the branch
  3. Commit modified files locally, but do not push
  4. Tag the branch
  5. Checkout the tag
  6. Build

As you can see from step 3, the modified files should not be pushed back to master, they should only exist on the tag that was used for the build.

Since Git tags are just a pointer to a commit, I have to commit the modified files before I tag, but then I do not want the modified files to be pushed back to origin.

The modified files should only exist in the tag for the build. I guess my question really is,

should I be cutting a build branch from the release branch, modifying the files, committing, tagging the branch, pushing the tag, and throwing away the build branch?

Or,

follow the existing process and revert the commit that modified the files on my local branch of the release branch, and push that?

Upvotes: 0

Views: 611

Answers (3)

whoisj
whoisj

Reputation: 388

Assuming you haven't pushed the branch you can use git rebase -i to selectively remove the commits you no longer want. Commits referenced by a tag will survive so long as the tag survives.

If you have pushed the branch, then just git revert. Reverting commits actually adds new commits, your old commits will remain unchanged.

Upvotes: 0

poke
poke

Reputation: 387667

That’s certainly a weird process you have there. I understand that you may have to do some pre-build steps that need to run in order for you to successfully build everything but it seems odd that these changes would have to be committed and pushed as a tag. If you have this need, it’s a sign that the pre-build process does some substantial changes (which you need to track), so maybe you should spend a bit of time to improve your build process instead so you no longer need this.

That being said, actually reverting that build-related commit, and as such impacting the normal history seems a bit messy. The build process, as weird as it is, should never impact the normal development flow, and adding commits in the history (one that patches something, and one that reverts the same thing) really doesn’t sound like a good idea. Especially since you theoretically can run into the situation where the build server pushes those commits and runs into conflicts—you don’t want that.

So I would just stick to keeping the branch as it is, and adding that pre-build commit temporarily and giving it a tag. As you correctly said, tags are just pointers to a commit, and branches are effectively the same, there is no need why you should affect a branch when you have a tag pointing to the commit already.

So essentially, what the build process would need to do is this:

# update remote and reset to the current release
git fetch origin
git reset --hard origin/release

# pre-build patching

# add and commit
git commit -a -m 'Build 1234 from 2015-05-28'

# create tag
git tag -a build-1234 -m 'Build 1234 from 2015-05-28'

# push the tag (only!)
git push origin build-1234

# build and ship

Note that I never talk about a branch there; you just ignore that you’re on one. While you do update it (as part of git commit), you never tell anyone about it, and only push the tag directly. And with the next build (assuming that you don’t throw away the environment completely with every build), you will get the newest changes from git reset --hard, throwing away your temporary commit (which is still being pointed at by that tag).

Upvotes: 1

user743382
user743382

Reputation:

You should do neither.

You shouldn't make the commit part of the branch if it isn't part of the branch.

Committing on the branch, and then undoing that, is needlessly complicated. It works, and gives the right results, but don't do the wrong thing first and then fix it up, if you can do the right thing right from the start.

Instead, don't check out the branch. Check out the commit the branch points to. If you want to check out using the branch name, a simple way is git checkout branch~0. This leaves you with a detached HEAD, not attached to any branch. You can then modify the files, create a commit, tag that, and push the tag.

Upvotes: 1

Related Questions