Git branches and development process.
Locked
Git branches and development process.
 
|
Re: Git branches and development process.
|
|
Re: Git branches and development process.
|
|
Re: Git branches and development process.
|
|
In reply to this post by Vladimir Ozerov
Actually, this approach works very well for the situation below. The way to
deal with it is explained here http://nvie.com/posts/a-successful-git-branching-model/ And has been discussed on this list a couple of times already. 'sprint-N' branch is not different from a 'development' branch, except that 'development' is always there, where N is increased all the time in 'sprint-N' schema. That's pretty confusing if you ask me. Another issue with sprint-branch model, is that it doesn't support sustaining releases in a transparent way, where's the one above (or similarly offered by Artiom) does. Cos On Wed, Jun 03, 2015 at 01:51PM, Vladimir Ozerov wrote: > This approach doesn't work well when there are several development > branches. E.g. someone is working on tickets for current release, someone > else is working on features for the next release. Current approach with > "sprint" branches handles this situation. > Another problem is that version is subject to frequent changes and can vary > for the same set of features depending on some "political" and "marketing" > reasons. Normally developer should not be aware of versioning. This is why > indirection between sprint and version is a good thing. > > On Wed, Jun 3, 2015 at 1:25 PM, Artiom Shutak <[hidden email]> wrote: > > > Igniters, > > > > As I remember, the question about hard understandable Ignite branches > > system was discussed many times. But I don't remember the end of it story. > > > > I suggest to have next branches system (nothing new). > > > > - *development* branch. The branch has the last development state with > > all new features. If you start development new feature, you just make > > branch from the HEAD of *development* branch and create a patch against > > this one. > > - *master* branch. The branch has the same state as the last released > > version of Ignite. As a result, when anyone clone Ignite, he will see > > stable version of Ignite and can simply play with him. > > - *release-x.x.x* branches. When we think, that development branch has > > enough new features for release, we just create new *release-x.x.x* > > branch and make Ignite stable here. After releasing of this branch, we > > need > > to merge* release-x.x.x *branch at *development* and at *master* > > branches. > > > > > > To get this branches state, we need to > > > > - "rename" *ignite-sprint-6* to *development* > > - "rename" *ignite-sprint-5 *to* release-1.2.0* > > - merge last released branch at *master *(if we didn't do it yet) > > > > // "rename" = create new branch from the HEAD of old branch and delete old > > branch. > > > > I think this schema will be more clear for contributors, commiters and > > simple users. > > > > Thoughts? Objections? > > > > -- Artem -- > > |
signature.asc (501 bytes)
Re: Git branches and development process.
|
|
Re: Git branches and development process.
|
|
Re: Git branches and development process.
|
|
Re: Git branches and development process.
|
|
Re: Git branches and development process.
|
|
Re: Git branches and development process.
|
|
Re: Git branches and development process.
|
|
Re: Git branches and development process.
|
|
On Sun, Jun 07, 2015 at 03:05PM, Branko Čibej wrote:
> On 07.06.2015 13:34, Konstantin Boudnik wrote: > > Another point: cherry-picking in git should be avoided wherever possible as they change commit SHAs and make tracking a way harder. > > I'd have thought, after hearing for years how Git merging leaves svn > coughing in the dust, that at least they'd have got cherry-picks right > by now ... heh. :) I might be wrong, but I think this is a conceptual decision on the part of git author(s). But I might be mistaken. > I don't think you can avoid some form of cherry picking. either > git-cherry-pick or diff & patch, and I guess the former is still better. > An indirect audit trail is still better than having no audit trail at all. > > You could possibly avoid some of that by introducing the concept of > bugfix branches, but that's potentially worse than the disease. Bugfix branches (with consequent merges) are actually working quite fine, but there might be corner cases where it isn't ideal either. As usual - never a single tool fits everything ;) Cos > > And yes - wholeheartedly agree that VCS model should be as simple as possible. > > > > Cos > > > > On June 7, 2015 9:35:59 AM GMT+03:00, "Branko Čibej" <[hidden email]> wrote: > >> On 06.06.2015 22:17, Vladimir Ozerov wrote: > >>> I think I understand why we do not use schemes proposed above. They > >> are > >>> definitely better than current. But we cannot use them because of two > >>> things: > >>> 1) We do not have real "stabilization" phase. Normally it must > >> include > >>> mainly bugfixes, but we usually continue filling development branch > >> with > >>> features as much as possible up to the last day before release. So we > >>> declare it as "stabilization", but in reality nothing changes and > >> this is > >>> still active development. > >>> 2) We do not have good versioning policy - for now it is normal to > >> change > >>> versions several times in a sprint. > >>> > >>> If we get rid of these two problems, we certainly can employ proposed > >>> schemes and gain benefits from it. > >> The thing to do is to turn the whole structure upside down. Instead of > >> having several development branches and doing stabilization on each of > >> them, instead, have /one/ development branch and stabilize the release > >> branches instead. And call the development branch "master". > >> > >> +- feature-X ------+ > >> / \ > >> master (development) ----------------------(tag-X)-------- > >> |\ > >> | +- rel-1.2.x (stable) -------rel-tag-1.2.0-RC1-------- > >> \ > >> +-- rel-1.1.x (stable) --------------rel-tag-1.1.13---- > >> > >> > >> The process is then: > >> > >> * All development happens on the "master" branch. You can still create > >> long-lived feature branches off the master branch, to avoid too much > >> destabilization: the rule should be that code always compiles and a > >> certain group of tests (usually called "smoke tests") always pass on > >> the master branch. > >> * When you're ready to begin stabilization for a release, create a > >> release branch (rel-1.2.x for example) from the master branch. Only > >> bug fixes happen on the release branch. When you're happy with the > >> stability of the release, just tag the release branch (e.g., 1.2.0) > >> and publish. This now becomes the bugfix branch for the 1.2.x release. > >> o Its up to you to decide how you fix bugs on the release branch; > >> there are basically two ways to do this: > >> + Fix all bugs on master and cherry-pick them to the release > >> branch(es). This is the preferred method because it ensures > >> that all bug fixes are present in all future releases. > >> + Fix bugs on the release branches and merge them back to > >> master. This works but > >> o Since many releases go through a number of release candidates, > >> you can tag each candidate (e.g., 1.2.13-RC5) on this branch and > >> have a history of what was fixed between candidates. > >> o You can easily maintain several releases at the same time. This > >> becomes very valuable once you've finally defined a version > >> compatibility policy. > >> > >> > >> This structure is very easy to understand: master is always the > >> bleeding-edge, release branches are always stable (and contain the > >> actual release tags), feature branches are mostly irrelevant and > >> ad-hoc. > >> There's an additional benefit compared your current model where master > >> only contains the latest released code: it doesn't really let you > >> maintain several release streams at the same time, whereas my proposed > >> model does. > >> > >> Also there's a serious flaw in the concept of sprint branches; there > >> are > >> two invalid assumptions: > >> > >> * The first invalid assumption is that you can shoehorn a particular > >> development process on every member of an open-source community. > >> That just doesn't work in practice: open source developers, > >> especially those at the ASF, usually have other interests in their > >> life (e.g, the jobs they do so they can eat) and they will loose > >> focus and go away for a while, etc. > >> * The second invalid assumption is that you can plan releases by > >> "sprints". You can do that if all your developers are essentially in > >> the same room and can talk face-to-face on a daily basis. You cannot > >> do this if you depend on random contributions from the community. > >> Consider someone coming in with a patch ... which of the 15 current > >> sprint branches should it apply to? With a single development > >> branch, the question doesn't even come up. > >> > >> > >> The main consideration about configuration management workflows is to > >> keep them as simple as possible. I've often noticed that Git-based > >> workflows tend to be complex because people instinctively pile on > >> branches, presumably because branching and merging is so simple. That > >> approach is not valid. You should always keep the number of public > >> branches to a minimum that every developer can understand without > >> keeping a huge SCM manual on her desk. Although you'll find far more > >> complex workflows in many corporate environments, you'll also find > >> dedicated teams of "SCM experts" whose only task is to maintain the > >> various branches and tags and merge stuff to the appropriate one. This > >> is extremely wasteful (and it also caters to the perceived incompetence > >> of the average closed-source programmer). You can't afford this kind of > >> complexity on an open-source project. > >> > >> -- Brane > >> > >> > >>> On Sat, Jun 6, 2015 at 11:00 PM, Vladimir Ozerov > >> <[hidden email]> > >>> wrote: > >>> > >>>> I still doesn't understand how does this scheme handle several > >>>> simultaneous "sprints" (in current terms). > >>>> > >>>> Our sprints are usually relatively short (2-4 weeks). On the one > >> hand, at > >>>> the end of every sprint we usually have a week or so to stabilize > >> it. > >>>> During this time the sprint is not released yet, so it is still > >>>> "development" branch in your terms. And there is still active > >> development > >>>> in this branch incluing bugfixes, finalization of some _almost_ > >> ready > >>>> features, critical last-minute-changes etc. On the other hand, at > >> this time > >>>> all new major features go to the next "sprint", not to the current, > >> to > >>>> avoid regressions. And this is not about a single feature as in the > >> scheme > >>>> above. This is about lots of feauters, which usually conflicts with > >> each > >>>> other and thus must be constantly accumulated in some other branch. > >> This is > >>>> why instead of > >>>> > >>>> sprint-5 (development) > >>>> new-feature-1 (merge to development after release, in a week) > >>>> new-feature-2 (merge to development after release, in a week) > >>>> > >>>> we have > >>>> > >>>> sprint-5 (development) > >>>> sprint-6 (next sprint) > >>>> new-feature-1 (merge to sprint-6 as soon as ready) > >>>> new-feature-2 (merge to sprint-6 as soon as ready) > >>>> > >>>> I am certainly +1 for using the most common practices, so that > >> adoption of > >>>> new people is as easy as possible. But it seems that with proposed > >>>> solutions we get rid of one problem immediately introducing another. > >>>> > >>>> Vladimir. > >>>> > >>>> On Sat, Jun 6, 2015 at 8:41 PM, Pavel Tupitsyn > >> <[hidden email]> > >>>> wrote: > >>>> > >>>>> +1 Artiom, Cos > >>>>> > >>>>> The link above describes a quite standard approach, familiar to > >> majority > >>>>> of > >>>>> devs, I believe. I have seen it many times before, it works well > >> for any > >>>>> VCS. > >>>>> Current approach with sprint branches is more confusing, and also > >> requires > >>>>> changing default branch on TC each sprint. I hear "which is the > >> default > >>>>> branch on TC at the moment" quite often. > >>>>> > >>>>> Thanks, > >>>>> > >>>>> On Sat, Jun 6, 2015 at 2:37 PM, Konstantin Boudnik <[hidden email]> > >>>>> wrote: > >>>>> > >>>>>> Actually, this approach works very well for the situation below. > >> The > >>>>> way to > >>>>>> deal with it is explained here > >>>>>> http://nvie.com/posts/a-successful-git-branching-model/ > >>>>>> > >>>>>> And has been discussed on this list a couple of times already. > >>>>> 'sprint-N' > >>>>>> branch is not different from a 'development' branch, except that > >>>>>> 'development' > >>>>>> is always there, where N is increased all the time in 'sprint-N' > >> schema. > >>>>>> That's pretty confusing if you ask me. Another issue with > >> sprint-branch > >>>>>> model, > >>>>>> is that it doesn't support sustaining releases in a transparent > >> way, > >>>>>> where's > >>>>>> the one above (or similarly offered by Artiom) does. > >>>>>> > >>>>>> Cos > >>>>>> > >>>>>> On Wed, Jun 03, 2015 at 01:51PM, Vladimir Ozerov wrote: > >>>>>>> This approach doesn't work well when there are several > >> development > >>>>>>> branches. E.g. someone is working on tickets for current release, > >>>>> someone > >>>>>>> else is working on features for the next release. Current > >> approach > >>>>> with > >>>>>>> "sprint" branches handles this situation. > >>>>>>> Another problem is that version is subject to frequent changes > >> and can > >>>>>> vary > >>>>>>> for the same set of features depending on some "political" and > >>>>>> "marketing" > >>>>>>> reasons. Normally developer should not be aware of versioning. > >> This is > >>>>>> why > >>>>>>> indirection between sprint and version is a good thing. > >>>>>>> > >>>>>>> On Wed, Jun 3, 2015 at 1:25 PM, Artiom Shutak > >> <[hidden email]> > >>>>>> wrote: > >>>>>>>> Igniters, > >>>>>>>> > >>>>>>>> As I remember, the question about hard understandable Ignite > >>>>> branches > >>>>>>>> system was discussed many times. But I don't remember the end of > >> it > >>>>>> story. > >>>>>>>> I suggest to have next branches system (nothing new). > >>>>>>>> > >>>>>>>> - *development* branch. The branch has the last development > >> state > >>>>>> with > >>>>>>>> all new features. If you start development new feature, you > >> just > >>>>>> make > >>>>>>>> branch from the HEAD of *development* branch and create a > >> patch > >>>>>> against > >>>>>>>> this one. > >>>>>>>> - *master* branch. The branch has the same state as the last > >>>>>> released > >>>>>>>> version of Ignite. As a result, when anyone clone Ignite, he > >> will > >>>>>> see > >>>>>>>> stable version of Ignite and can simply play with him. > >>>>>>>> - *release-x.x.x* branches. When we think, that development > >>>>> branch > >>>>>> has > >>>>>>>> enough new features for release, we just create new > >>>>> *release-x.x.x* > >>>>>>>> branch and make Ignite stable here. After releasing of this > >>>>> branch, > >>>>>> we > >>>>>>>> need > >>>>>>>> to merge* release-x.x.x *branch at *development* and at > >> *master* > >>>>>>>> branches. > >>>>>>>> > >>>>>>>> > >>>>>>>> To get this branches state, we need to > >>>>>>>> > >>>>>>>> - "rename" *ignite-sprint-6* to *development* > >>>>>>>> - "rename" *ignite-sprint-5 *to* release-1.2.0* > >>>>>>>> - merge last released branch at *master *(if we didn't do it > >> yet) > >>>>>>>> // "rename" = create new branch from the HEAD of old branch and > >>>>> delete > >>>>>> old > >>>>>>>> branch. > >>>>>>>> > >>>>>>>> I think this schema will be more clear for contributors, > >> commiters > >>>>> and > >>>>>>>> simple users. > >>>>>>>> > >>>>>>>> Thoughts? Objections? > >>>>>>>> > >>>>>>>> -- Artem -- > >>>>>>>> > >>>>> > >>>>> -- > >>>>> -- > >>>>> Pavel Tupitsyn > >>>>> GridGain Systems, Inc. > >>>>> www.gridgain.com > >>>>> > |
Re: Git branches and development process.
|
| Free forum by Nabble | Edit this page |