2

As a preface, I want to say that git-flow will solve some of these problems. I would prefer to stick to using GitHub PRs to handle both feature and hotfix branches. I also prefer to rebase feature branches. I follow the mantra that every commit should have a full set of passing tests. If you merge a commit upstream, you cannot guarantee that all commits will have passing tests without re-running the tests on every commit.

I have branches PROD and DEV. PROD should always be upstream from DEV. If I have a fix that needs to go to PROD, here's what I would do:

  • branch off of PROD and create a fix -> commit X
  • merge X into PROD and release a new tag with git tag ... (merge with GitHub PR so that the fix can be reviewed)
  • branch off of DEV && git cherry-pick X then PR to DEV (no need to release a new tag here)

Now the problem arises with the last step. What if I forget the last step? How can I check to see if X' (the cherry-picked commit) is on DEV? What's the best way to keep PROD and Dev up-to-date, or at least see if they differ with cherry-picks?

I've played around with git log --cherry-pick DEV..PROD, but commit X is still showing up.

This article provides a couple good options but I'm trying to solve the scenario where I have to cherry-pick instead of maintaining another branch.

richardpringle
  • 796
  • 5
  • 22

2 Answers2

2

I found the answer to my own question. Obviously, this is matter of opinion as there are many potential solutions, but here's mine:

I am now using git tags to freeze off my PROD branch. With every new release, I update the minor version of my code-base with a new git-tag. If I find a bug that needs to be fixed on an upstream tag, I make my changes to DEV (the leading branch) then cherry-pick all changes to PROD. For Example:

$ git checkout DEV && git checkout -b HOTFIX
$ # commit the changes
$ git checkout PROD # HEAD is at v1.2.0
$ git cherry-pick ..HOTFIX
$ git tag v1.2.1

Above is the simple version of what I do, not taking GitHub into account.

Instead, what I do with GitHub is use Jenkins and the ghprb plugin to PR a HOTFIX branch to into PROD and then run a release script from Jenkins. Anytime I PR PROD, another job runs to compare PROD against dev with the following:

$ git log --cherry-pick --no-merges --right-only DEV...PROD

If any diff shows up, I send a notification (I use a Slack plugin, but I'm sure you could use something else that's equally as effective).

That's it! It was actually pretty simple to set everything up. If you (the reader) see any flaws with what I'm doing, please leave a comment, not only so I can fix my answer, but fix my actual set-up as well!

richardpringle
  • 796
  • 5
  • 22
0

I think your best solution here is to take advantage of the commit message. Include some hotfix identifier (like a JIRA ticket number or a version) in the commit message so that you can search and compare it later.

Any other solution is going to be faulty. For example, say that you have a nice clean hotfix that gets merged into your PROD, but when you attempt to cherry-pick it into DEV you get a conflict. You resolve it, but now the diff for your cherry-pick commit is no longer the same as your PROD commit. The commit message is going to be the best way to tie those two commits together.

Bug tracking tools that integrate with your CVS can help as well, by tracking which "versions" a ticket should be targeted at and then tracking one branch for each version. This will let you know if a ticket is missing a branch, or if the branch was never merged, etc.

JDB
  • 25,172
  • 5
  • 72
  • 123
  • thanks for the answer but what I'm looking for is something more like this command `git log --cherry-pick DEV..PROD` only it seems like that command isn't behaving as expected: https://stackoverflow.com/questions/15807522/why-is-git-log-cherry-pick-not-removing-equivalent-commits – richardpringle Jan 23 '18 at 22:27
  • Update on that, I need to add the other `.`, `git log --cherry-pick --right-only DEV...PROD` worked exactly as expected. – richardpringle Jan 29 '18 at 20:49
  • to get around the issue of changing diffs, I just make sure that I commit on the upstream branch and am notified of any changes (see my answer). If there's a case where the diffs aren't the same, I get a notification and look the culprit commits. Conflicts in my codebase are rare-enough that looking into the individual times that this issue pops up is not a problem. I also create a new branch when this does come up so that the offending commits don't stay in my history forever. – richardpringle Jan 29 '18 at 21:23