0

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?

Zibbobz
  • 725
  • 1
  • 15
  • 41

1 Answers1

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

erik258
  • 14,701
  • 2
  • 25
  • 31
  • Thank you for the prompt response! I'm very new to GIT and GOGS, so I was a little hesitant to do this - but I'm glad I'm on the right track. – Zibbobz Oct 28 '19 at 13:51
  • I'm having some problems with this method - even when I check out the commit indicated, when I start working on it in Rational Developer, I'm seeing changes made *after* that Commit - Is this normal? Or is this an indication that I've done something wrong? – Zibbobz Oct 28 '19 at 17:00
  • 1
    No, you shouldn't see commits after `abc123f` until you switch over to master on step 7. `git log` might help provide some insight into which commits are in which history. – erik258 Oct 28 '19 at 17:07
  • I think I figured it out - if I create my workspace before checking out and creating the branch, it seems like my workspace still references the Master branch no matter what I do. So I simply created a new workspace. – Zibbobz Oct 28 '19 at 17:23
  • sounds like something Rational Developer is (rather irrationally) doing – erik258 Oct 28 '19 at 17:53
  • It's not entirely a great developer tool honestly - but it's what we're stuck using in-house. Regardless, I don't think there's any answer that could actually add to this beyond what you've already suggested, so I'm going to accept yours - thank you for the help. :) – Zibbobz Oct 28 '19 at 18:48