0

In my new company we use a master - develop - feature git workflow with a detail that looks a little weird to me:

We don't use release branches, instead develop is merged to master only once per release (squashed) with a commit message containing the release changelog which is unbeliebable important to my colleague..

What happened is that he fixed up a master merge commit (just fixed the commit message) and force-pushed this rewritten commit. What we can't figure out is how to proceed from this point.

I don't think so but is there any way to work on without:

  • Adding additional commits to master
  • Rebasing develop onto master as this results in losing the whole develop history
  • Resetting the last master merge commit and merging the whole release again
hossi
  • 85
  • 6
  • It sounds almost as if you have a release branch, but it's called `master` and your `master` is called `develop`. – Joachim Sauer Jan 29 '20 at 09:44
  • Well, true but than there is just a single release branch, not one for each release.. – hossi Jan 29 '20 at 09:45
  • I see ... that might become an issue if you want to release a 2.1 once 3.0 was released ... I think you *need* to start creating release branches then, but you might get away with only creating them once a 2.1 is needed (i.e. make a release_2 branch starting from the commit for the 2.0 release). – Joachim Sauer Jan 29 '20 at 09:48
  • This is a pretty reasonable setup in a Continuous Delivery setup where master is released to prod. GitFlow style without release stabilization. It's just that the force us should NEVER have happened. I would have been better to have undone that merge commit on master and then have merged the develop into master again. Now my guess is your best path is to merge that forced commit on master back into develop (you can probably resolve as keep-mine on everything) and then cherrypick any additional hotfixes in master to develop. – jessehouwing Jan 29 '20 at 10:01
  • It is not intended to publish maintenance releases for older versions so this should not become an issue. After 3.0 was releases there won't be any version 2 update. – hossi Jan 29 '20 at 10:02
  • @jessehouwing sorry about the ambiguity.. I wrote about reverting the last master merge commit but what ia actually meant was deleting (resetting) it. Thats one possiblity but I was looking for a different solution. I already tried to merge master back to develop but afterwards the next merge from develop to master contained all the previous release commits again. What I didn't try was cherry-picking as you described so I will try this. – hossi Jan 29 '20 at 10:09
  • Just read your comment again.. There are no additional hotfixes so there is nothing else todo.. Looks like I need to convince my colleague that additional commits on master are fine. If I can't we probably need to stick to the way resetting the merge and doing it again.... argh – hossi Jan 29 '20 at 10:12
  • I am not sure I understand what the problem is here. You merged a squashed copy of develop onto master, and then he amended that commit to fix a problem with the commit message. Then what? Can't you continue working? What kind of problems are you encountering here? – Lasse V. Karlsen Jan 29 '20 at 11:50
  • Following scenario: develop: `C1 + C2` -> squash merge to master: `M` -> ammended changes to merge commit master: `M*` -> merge master into develop `C1 + C2 + M*` -> next feature landed on develop `C1 + C2 + M* + C3` -> next merge to master contains C1, C2, C3 – hossi Jan 29 '20 at 12:19
  • Doesn't that situation exists even if you don't amend the merge commit and merge to develop? I mean, you squashed develop and put the commit onto master, there's no merge relationship between master and develop is there? So git doesn't understand that the commits doesn't need to be included, but there should be no *changes* to merge, because master already contains most of those from previous squashes. – Lasse V. Karlsen Jan 29 '20 at 12:31
  • You shouldn't threat amend as way to do hotfixes, you sholuld do hotfix as separate commit on master, then merge it to develop. – Leszek Mazur Jan 29 '20 at 12:33
  • @LasseV.Karlsen yes this should be the same even w/o ammending which means that I can't merge master into develop. I also can't rebase develop onto master and there is nothing I could cherry-pick to solve this. Looks like i really need to convince my colleague to adapt the workflow.. – hossi Jan 29 '20 at 12:58
  • If you squash a branch onto another you're not merging. After this, if you intend to keep working on the original branch, the one you squashed, you **will** have issues down the line. You should throw away that branch and start a new one from master. See [this question](https://stackoverflow.com/questions/22593087/merging-a-branch-of-a-branch-after-first-branch-is-squashed-when-merged-to-maste) for more information. – Lasse V. Karlsen Jan 29 '20 at 13:42

2 Answers2

1

If you want to amend remote commit, you must:

  1. Reset remote master branch to state before merge
  2. Amend local merge
  3. Push to remote repository
Leszek Mazur
  • 2,443
  • 1
  • 14
  • 28
0

You can commit your local changes to local git repository and then pull master branch change. if there are merge conflict, fix those in local branch and commit and push to remote branch.

techzone4all
  • 123
  • 2
  • 10