From time to time there is the discussion of which workflow is better to develop with git, etc.
I'm not going to try to convince anyone on which workflow to use, i'm just going to explain what i do and explain why i think it's useful (and even more in the multi-developer KDE environment).
Let's picture the scenario we had a few days ago where there were lots of projects with three "live" branches, i.e. KDE/4.13, KDE/4.14 and master.
What is my way to develop?
* Bugfixes go to oldest "live" stable branch
* Features go to oldest "live" non frozen branch
* Branches are merged up
So let's say that I develop a new feature to support a whole new document format to Okular. Since that is a new feature it would go to the "oldest live non frozen branch", that in this case was master since KDE/4.13 and KDE/4.14 where already feature frozen. So I commit it to master and then "Branches are merged up" which in this case means nothing since there's no branch "up" from master.
Now let's say there's a crash bug when opening a file with three monitors. Since that is a bugfix, it'd go to the "oldest live stable branch", that in this case would be KDE/4.13. And then "Branches are merged up", so i would mean 4.13 into 4.14 and after that 4.14 into master. Ensuring that 4.14 and master also have the bugfix.
I think that this is a very useful way of developing using git branches for a lot of reasons, but the biggest of them is that for a random person it is easy to know if a "branch high in the hiearchy" has all the bugfixes or not, he just have to go to KDE/4.14 and to "git merge origin/KDE/4.13", if no change is brought over, it means that for sure all the bugfixes and code that was in the 4.13 release will be in the 4.14 release, otherwise it is hard to know.
So now that 4.13 is not going to be released anymore and 4.14 is a very young fork of master, i suggest that for every push you do to KDE/4.14 you go to the master branch and merge origin/KDE/4.14. This way you will have a master that is always fully merged with 4.14 and a third party person looking at your code (like the release manager) won't have to worry if it contains all the code or not.
Happy hacking!
And of course if you disagree with me, that's fine, not that i'm happy if my reasons did not convince you :)
1 comment:
No sóc un expert, però a primera vista eixa forma de treballar pareix tindre més avantatges que les alternatives, almenys en la majoria dels casos.
Post a Comment