How to manage feature changes during release cycle?

[Stefan Glienke 2002]

We used to do Git flow but recently changed to GitLab flow.

 

It basically goes like this:

14 hours ago, David Heffernan said:

All bug fixes are made on trunk and then merged cherry picked onto whichever release branches are supported. 

 

[Lars Fosdal 1791]

9 minutes ago, Mike Torrettinni said:

So, I do need to patch this branch,too? There is no other way?

Ref the chart I posted.  That patch or hotfix if you like can be spun off the release branch and committed and merged back into the release branch and the development branch.

I am fond of GitKraken here, because it supports GitFlow which simplify doing these things. 

[David Heffernan 2345]

3 minutes ago, Lars Fosdal said:

I am fond of GitKraken here, because it supports GitFlow which simplify doing these things. 

I don't really understand how tools can support specific workflows. Aren't workflows just conventions that you put on top of the vcs? I mean, I'm sure that I can do git flow, gitlab flow, github flow etc. with any tool.

[Lars Fosdal 1791]

9 minutes ago, David Heffernan said:

I don't really understand how tools can support specific workflows. Aren't workflows just conventions that you put on top of the vcs? I mean, I'm sure that I can do git flow, gitlab flow, github flow etc. with any tool.

They are.  GitKraken supports implements the GitFlow convention, simplifying the execution of that workflow.

 

[Mike Torrettinni 198]

31 minutes ago, Lars Fosdal said:

They are.  GitKraken supports implements the GitFlow convention, simplifying the execution of that workflow.

 

Aha, so this is GUI layer that helps with branching and merging, right? Does it introduce any different, better features, or just better visual presentation?

Like all these git tools Kraken, SourceTree, Fork.. are just GUI tools for Git (so you don't need to write command in cmd), right?

[David Heffernan 2345]

These tools are really useful, but they aren't a substitute for understanding the workflow.

[Edwin Yip 154]

4 hours ago, Attila Kovacs said:

Can we see a "branch" example with 10+ projects having own code, shared code, 10+ major 3rd party libs, tons of binary data, whatever I forgot to mention. Asking for a firend.

I bet you yourself are that friend of your own :D

[Fr0sT.Brutal 900]

I'm the only dev of my projects so I adopted some kind of Git workflow:

- Small changes fitting into single commit go directly to master

- Somewhat big features (requiring significant changes in multiple files) go to feature branches.

  * If they are finished quickly (no commits to master happen after starting feature branch), I merge into master without fast-forward to get nice-looking curve in history.

  * If a branch lasts for a while, sometimes I rebase it onto current HEAD - or -

  * Merge commits from master to feature branch (this is what all should do but I find multiple merges too confusing in history so I try to avoid them). More frequently I utilize cherry-picking which is very nice tool of distributing commits.

  * When a feature is ready, I rebase onto current HEAD and do clean merge.

 

I also use submodules for shared libs. This requires some self-discipline especially if you periodically modify these libs right from a parent project - this results in lots of fun when you have N different updates inside N different projects and got to merge them all into main repo and then update all these N submodules. I also came to a rule to commit changes in submodules into separate commits (without changes to parent project) just to separate things. What's good in submodules - you can always jump to any previous state including all deps and it will be buildable. Just don't forget to run "Update submodules" after switching

Edited September 28, 2021 by Fr0sT.Brutal

[Lars Fosdal 1791]

42 minutes ago, Mike Torrettinni said:

this is GUI layer that helps with branching and merging

Correct. 

Most UIs for git visualize branches and merges.

 

[Fr0sT.Brutal 900]

Btw: when actively working on a feature, I sometimes don't bother about decorating beautiful commits. I just commit stuff periodically, even non-buildable and incomplete with very short messages or just "tmp" message. When code starts looking more or less stabilized, I squash these temp commits into something nice looking and do actual commits that will remain in history

[Lars Fosdal 1791]

As long as what you push to the shared repository, compiles 🙂
It is very annoying if teammates commit code that doesn't compile. 

 

[Mike Torrettinni 198]

3 hours ago, Lars Fosdal said:

That patch or hotfix if you like can be spun off the release branch and committed and merged back into the release branch and the development branch.

Thanks, this means I need to implement bug fixes in both places. I kind of wanted to avoid this.

 

It's interesting how GUI tools branching flow from left and up, while a lot of images of git branching go from right and down.

[Lars Fosdal 1791]

I guess it is because conceptual explanations tend to look at time starting from the top, going down - while actual systems tend to show recent events on top, going back in time as you move downwards.

Ref. email inboxes, Windows Event Viewer, GitKraken, etc 😉 

 

For the graphical view, it also makes sense to have the main branch + longest living branches on the left, since the number of branches varies.

[Lars Fosdal 1791]

20 minutes ago, Mike Torrettinni said:

this means I need to implement bug fixes in both places. I kind of wanted to avoid this.

If you avoid this, one of the branches will be left unfixed. 
You always must fix it in both places.
The question really boils down to which model you use.

 

[Mike Torrettinni 198]

13 minutes ago, Lars Fosdal said:

I guess it is because conceptual explanations tend to look at time starting from the top, going down - while actual systems tend to show recent events on top, going back in time as you move downwards.

Ref. email inboxes, Windows Event Viewer, GitKraken, etc 😉 

 

For the graphical view, it also makes sense to have the main branch + longest living branches on the left, since the number of branches varies.

Yes and it make sense, up, down. Not sure why you would start diagram with main branch on right and draw to the left, seems odd.

Edited September 28, 2021 by Mike Torrettinni

[Fr0sT.Brutal 900]

2 hours ago, Lars Fosdal said:

As long as what you push to the shared repository, compiles 🙂
It is very annoying if teammates commit code that doesn't compile. 

Of course all these tmp commits live locally! This is one of killer features of Git, I can't imagine what I would do if I were on SVN

[David Heffernan 2345]

1 hour ago, Mike Torrettinni said:

Thanks, this means I need to implement bug fixes in both places. I kind of wanted to avoid this.

Not really, the vcs does the work. You fix the bug once and then push it onto whichever branches also need the fix. Irrespective of the workflow you are going to do the fix once, commit it, and then use the vcs to propagate that fix to wherever you choose.

[Mike Torrettinni 198]

1 minute ago, David Heffernan said:

Not really, the vcs does the work. You fix the bug once and then push it onto whichever branches also need the fix. Irrespective of the workflow you are going to do the fix once, commit it, and then use the vcs to propagate that fix to wherever you choose.

This is only true in very simple example, or where bug needs fixing in very obscure part of the code, untouched in the feature branch. As soon as you start changing the feature, it's highly unlikely the bug fix for old code could be applied also to the branch.

You need to have 2 implementation of bug fixing. Well, actually you could have fixed the bug already in the branch, unknowingly, while making changes.

[Mike Torrettinni 198]

3 hours ago, Lars Fosdal said:

Correct. 

Most UIs for git visualize branches and merges.

 

This looks pretty clean and quite disciplined development. I rarely have 2 scheduled changes in a row that I don't find something else to improve, change. So, simple 1 line descriptions are almost never an option, except build numbers which are logged and have detailed description of changes.

Edited September 28, 2021 by Mike Torrettinni

[David Heffernan 2345]

5 minutes ago, Mike Torrettinni said:

This is only true in very simple example, or where bug needs fixing in very obscure part of the code, untouched in the feature branch. As soon as you start changing the feature, it's highly unlikely the bug fix for old code could be applied also to the branch.

You need to have 2 implementation of bug fixing. Well, actually you could have fixed the bug already in the branch, unknowingly, while making changes.

I don't think so. If the bug is in the code for the new feature then you don't need to push it to the release branch because this new feature hasn't been released.

 

Of course you will sometimes be working on a feature that involves modifying existing code, and those modifications clash with a bug fix for released code. But if there is a clash then of course you have to fix it on the main dev branch, and then work out how to push that to any release/feature branches resolving conflicts. No workflow can avoid that.

 

I'm sure other people can chip in, but in my experience, the vast majority of bug fixes can be resolved and then pushed to release branches without conflicts needing to be resolved. 

[Der schöne Günther 316]

2 minutes ago, David Heffernan said:

but in my experience, the vast majority of bug fixes can be resolved and then pushed to release branches without conflicts needing to be resolved

I would absolutely agree unless @Mike Torrettinni also used a new feature as a motivation to drastically refactor parts that now needed bugfixing.

[Mike Torrettinni 198]

8 minutes ago, David Heffernan said:

Of course you will sometimes be working on a feature that involves modifying existing code, and those modifications clash with a bug fix for released code. But if there is a clash then of course you have to fix it on the main dev branch, and then work out how to push that to any release/feature branches resolving conflicts.

Correct. Perhaps is my personal quirk, but I don't like the situation when the feature bug is fixed in develop branch and I didn't fix or check for it in the feature branch. I just can't wait until the end to see if the merge will work and then work it out, I need to fix it right away, if possible. Most likely new feature branch will overwrite full feature code in develop branch, when ready.

 

1 minute ago, Der schöne Günther said:

used a new feature as a motivation to drastically refactor parts that now needed bugfixing.

Yes, you say 'drastically refactor' I say changing, improving a feature 🙂

[David Heffernan 2345]

1 hour ago, Mike Torrettinni said:

Perhaps is my personal quirk, but I don't like the situation when the feature bug is fixed in develop branch and I didn't fix or check for it in the feature branch. I just can't wait until the end to see if the merge will work and then work it out, I need to fix it right away, if possible.

I don't think you understand what we are saying.

 

On a feature branch you develop a new feature that hasn't yet been released. So if there is a bug in code that has been released it doesn't clash with your new feature, because the feature is new. So the scenario you describe basically doesn't arise. 

 

You asked for advice, and we all have experience of this. You don't. Which is why you asked. Just a suggestion. Perhaps our experience means something? 

 

Or perhaps I don't understand how you develop. Perhaps you really do rewrite your entire code base regularly. 

Edited September 28, 2021 by David Heffernan

[Mike Torrettinni 198]

10 minutes ago, David Heffernan said:

I don't think you understand what we are saying.

I think you missed the beginning of my statement where I agreed with you. All good, now.

 

@Lars Fosdal I found diagram flow from left going up. not as detailed as the other one, but at least the flow direction is not confusing to me.

 

https://www.bitsnbites.eu/a-stable-mainline-branching-model-for-git/

 

Edited September 28, 2021 by Mike Torrettinni

[Darian Miller 361]

From Dave Farley: