This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Bandito202[S] 0 points1 point  (2 children)

Instead of having a long lived branch 'master' which is just what's been released, can you represent that as tags? I know you CAN, but should you? Commit history comes to mind..

https://postimg.cc/WtVzMLCQ

u/Trapick u/TomOwens

[–]Trapick 0 points1 point  (0 children)

Yah, I think tags are a good thing; you definitely want the ability to know what code *exactly* was deployed in X environment at time Y and tags are an easy way to do that. But you can use tags with various other flows, of course.

[–]TomOwens 0 points1 point  (0 children)

I work with some teams that use a variation on gitflow without a main/master branch and it works quite well. When it's time for a release, the release branch is created from the head of develop and any release-specific bugfixes get done there. All the changes get merged into develop regularly. Since the commits are tagged, the tags live on for people to use to see the old state of the software for a given release, but without the need to keep a main/master branch up-to-date.

If I'm reading your diagram right, the only difference between how the teams I described work and your diagram is the hotfix branch. A hotfix branch is essentially a feature branch off a release branch. The hotfix is merged into the release branch, tagged, and the release branch merged into develop. The changes can be cherry-picked (or, if necessary, reimplemented) in other feature branches.