Hi, Sorry to see -1s, I was skeptic too and explored every bit of the workflow and usage of git and I think it’s a good model.
TL;DR? I hear you and the wiki is changing a lot, so just go through the cheatsheet and come back to this email: http://danielkummer.github.io/git-flow-cheatsheet If you need a quick intro, see this 6 min video: https://www.youtube.com/watch?v=I-73cssiVC4 If you have time, go through these entire 30+ mins videos: Using git-flow to releave your headaches: https://www.youtube.com/watch?v=NdXhz4rt_sQ What is git-flow: https://www.youtube.com/watch?v=T-miCpHxfds Or, better install git-flow and play with it on a sample repo: https://github.com/nvie/gitflow/wiki/Installation Play with it — http://yakiloo.com/getting-started-git-flow TL;DR again? I would be happy to have a Hangout/Skype/GTM and whatnot call to explain and discuss why this is better than our current workflow and help you reach a conclusion if it’s for you or not. There are several gains of this model, some of them I’ll list below: - A tried and tested convention for over 4 years, so it would take new folks less time to learn the convention - The git-flow tooling is great, there are less chances of collateral conflicts and across release branches (since there is a single release branch) - At any time there are 5 main (type of) branches that you need to understand around which the whole workflow “works" - A rolling release model/workflow is possible - It follows a landing rule that you cannot land changes from release to master, i.e. you never cherry-pick, merge, rebase etc. from an unstable branch to a stable/firm branch - Unlike current release branches, there is a single “released” branch that is master and staging/development branch “develop”. Every release is tagged on master, it would be useful when doing LTS releases - Ability to have support branches, again useful for LTS kind of releases. - I think RMs will like it, as they won’t have to chase around branches or development to find what got in and what not and what to sync from where to where: the rule is simple, you cut out release branch from “develop” work on it, test it and stablize it. At the time of release you merge it to “develop” and “master”. On master you tag the release and you “release” ACS. (Merging from “release” to “develop” may cause conflicts so you fix it) IMHO we can beat any workflow so it can only work if everyone agree and follows the workflow and other good stuff from the Git wiki: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git Hi Prachi, please find my comments in-line below; On 05-Aug-2014, at 8:51 pm, Prachi Damle <prachi.da...@citrix.com> wrote: > Sorry if this is already discussed, but few areas that are unclear to me with > this process are: > > - does every fix, however minor it be(say a signle line), needs to be > developed in a separate branch? And then we have to merge these individual > branches to develop for every fix? Since, it’s hard to know how many commits every bug or feature work may consist of it’s a good idea to start off with a separate branch and sync that branch (back or push) on remote (asf repo or your own github repo); - If you want the git history to have history that you worked on a separate branch when you merge you do: git checkout develop && git merge --no-ff <your-work-branch> --no-ff - Most of the times you may just want a linear history (say one commit in the branch and you don’t want to create a merge commit), you do: git checkout develop && git merge -ff <your-branch> For feature work and a regular bugfix during development you should start a “feature/“ branch and work on it as per the default convention. You use the “hotfix/“ branching/merging on master only when there is a serious bug need to be fixed for already released versions and you need to publish (emergency) releases, the heartbleed bug qualifies for that but not your regular bugs. Shoutout to some folks who have created “hotfix/“ branches, please read above :) > - In that case will direct check-ins to 'develop' branch be not allowed? It’s fine to check-in directly to develop. While doing that, please don’t break develop like it’s expected for master (like at present) :) > - If not, if CI fails on develop branch, how will one know what caused the > failure? Was it some direct checkin Vs some feature/fix merged? Will we > revert all the small feature/fixes that were merged to develop branch upto > the CI baseline? If yes, wont the developers that did not cause the break get > penalized unnecessary? CI/Jenkins will still be needed, this workflow does not guarantee human error causing accidental breakage unlike any other technology. As committers and developers it’s our duty to make sure we either ask the ‘breaker’ to fix it, or revert and politely let them know, or lastly fix ourselves. There is not need to penalise anyone, the reverting part should be done by a human and not a cron job IMHO. > - Lastly, why can't this process be implemented on master? Why are we > introducing another branch for the same purposes which the master branch > usually serves? Well, actually we can. Git-flow allows you to rename the conventional branch. But there is a reason I would want to adopt the convention: - as git-flow is in-fact widely used and it would be easier for people to just follow the git-flow workflow - new folks don'tdon’t have to learn git-flow and then learn the ACS project specific changes we did (we already tried changing the maven convention and it was difficult) - new folks would simply want to checkout master and they would expect it to work Cheers. > > > I am -1 on this. We should not start implementing this until all processes > are clear. > > Prachi > > -----Original Message----- > From: Jessica Wang [mailto:jessica.w...@citrix.com] > Sent: Tuesday, August 05, 2014 11:33 AM > To: dev@cloudstack.apache.org > Subject: RE: [VOTE] git workflow > > Exactly. This just shifts pain from one branch to another. > I don't see any gains from this, either. > I vote "-1". > > Jessica > > > -----Original Message----- > From: Min Chen [mailto:min.c...@citrix.com] > Sent: Tuesday, August 05, 2014 11:27 AM > To: dev@cloudstack.apache.org > Subject: Re: [VOTE] git workflow > > Agree with Animesh. Didn't see any gains from this, we just shift pain from > one branch to another, so vote -1. > > -min > > On 8/2/14 9:50 PM, "Animesh Chaturvedi" <animesh.chaturv...@citrix.com> > wrote: > >> +0 >> >> While this protects master with only commits which are merges from >> release branch and keeps it clean but the issues that we have shift to >> develop branch. >> >> >>> -----Original Message----- >>> From: Rajani Karuturi [mailto:rajani.karut...@citrix.com] >>> Sent: Thursday, July 31, 2014 3:28 AM >>> To: dev >>> Subject: [VOTE] git workflow >>> >>> Hi All, >>> >>> We had long discussions on the git flow. >>> I tried to capture the summary of it @ >>> http://markmail.org/message/j5z7dxjcqxfkfhpj >>> This is updated on wiki @ >>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git- >>> ProposedGitflowbasedCheck-inProcess and is up for a vote: >>> >>> Can you share your opinion on the proposal? >>> >>> [ ] +1 approve >>> [ ] +0 no opinion >>> [ ] -1 disapprove (and reason why) >>> >>> >>> Thanks, >>> ~Rajani >>> >>> >> > Regards, Rohit Yadav Software Architect, ShapeBlue M. +41 779015219 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/> CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/> This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
