How to Create a branch off an old commit in our GOGs repository, push it to make a tag, then merge the change onto Master without losing our changes?

Question

Our team works on a legacy application and is relatively small and new to using GIT repositories to control our source code. We don't have a Git Master, and we really don't have any way of keeping our changes organized.

As a result, we've pushed some changes to our Master branch after making a successful release - only to find that release now needs a hot fix.

We don't want to push the changes we're working on for the next release - so ideally we want to:

1. Have one person pull the last commit (with a tag for our release) from GOGs
2. Make the change in the code to fix the bug in production
3. Push the change out and create a tag so our release team can deploy it
4. Merge that change onto our Master branch, so that our work for the next release isn't lost but the change for the fix is applied

This is our first time trying to make a live fix to the code - I've seen some suggestions but most of them involve basing it off of a developer branch that hasn't already been pushed. What can we do, as a group that has already pushed changes out to Master and want to apply a fix to an old push?

Answer 1

What you describe is basically correct.

1. Identify commit that's in production now. Let's say it's abc123f. It could also be a tag which works the same ad a commit (commit, branch, tag - all are refs. A branch is a moving target, but commit and tag ate immutable).
2. Within the repo, check out that commit : git checkout abc123f
3. Create your hotfix branch: git checkout -b hotfix-branch
4. Make changes, test, and commit.
5. Tag the commit you end up with and push the tag
6. Give tag to release team
7. git checkout master; git fetch --all; git pull to get the up to date master
8. git merge hotfix-branch followed by git push will add and push the hotfix into master upstream.

Remember you can always use git diff to compare branches to check your work and verify. I do this very often and you should too, as having confidence in your changes is a primary benefit if version control! 8