git: check out a tag, modify something, then tag it again

Question

I feel like I should know this, but I'm getting confused.

I forked a repository on github. What I need is to checkout a tag (called 'v1.0.5'), modify a statement on a file, re-tag that state with a new tag called '1.0.5' (without the 'v'), then do the same changes to master.

Let me be clearer. I'm changing EightMedia's Hammer.js from a named AMD module to an anonymous one.

the only file I have to change is src/outro.js. The file doesn't change from tag v1.0.5 to HEAD.

I want to change

// requireJS module definition
if(typeof window.define === 'function' && window.define.amd) {
    window.define('hammer', [], function() {
        return Hammer;
    });
}

to

// requireJS module definition
if(typeof window.define === 'function' && window.define.amd) {
    window.define(function() {
        return Hammer;
    });
}

What I want is: checkout v1.0.5, change that file, and push the repo in a way that I have a tag 1.0.5 that comprises the exact content of v1.0.5, plus the changes. The tag must be pushed to remote.

Then, checkout master, change the file again and push it again to master.

I'm quite lost when checkout v1.0.5 and I get in the detached HEAD state. After committing, where do I push the modifications? And how can I tag them and push tags to remote?

Answer 1

First, checkout using the original tag:

git checkout v1.0.5

This will put you in detached HEAD state - your commits won't go to any branch in particular. This sounds like what you want!

Now, make your changes, stage them, and commit.

git commit -a -m "Commit message"

You're still in detached HEAD state, but you're at a new commit - the one that has both the changes and history you want. So tag it!

git tag 1.0.5

To push back to the remote (assuming yours is still named origin):

git push origin 1.0.5

This will push the tag itself (1.0.5) as well as all the necessary commit history it points to.

Note that your change won't be included anywhere other than this tag. Based on your question, I think that this is what you want, but if you do need to merge back to master, you can follow with:

git checkout master
git merge 1.0.5

Answer 2

When you checkout a tag, you are automatically put into 'detached HEAD' state, since tags are immutable and shouldn't move. When you make the changes and then commit them, they don't go on any branch or tag – the only reference you have to the commit is the current HEAD pointer.

To make working a bit easier, you can create a temporary branch to work on.

git checkout -b tmp v1.0.5

You can create a new tag which points to the current commit with git tag 1.0.5 (this will tag the new commit and its history).

Then, instead of re-doing the changes on master, simply merge the newly created commit/tag into the master branch

git checkout master
git merge 1.0.5

Answer 3

Because you are trying to create an alternate history. Git creates a history based on the state of the entire repository, not just one file. If you want to make a change to a previous commit the normal way is to create a branch

git checkout -b newbranch v1.0.5

make your changes on the branch, then tag

git tag 1.0.5