The choice of the model of branching for Git?

In our project as VCS we use Git with such a branching model. However, this model does not suit us, because it presupposes the existence of releases with pre-determined functionality.


The project historically different mechanism: features are developed in parallel, with not known beforehand, as soon as one or the other feature you will need on production. In the case of the above model, we get problems with the transfer of best practices from the develop branch to the master branch, because, often, "features" overlap. This is due to the fact that the branch "features" are generated from the develop branch, which at some point in time begins to outstrip the master branch.


Would be grateful for links to the different branching model, different from those mentioned. Unfortunately, Google mostly offers in its results it. Also would be grateful for any practical advice.
October 8th 19 at 01:13
3 answers
October 8th 19 at 01:15
It may not have a develop branch, and have master and under every branch on the feature?
Until we came to this option. But it has a significant drawback: the difficulty in verification of new features on the test server. I.e. to check several features simultaneously, you should still collect them in the develop branch. While it is likely to face a conflict, which first have to be solved with the test (merge into develop) and then when you deploy (merge to master). - floy_Murray commented on October 8th 19 at 01:18
So can test a few features integrating n features in a new branch, i.e. n features together it has n+1 feature. And then the n+1 feature, after testing, merge into master. - xander_Kozey commented on October 8th 19 at 01:21
That's the whole point, that we can't combine multiple features into one, since some of them may require once, but part after some time, otherwise we would be quite fit the "successful branching model". - floy_Murray commented on October 8th 19 at 01:24
So nobody makes pour n+1 feature, I just suggested. You can test it, and add only those features that are needed. In the end there is a cherry-pick. - xander_Kozey commented on October 8th 19 at 01:27
Well, about this time I wrote above: "it is likely to face a conflict, which first have to be solved with the test (merge into develop) and then when you deploy (merge to master)". It is not so critical, but not very convenient. I was hoping there are other solutions. - floy_Murray commented on October 8th 19 at 01:30
Why not pour in of develop only features that will be needed in the wizard, and the rest to keep up to the moment when you decide to implement them? - retha13 commented on October 8th 19 at 01:33
Why not? It is possible and even necessary. - floy_Murray commented on October 8th 19 at 01:36
October 8th 19 at 01:17
we have every feature branitsa from the master, but in General all branitsa from the master, releases at any time going from features/bago-out brunches, all conflicts are solved at the stage of merging in the release.
And you don't have to test multiple features? - floy_Murray commented on October 8th 19 at 01:20
Always testada together in the Release. If multiple features are dependent, then the developers have a separate branch like the release, but only on their features, though in fact, release a few large features tend not to carry. - xander_Kozey commented on October 8th 19 at 01:23
October 8th 19 at 01:19
Just yesterday I found just such a model demiazz.github.com/blog/2011/11/19/a-successfull-git-branching-model/I think that it is right for You.
Reread, please, the first two lines of my question and be sure to follow the link. - floy_Murray commented on October 8th 19 at 01:22

Find more questions by tags BranchingGitSoftware