Mateusz, The link you referred to is actually based on a piece of software that sits on top of git called git-flow (installable on debian systems via sudo apt-get install git-flow).
I have been using it for about six months now (takes a few weeks to get used to). I find it absolutely indispensable in my own projects now. This is what I typically do: 1. Before making any changes to the code base, I issue a Bug or Feature into redmine so I get a number back. 2. Most of the time, it's a feature, so I run git flow feature start feature_XXX where XXX is the number in 1. 3. git-flow will create a temporary feature branch off of the develop branch for me. 4. I commit all the code that I code I need to, to feel safe about not losing any work. 5. When I'm done, I do a git flow feature finish feature_XXX 6. git push will push the code back to the server Sometimes, I need to do a bugfix that needs to go into the master branch and the develop branch. 7. Like features, I do a git flow feature start hotfix YYY, where YYY is some version number - we need a standard version number here because the code will end up in develop and in master and anything that goes into master should have some kind of standard tagging. 8. Finish up with git flow feature finish hotfix YYY Once in a long while, we need a real release. In that case, we go for 9. git flow start release ZZZ 10. git flow finish release ZZZ where ZZZ is some standard version number again. In between 9. and 10., there is usually some QA action along with good unit-testing/validation. I didn't mean for this message to be so long, but I wholly recommend the use of git-flow: it really makes good use of git branching under the covers. BTW, for users of git-flow, and in fact, for users of git, it is customary/the convention to push to develop and not to master (at least not directly), but I don't think there's anything to prevent someone from NOT following this convention. - Ken On Fri, Nov 16, 2012 at 9:56 PM, Mateusz Loskot <[email protected]> wrote: > On 16 November 2012 13:25, Vadim Zeitlin <[email protected]> wrote: >> On Fri, 16 Nov 2012 12:57:23 +0000 Mateusz Loskot <[email protected]> wrote: >> >> ML> I'm thinking about structuring SOCI development and following >> ML> some well-known GitHub practices regarding branching, tagging, etc. >> ML> >> ML> I've proposed some ideas as a task here: >> ML> >> ML> https://github.com/SOCI/soci/issues/18 >> ML> >> ML> I'd like to ask everyone for comments,especially related to the model >> ML> outlined in the article linked in the ticket. >> >> Hello, >> >> This is not a bad model but I wonder if people are not going to be >> confused by the need to make patches to (or make pull requests for) the >> "development" branch instead of the usual "master". > > I do have exactly the same concern. > I'm not used to the use of "develop" or "next" branch, > but I have seen projects using it (e.g. CMake, i3wm.org). > I simply integrate my private branches with master directly. > >> As it seems that many >> (most?) changes to SOCI come from people not working on it all the time, > > Yes. > > My aim is to favor some sort of open development with anyone > encouraged to share her/his ideas, and step forward to take some action. > In an ideal world, I'd be happy to grant anyone with write access to Git repo, > anyone who would ask for that, but... > And here GitHub plays great as it enables folks to contribute easily. > It's just that there is someone needed for some kind of traffic control :) > > We have the SOCI core team, if you will, and that's fantastic. > But, I don't expect SOCI members to be contribute on daily/weekly/any > frequent basis, so neither of us should feel obliged to be active. > (I do not work on SOCI all the time myself either.) > The point is, it's just great thing if we push the project forward from > time to time, taking tiny steps, even once a year :) > >> I think that many of them might not suspect that they need to start from that >> branch instead of "master". > > Yes, good point. > >> So perhaps this model can be used but with "master" used for development >> and some branch with a different name ("stable"? "release"?) for the >> releases? > > Yes, that would simplify the workflow too. > > Best regards, > -- > Mateusz Loskot, http://mateusz.loskot.net > > ------------------------------------------------------------------------------ > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > _______________________________________________ > soci-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/soci-users ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov _______________________________________________ soci-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/soci-users
