So, we're going the gitflow way [1][2]. However, when I looked at our bitbucket repositories today, only the libtaskotron branch uses 'develop' branch, all other projects use only 'master' branch - even taskotron-trigger or task-rpmlint. Does it mean we use gitflow only for libtaskotron? Or is it a repo author's choice? I'm a bit afraid it's going to be chaos - you'll need to inspect available branches every time to decide against which branch to base a patch or into which branch to commit.
I wonder, could we use gitflow but drop the idea of misusing 'master' branch name for something else than usual?
Because that's the main grievance I have against gitflow, otherwise it's a neat workflow. I believe gitflow should have never used master for something else, it should have used 'stable' branch instead for stable releases (i.e. 'gitflow/master' should have been 'traditional/stable' and 'gitflow/develop' should have been 'traditional/master'). All the tools (and most of the users) expect 'master' to be the main development branch. Git init creates master by default. Git clone checks out master by default. Github/Bitbucket displays master by default. Arcanist merges to master by default. Users clone and send patches against master by default. Usually you can adjust the tools, but what's the benefit? Why all the mess? I simply don't get it. (Also notice people criticizing it under one of the most famous blogposts [3] and offering the same suggestions as I do).
So, if we use gitflow with traditional master meaning, and stable branch for stable releases, I see it as a win-win. Regardless whether that particular repo uses gitflow or not, you known what branch to work with automatically. You don't need to change configuration in your tools. Everything works, and you get the benefits.
If you have installed the gitflow RPM package (it adds the "git flow" subcommand), it asks you initially what naming conventions you like to use. So if you like that tool, there's no problem using it with the traditional 'master' meaning.
[1] https://fedoraproject.org/wiki/User:Tflink/taskotron_contribution_guide [2] http://nvie.com/posts/a-successful-git-branching-model/ [3] http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/
----- Original Message -----
From: "Kamil Paral" kparal@redhat.com To: "Fedora QA Development" qa-devel@lists.fedoraproject.org Sent: Friday, January 24, 2014 4:03:40 PM Subject: gitflow and branch naming conventions
So, we're going the gitflow way [1][2]. However, when I looked at our bitbucket repositories today, only the libtaskotron branch uses 'develop' branch, all other projects use only 'master' branch - even taskotron-trigger or task-rpmlint. Does it mean we use gitflow only for libtaskotron? Or is it a repo author's choice? I'm a bit afraid it's going to be chaos - you'll need to inspect available branches every time to decide against which branch to base a patch or into which branch to commit.
I wonder, could we use gitflow but drop the idea of misusing 'master' branch name for something else than usual?
Because that's the main grievance I have against gitflow, otherwise it's a neat workflow. I believe gitflow should have never used master for something else, it should have used 'stable' branch instead for stable releases (i.e. 'gitflow/master' should have been 'traditional/stable' and 'gitflow/develop' should have been 'traditional/master'). All the tools (and most of the users) expect 'master' to be the main development branch. Git init creates master by default. Git clone checks out master by default. Github/Bitbucket displays master by default. Arcanist merges to master by default. Users clone and send patches against master by default. Usually you can adjust the tools, but what's the benefit? Why all the mess? I simply don't get it. (Also notice people criticizing it under one of the most famous blogposts [3] and offering the same suggestions as I do).
I am not against the idea but just a note, we'd need to change this for projects that have been using gitflow/develop style branch (blockerbugs) as well.
Thanks, Martin
So, if we use gitflow with traditional master meaning, and stable branch for stable releases, I see it as a win-win. Regardless whether that particular repo uses gitflow or not, you known what branch to work with automatically. You don't need to change configuration in your tools. Everything works, and you get the benefits.
If you have installed the gitflow RPM package (it adds the "git flow" subcommand), it asks you initially what naming conventions you like to use. So if you like that tool, there's no problem using it with the traditional 'master' meaning.
[1] https://fedoraproject.org/wiki/User:Tflink/taskotron_contribution_guide [2] http://nvie.com/posts/a-successful-git-branching-model/ [3] http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/ _______________________________________________ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
On Fri, 24 Jan 2014 10:03:40 -0500 (EST) Kamil Paral kparal@redhat.com wrote:
So, we're going the gitflow way [1][2]. However, when I looked at our bitbucket repositories today, only the libtaskotron branch uses 'develop' branch, all other projects use only 'master' branch - even taskotron-trigger or task-rpmlint. Does it mean we use gitflow only for libtaskotron? Or is it a repo author's choice? I'm a bit afraid it's going to be chaos - you'll need to inspect available branches every time to decide against which branch to base a patch or into which branch to commit.
There are multiple reasons for this: 1. gitflow probably isn't appropriate for tasks. if we're cloning the repo with automation, the only thing that I can see using branches for is to differentiate between releases
2. trigger was pushed up as proof-of-concept code and I forgot to add a 'develop branch'
I wonder, could we use gitflow but drop the idea of misusing 'master' branch name for something else than usual?
Because that's the main grievance I have against gitflow, otherwise it's a neat workflow. I believe gitflow should have never used master for something else, it should have used 'stable' branch instead for stable releases (i.e. 'gitflow/master' should have been 'traditional/stable' and 'gitflow/develop' should have been 'traditional/master'). All the tools (and most of the users) expect 'master' to be the main development branch. Git init creates master by default. Git clone checks out master by default. Github/Bitbucket displays master by default. Arcanist merges to master by default. Users clone and send patches against master by default. Usually you can adjust the tools, but what's the benefit? Why all the mess? I simply don't get it. (Also notice people criticizing it under one of the most famous blogposts [3] and offering the same suggestions as I do).
I disagree with you here - master is the main branch but it isn't necessarily the main "development" branch. I see it as folks cloning a repo and wanting it to work, therefore having stable release code in master makes more sense than having the stable release code in some non-default branch.
I guess it comes down to who we want to prioritize as the "default" consumer.
So, if we use gitflow with traditional master meaning, and stable branch for stable releases, I see it as a win-win. Regardless whether that particular repo uses gitflow or not, you known what branch to work with automatically. You don't need to change configuration in your tools. Everything works, and you get the benefits.
Until we get folks who are used to the default gitflow config (note that infra is using it for many of their projects) and confusion may start.
If you have installed the gitflow RPM package (it adds the "git flow" subcommand), it asks you initially what naming conventions you like to use. So if you like that tool, there's no problem using it with the traditional 'master' meaning.
I still disagree with you about the "traditional" meaning of master. While many projects seem to use master for dev, I think most of those projects don't have separate dev and release branches.
That being said, I'm not completely against this idea if there are enough other folks who are +1. I'm still -1 on the idea but I could live with it :)
If we do change the defaults for gitflow, let's do it soon, though.
Tim
I disagree with you here - master is the main branch but it isn't necessarily the main "development" branch. I see it as folks cloning a repo and wanting it to work, therefore having stable release code in master makes more sense than having the stable release code in some non-default branch.
I think 'master' should always contain the latest _working_ code. If we want to take something apart and break it, it should be developed in a feature branch. And functional tests should be run on every commit to master. (I know, that's the ideal state, but it seems we're going the right way).
If somebody wants a stable code base, he usually doesn't clone master, does he? He checks out a stable tag instead.
I guess it comes down to who we want to prioritize as the "default" consumer.
What are the choices? I think the most common consumer for master branch is a developer or, alternatively, an experienced bleeding-edge user.
So, if we use gitflow with traditional master meaning, and stable branch for stable releases, I see it as a win-win. Regardless whether that particular repo uses gitflow or not, you known what branch to work with automatically. You don't need to change configuration in your tools. Everything works, and you get the benefits.
Until we get folks who are used to the default gitflow config (note that infra is using it for many of their projects) and confusion may start.
If there's no develop branch, what confusion do you refer to? I see gitflow as a set of SOPs - branching procedures and naming conventions. You can easily follow it and nobody doesn't even need to recognize that you use gitflow. You just name your feature branches 'feature/XX', release branches 'release/XX', etc. I'm not sure how we can confuse people, if our repo consists of 'master' and a bunch of 'feature/' branches.
If you have installed the gitflow RPM package (it adds the "git flow" subcommand), it asks you initially what naming conventions you like to use. So if you like that tool, there's no problem using it with the traditional 'master' meaning.
I still disagree with you about the "traditional" meaning of master. While many projects seem to use master for dev, I think most of those projects don't have separate dev and release branches.
They don't and they should, but I don't see this related to develop/master naming issue.
If I understand you correctly, you would like 'master' to contain more stable code than what is usual for a large number of existing projects - broken code, incomplete features, failures to even compile, etc. And that is a nice goal indeed. I think we can achieve that either by: 1. strong development practices - feature branches, commit reviews, continuous integration tests or by: 2. not bothering with strong development practices and putting all dirty work into a separate development branch (let's call it 'develop') that's going to be broken most of the time. However, every time the code starts to look better (it compiles, tests pass), we promote it to master.
Of course 1. is better than 2., but it would be nice if those aforementioned bad projects adopted at least approach 2. The result is that people interested in bleeding edge code have working master, and even if they send a patch against master and 'develop' is used for the actual development instead, usually those two branches are not that far apart.
Unfortunately, that's not what gitflow does. In gitflow, 'master' means *the* stable, it means old code. It's not continuously updated from develop branch, it's updated only at releases. It's not the branch you want to receive patches against. And it's kind of superficial anyway, because why would you check out a branch containing only tagged commits? In git you can check out a commit directly. I think this part of the workflow was created with some older SVN-like systems in mind, not git. So, in gitflow a 'master' doesn't mean 'unbroken code', it means the most stable code you can ever get.
So, it depends what you want to have. If you would like 'master' to mean 'unbroken/more stable code', I think gitflow fails to deliver that. If you would like 'master' to mean 'you can't get any more stable', then gitflow is perfect. But I really don't think that this is a common understanding.
That being said, I'm not completely against this idea if there are enough other folks who are +1. I'm still -1 on the idea but I could live with it :)
In that case it will depend on what others think (or if they voice any opinion at all). Of course, I could live with the default gitflow as well. I just simply find confusing and a bit irritating its choice to rename traditional branch names for no apparent reason or benefit (in my view). I can definitely cope with it, sure, I'll remember what branch name to use. But I'm concerned about the passers-by and potential bleeding-edge users/contributors. I see this as an unnecessary bump on the road they need to hop over.
If we do change the defaults for gitflow, let's do it soon, though.
Tim
On Mon, 27 Jan 2014 14:24:35 -0500 (EST) Kamil Paral kparal@redhat.com wrote:
I disagree with you here - master is the main branch but it isn't necessarily the main "development" branch. I see it as folks cloning a repo and wanting it to work, therefore having stable release code in master makes more sense than having the stable release code in some non-default branch.
I think 'master' should always contain the latest _working_ code. If we want to take something apart and break it, it should be developed in a feature branch. And functional tests should be run on every commit to master. (I know, that's the ideal state, but it seems we're going the right way).
If somebody wants a stable code base, he usually doesn't clone master, does he? He checks out a stable tag instead.
I suppose it depends on the person. If I'm going to poke around at a project, I usually do so with master. Then again, if I'm going to package something, I look for a released download which generally corresponds with a tag (which it should, regardless of branch strategy).
I guess it comes down to who we want to prioritize as the "default" consumer.
What are the choices? I think the most common consumer for master branch is a developer or, alternatively, an experienced bleeding-edge user.
So, if we use gitflow with traditional master meaning, and stable branch for stable releases, I see it as a win-win. Regardless whether that particular repo uses gitflow or not, you known what branch to work with automatically. You don't need to change configuration in your tools. Everything works, and you get the benefits.
Until we get folks who are used to the default gitflow config (note that infra is using it for many of their projects) and confusion may start.
If there's no develop branch, what confusion do you refer to? I see gitflow as a set of SOPs - branching procedures and naming conventions. You can easily follow it and nobody doesn't even need to recognize that you use gitflow. You just name your feature branches 'feature/XX', release branches 'release/XX', etc. I'm not sure how we can confuse people, if our repo consists of 'master' and a bunch of 'feature/' branches.
Yeah, it's a set of SOPs but they also come with default values - the develop branch being one of those defaults. I assume that people could figure it out but that's pretty much counter to the argument that you're making (people would not notice the develop branch and send patches against master).
If you have installed the gitflow RPM package (it adds the "git flow" subcommand), it asks you initially what naming conventions you like to use. So if you like that tool, there's no problem using it with the traditional 'master' meaning.
I still disagree with you about the "traditional" meaning of master. While many projects seem to use master for dev, I think most of those projects don't have separate dev and release branches.
They don't and they should, but I don't see this related to develop/master naming issue.
Naming has little to do with it. You could call the development branch "snozberry" and the released branch "maplesyrup" and the argument would be pretty much the same. It's about separation of released and under-development code in consistent places.
If I understand you correctly, you would like 'master' to contain more stable code than what is usual for a large number of existing projects - broken code, incomplete features, failures to even compile, etc. And that is a nice goal indeed. I think we can achieve that either by: 1. strong development practices - feature branches, commit reviews, continuous integration tests or by: 2. not bothering with strong development practices and putting all dirty work into a separate development branch (let's call it 'develop') that's going to be broken most of the time. However, every time the code starts to look better (it compiles, tests pass), we promote it to master.
2. is not acceptable in any way, shape or form. The development branch needs to be usable almost all of the time and we should be deploying it to a dev system on a regular (every couple of days, bare minimum) basis. Regardless of what we call the different branches, the only place it's acceptable to have regularly broken code is in a feature branch.
Of course 1. is better than 2., but it would be nice if those aforementioned bad projects adopted at least approach 2. The result is that people interested in bleeding edge code have working master, and even if they send a patch against master and 'develop' is used for the actual development instead, usually those two branches are not that far apart.
Unfortunately, that's not what gitflow does. In gitflow, 'master' means *the* stable, it means old code.
No, it means "production ready" code. While that is going to be older than whatever we're currently developing by definition, it's not like develop is rawhide to master's epel. It's a consistent place to get stable code from if you chose to deploy from git or are working on a bugfix against the currently released version that can't wait for the development branch to be ready for release.
It's not continuously updated from develop branch, it's updated only at releases. It's not the branch you want to receive patches against.
Why not? If the fix is for a bug in master, wouldn't we want the patch against the released code instead of against code which hasn't been released yet?
And it's kind of superficial anyway, because why would you check out a branch containing only tagged commits? In git you can check out a commit directly.
How would you integrate any changes to that commit without making an unholy mess of the repo or releasing it as a patch?
I think this part of the workflow was created with some older SVN-like systems in mind, not git.
This workflow would be insane in SVN, branching and merging are expensive and tend to be painful.
So, in gitflow a 'master' doesn't mean 'unbroken code', it means the most stable code you can ever get.
Exactly - it's stable code. The methodology provides a clean and well defined way to make changes to both stuff that's been released and stuff that hasn't been released yet. I'm not saying that gitflow is the only answer or that there aren't other ways to manage branches, I just think that it's a good, relatively well-defined solution and I don't really have a better alternative.
So, it depends what you want to have. If you would like 'master' to mean 'unbroken/more stable code', I think gitflow fails to deliver that. If you would like 'master' to mean 'you can't get any more stable', then gitflow is perfect. But I really don't think that this is a common understanding.
Well, gitflow or any branching strategy isn't a cure. It's simply a methodology that takes any guesswork out of where code should go or what's in various branches. Without discipline and good development practices, it's worse than useless because we'd have multiple branches with an unclear purpose instead of just one.
One of the biggest advantages I see in having a 'develop' branch is that new features don't have to come to a halt at release time. If we combined master and develop, new features can't be merged in once we start the pre-release process. How do you propose we do release branches without a separation between develop and master?
How would hotfixes work if we find critical bugs in released code when our development branch isn't ready for release? How would the gitflow tool be affected? Can it handle stable and development branches being the same?
That being said, I'm not completely against this idea if there are enough other folks who are +1. I'm still -1 on the idea but I could live with it :)
In that case it will depend on what others think (or if they voice any opinion at all). Of course, I could live with the default gitflow as well. I just simply find confusing and a bit irritating its choice to rename traditional branch names for no apparent reason or benefit (in my view). I can definitely cope with it, sure, I'll remember what branch name to use. But I'm concerned about the passers-by and potential bleeding-edge users/contributors. I see this as an unnecessary bump on the road they need to hop over.
I'm not as worried, to be honest. We need to document our processes better but in a similar vein to what I said about github and making drive-by patches easier, if someone is not capable of looking at the readme or any other docs before writing a patch ... are we really that confident that any contributions would be useful and wanted? If reading the readme and typing 'git checkout develop' is too much work for testing, how likely is it that the same person would take the time to file a decent bug or send mail to the list?
It'd be nice to hear some more opinions on this - especially from folks who will be regular contributors (don't make me call you out by name because I will resort to that if needed).
Tim
If I understand you correctly, you would like 'master' to contain more stable code than what is usual for a large number of existing projects - broken code, incomplete features, failures to even compile, etc. And that is a nice goal indeed. I think we can achieve that either by: 1. strong development practices - feature branches, commit reviews, continuous integration tests or by: 2. not bothering with strong development practices and putting all dirty work into a separate development branch (let's call it 'develop') that's going to be broken most of the time. However, every time the code starts to look better (it compiles, tests pass), we promote it to master.
- is not acceptable in any way, shape or form. The development branch
needs to be usable almost all of the time and we should be deploying it to a dev system on a regular (every couple of days, bare minimum) basis. Regardless of what we call the different branches, the only place it's acceptable to have regularly broken code is in a feature branch.
I didn't mean that 2. would be suitable for us :-) I just wanted to say that even this would be an improvement for some projects out there in the wild which have their master broken most of the time.
Of course 1. is better than 2., but it would be nice if those aforementioned bad projects adopted at least approach 2. The result is that people interested in bleeding edge code have working master, and even if they send a patch against master and 'develop' is used for the actual development instead, usually those two branches are not that far apart.
Unfortunately, that's not what gitflow does. In gitflow, 'master' means *the* stable, it means old code.
No, it means "production ready" code. While that is going to be older than whatever we're currently developing by definition, it's not like develop is rawhide to master's epel. It's a consistent place to get stable code from if you chose to deploy from git or are working on a bugfix against the currently released version that can't wait for the development branch to be ready for release.
If you see it like this - you want 'master' to mean 'production ready' (== only officially released versions) - then gitflow makes absolute sense.
It's not continuously updated from develop branch, it's updated only at releases. It's not the branch you want to receive patches against.
Why not? If the fix is for a bug in master, wouldn't we want the patch against the released code instead of against code which hasn't been released yet?
It depends how much we would have re-factored the in-development code in the meantime. In general I would rather see more patches against development code than against stable code, it's easier for us to merge. But in most cases it should not matter much, right.
And it's kind of superficial anyway, because why would you check out a branch containing only tagged commits? In git you can check out a commit directly.
How would you integrate any changes to that commit without making an unholy mess of the repo or releasing it as a patch?
Exactly the same as in the original gitflow model - by using hotfixes branch. See the picture at [1].
Let's say you find a problem in tag 0.1. You create hotfixes/0.1 branch starting from commit 0.1. You fix the problem in one or more commits. Then you tag the last commit as 0.1.1 or 0.2, as you wish. Finally, you can delete hotfixes/0.1 branch, it's no longer necessary.
Then you discover problem in tag 0.1.1. You create hotfixes/0.1.1 branch starting from commit 0.1.1, fix the problem, tag the latest commit as 0.1.2, delete the branch.
Of course all those hotfixes get merged into your development branch as well. Everything is the same as in the picture. I was just trying to point out that the rightmost thick line connecting tags 0.1, 0.2, 1.0 and so on (a branch called master on the picture) is not necessary at all. The only "advantage" it has is that it allows you to do "git pull" to get the latest stable release instead of checking out a tag directly ('git tag' and 'git checkout <tag>').
However, since you don't agree with master referring to development code and you rather want master to refer to the latest stable code (something I haven't expected before), then yes, the original picture in the article makes sense in this case. If you intention is to offer people the latest stable code by default (when they open up our github/bitbucket page, they are shown master as the default branch), it all makes sense and the branch is needed. (That's not what Fedora Infra does, however, they display 'develop' branch as default for many of their repos; that defeats the purpose of the rename in the first place).
I think this part of the workflow was created with some older SVN-like systems in mind, not git.
This workflow would be insane in SVN, branching and merging are expensive and tend to be painful.
So, in gitflow a 'master' doesn't mean 'unbroken code', it means the most stable code you can ever get.
Exactly - it's stable code. The methodology provides a clean and well defined way to make changes to both stuff that's been released and stuff that hasn't been released yet. I'm not saying that gitflow is the only answer or that there aren't other ways to manage branches, I just think that it's a good, relatively well-defined solution and I don't really have a better alternative.
So, it depends what you want to have. If you would like 'master' to mean 'unbroken/more stable code', I think gitflow fails to deliver that. If you would like 'master' to mean 'you can't get any more stable', then gitflow is perfect. But I really don't think that this is a common understanding.
Well, gitflow or any branching strategy isn't a cure. It's simply a methodology that takes any guesswork out of where code should go or what's in various branches. Without discipline and good development practices, it's worse than useless because we'd have multiple branches with an unclear purpose instead of just one.
One of the biggest advantages I see in having a 'develop' branch is that new features don't have to come to a halt at release time. If we combined master and develop, new features can't be merged in once we start the pre-release process. How do you propose we do release branches without a separation between develop and master?
That's what the 'release' branches are for, see picture at [1]. It's like branching Fedora XX from Rawhide. You branch 'release/1.0' branch from your main development branch and you can work on both in parallel - stabilizing the release in the release branch and do more development in the development branch.
So, in my world, 'master' branch never stops and 'release/XX' branches are branched from it. In gitflow world, 'develop' branch never stops and 'release/XX' branches are branched from it. I don't see any major difference :-)
How would hotfixes work if we find critical bugs in released code when our development branch isn't ready for release? How would the gitflow tool be affected? Can it handle stable and development branches being the same?
Let me try to illustrate my changes a bit better :) See this:
http://i.imgur.com/dLMe9fM.png
or alternatively this:
http://i.imgur.com/MQ1Hpg3.png
I haven't suggested any other changes to the workflow, everything remains the same. All features stay intact. I just proposed to fix a logical inconsistency in branch naming (in my view).
That being said, I'm not completely against this idea if there are enough other folks who are +1. I'm still -1 on the idea but I could live with it :)
In that case it will depend on what others think (or if they voice any opinion at all). Of course, I could live with the default gitflow as well. I just simply find confusing and a bit irritating its choice to rename traditional branch names for no apparent reason or benefit (in my view). I can definitely cope with it, sure, I'll remember what branch name to use. But I'm concerned about the passers-by and potential bleeding-edge users/contributors. I see this as an unnecessary bump on the road they need to hop over.
I'm not as worried, to be honest. We need to document our processes better but in a similar vein to what I said about github and making drive-by patches easier, if someone is not capable of looking at the readme or any other docs before writing a patch ... are we really that confident that any contributions would be useful and wanted? If reading the readme and typing 'git checkout develop' is too much work for testing, how likely is it that the same person would take the time to file a decent bug or send mail to the list?
I agree with you, people will need to read documentation anyway. The only thing I dislike is that we want to divert from the traditions that everyone knows. 'master' is traditionally used to mean the main development branch, or at least _a_ *development* branch. If we want to have a branch with just stable, released code, why wouldn't we call it 'stable' (or anything similar) instead of changing the meaning or 'master' and then using a different branch for the purposes of master?
But I don't think we should spend too much time on this. If you believe that we should go against the tide and have 'master' to mean something else, I'm fine with that. I simply did not expect that this is really your intention.
It'd be nice to hear some more opinions on this - especially from folks who will be regular contributors (don't make me call you out by name because I will resort to that if needed).
I think they are a bit discouraged by the long discussion and they don't want to wrap their brains around all those graphs and models. I'm not surprised, I did not expect to go into so much detail anyway, for me this was a trivial rename fix proposal. But apparently I wasn't able to describe properly how simple all of this is, and it evolved into such a complex monster issue :-) I'm fine with anything, really.
On Thu, 30 Jan 2014 07:56:08 -0500 (EST) Kamil Paral kparal@redhat.com wrote:
<snip>
And it's kind of superficial anyway, because why would you check out a branch containing only tagged commits? In git you can check out a commit directly.
How would you integrate any changes to that commit without making an unholy mess of the repo or releasing it as a patch?
Exactly the same as in the original gitflow model - by using hotfixes branch. See the picture at [1].
Let's say you find a problem in tag 0.1. You create hotfixes/0.1 branch starting from commit 0.1. You fix the problem in one or more commits. Then you tag the last commit as 0.1.1 or 0.2, as you wish. Finally, you can delete hotfixes/0.1 branch, it's no longer necessary.
Then you discover problem in tag 0.1.1. You create hotfixes/0.1.1 branch starting from commit 0.1.1, fix the problem, tag the latest commit as 0.1.2, delete the branch.
Of course all those hotfixes get merged into your development branch as well. Everything is the same as in the picture. I was just trying to point out that the rightmost thick line connecting tags 0.1, 0.2, 1.0 and so on (a branch called master on the picture) is not necessary at all. The only "advantage" it has is that it allows you to do "git pull" to get the latest stable release instead of checking out a tag directly ('git tag' and 'git checkout <tag>').
However, since you don't agree with master referring to development code and you rather want master to refer to the latest stable code (something I haven't expected before), then yes, the original picture in the article makes sense in this case. If you intention is to offer people the latest stable code by default (when they open up our github/bitbucket page, they are shown master as the default branch), it all makes sense and the branch is needed. (That's not what Fedora Infra does, however, they display 'develop' branch as default for many of their repos; that defeats the purpose of the rename in the first place).
I think that a lot of this stems from my misunderstanding of your proposal. I thought you were proposing to merge the 'master' and 'develop' branches into a single branch, which is not what you actually proposed :)
Honestly, I don't care much whether we change the default branch for the repos or switch the way we're naming branches. I'm more interested in maintaining the separation between stable and development branches, do hotfixes etc.
The biggest impediment I see to changing the branch names is that we'd have to go back and change blockerbugs (using gitflow with default names) but I suppose that's not a huge issue.
<snip>
I'm not as worried, to be honest. We need to document our processes better but in a similar vein to what I said about github and making drive-by patches easier, if someone is not capable of looking at the readme or any other docs before writing a patch ... are we really that confident that any contributions would be useful and wanted? If reading the readme and typing 'git checkout develop' is too much work for testing, how likely is it that the same person would take the time to file a decent bug or send mail to the list?
I agree with you, people will need to read documentation anyway. The only thing I dislike is that we want to divert from the traditions that everyone knows. 'master' is traditionally used to mean the main development branch, or at least _a_ *development* branch. If we want to have a branch with just stable, released code, why wouldn't we call it 'stable' (or anything similar) instead of changing the meaning or 'master' and then using a different branch for the purposes of master?
But I don't think we should spend too much time on this. If you believe that we should go against the tide and have 'master' to mean something else, I'm fine with that. I simply did not expect that this is really your intention.
Agreed on not spending more time on this. We've got more important things to deal with than branch names.
It'd be nice to hear some more opinions on this - especially from folks who will be regular contributors (don't make me call you out by name because I will resort to that if needed).
I think they are a bit discouraged by the long discussion and they don't want to wrap their brains around all those graphs and models. I'm not surprised, I did not expect to go into so much detail anyway, for me this was a trivial rename fix proposal. But apparently I wasn't able to describe properly how simple all of this is, and it evolved into such a complex monster issue :-) I'm fine with anything, really.
Yeah, I'm fine with either changing the default branch or renaming stuff - as long as we do it for all projects and do it very soon.
After talking on IRC, I think we're both OK with changing the default branch in bitbucket. It takes the least amount of work to change and I suspect it'll mean less documentation and confusion since we'd be able to use the defaults during gitflow setup (assuming folks are using the gitflow tool). People landing on the bitbucket page will see the devel code which makes sense to me and if I'm understanding you correctly, was your main objection to gitflow.
Any objections to going forward with this - setting 'develop' as the default branch for projects which are not dependent on fedora version and keeping with the gitflow defaults?
Tim
----- Original Message -----
From: "Tim Flink" tflink@redhat.com To: qa-devel@lists.fedoraproject.org Sent: Thursday, February 6, 2014 6:01:02 PM Subject: Re: gitflow and branch naming conventions
<snip>
Any objections to going forward with this - setting 'develop' as the default branch for projects which are not dependent on fedora version and keeping with the gitflow defaults?
No objections.
qa-devel@lists.fedoraproject.org
-
Kamil Paral -
Martin Krizek -
Ralph Bean -
Tim Flink