Any branch can be deleted, see 'git branch -d' and 'git branch -D'. Also, remote branches (like one pushed to the origin) can be removed by doing a 'git push origin :branch_name'.
My only question about the use of git feature branches (which I agree should definitely be used) is the workflow used to get the commits on a feature branch back to the master, especially for long-lived branches that are pushed to the origin like Dan is suggesting. Several experiences have taught me that allowing the default git merging strategy (i.e., fast-forward merges) is a very bad idea because it co-mingles all commits when a feature branch is merged back to the master branch. In the event that bad commits need to be plucked out after the merge takes place, fast-forward merges make this task nearly impossible and can create a very big mess. I've learned through experience that it is always a better idea to rebase the master onto the feature branch, resolve all conflicts in isolation on that feature branch and only then do a non-fast-forward merge of the feature branch to the master branch. Using non-fast-forward merging keeps the existence of the feature branch intact (even after it has been deleted and this is key). Use of non-fast-forward merges makes plucking out commits from a feature branch much, much easier. Bruce On Tue, Jun 9, 2015 at 9:34 PM, Daniel Kulp <dk...@apache.org> wrote: > > > On Jun 9, 2015, at 9:56 PM, Clebert <clebert.suco...@gmail.com> wrote: > > > > +1. Although Only question I have: > > > > With git it's not really needed to create a branch in the main repo for > temporary branches. > > Depends on the purpose….. If I was going to work on a relatively large > idea/change and want to collaborate with another committer, a branch at > Apache makes a lot of sense. For example, I’m thinking about creating one > to work on the CXF change. I can keep working on it, all commits would > still go to the commits@ list so everyone can see what’s going on. > Others could help out, etc… Once “done”, it could be merged to master and > the branch removed. > > > But If someone did it thought. Is it easy to remove a branch with > Apache git? I have the impression that you need Infra guys to delete > branches? > > If only infra structure guys can delete branches I would not encourage > branches on the main repo. > > The only branch you cannot remove is master. Anything else is just like > normal. > > Dan > > > > > > -- Clebert Suconic typing on the iPhone. > > > >> On Jun 9, 2015, at 20:22, Daniel Kulp <dk...@apache.org> wrote: > >> > >> I guess if it was up to me to actually write a formal doc describing > the process it would go something like: > >> > >> > >> ——————— > >> > >> ActiveMQ uses a Commit-Then-Review process for getting changes > contributed to the development branches. In general, this means the > ActiveMQ committers are free to directly commit their own work to master > and push those changes to the canonical repository at Apache. However, > the expectation is that the developer has made a good effort to test their > changes and is reasonably confident that the changes that are being > committed will not “break the build.” > >> > >> What does it mean to be reasonably confident? That may depend on the > developer. If the developer has run the same maven commands that the CI > builds are running, they can likely be reasonably confident. However, if > the changes are significant, touches a wide area of code, or even if the > developer just wants a second opinion, they are encouraged to engage other > members of the community to obtain an additional review prior to commit. > This can easily be done via a pull request on github, a patch file > attached to an email or JIRA, committed to a branch in the Apache git repo, > etc… There are a variety of options open to them. Having additional > eyes looking at significant changes prior to committing to the main > development branches is definitely encouraged if it helps obtain the > “reasonable confidence” that the build is not broken and code quality has > not decreased. We also have automatic builds setup to test github pull > requests in advance to help establish a good level of confidence in the > build. > >> > >> However, “things happen”. We’re all human. In the case where the > build does break, the expectation is that the developer will make a best > effort to get the builds fixed in a reasonable amount of time. If it > cannot be fixed in a reasonable amount of time, the commit can be reverted > and re-reviewed. > >> > >> ——————— > >> > >> Everyone: does that about cover it? Did I miss anything? The > github pull requests and gui tools are definitely a good tool chain in > certain cases and I would still encourage those folks that find value in > them to continue using them. However, they cannot be “required”. > >> > >> > >> Dan > >> > >> > >> > >> > >> > >> > >>>> On Jun 9, 2015, at 7:57 PM, Clebert Suconic < > clebert.suco...@gmail.com> wrote: > >>>> > >>>> +1 to stay with the existing CTR practice that is well established in > the > >>>> ActiveMQ community. That's why committership is granted. It's a level > of > >>>> trust and confidence that you don't make low hanging fruit errors. > >>> > >>> I actually screw up all the time ;) But I rather make eventual > >>> mistakes than not do something :) > >>> > >>> Anyways... lets keep the pull requests as a tool. For instance I just > >>> prevented an issue because of a PR Build > >>> > >>> https://builds.apache.org/job/ActiveMQ-Artemis-PR-Build/418/ > >>> https://github.com/apache/activemq-artemis/pull/22 > >>> > >>> But I don't want to talk about the issue itself on this Thread... This > >>> is a meta discussion.. I will talk about the issue itself on another > >>> post I'm about to make > >> > >> -- > >> Daniel Kulp > >> dk...@apache.org - http://dankulp.com/blog > >> Talend Community Coder - http://coders.talend.com > >> > > -- > Daniel Kulp > dk...@apache.org - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com > > -- perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*" );' ActiveMQ in Action: http://bit.ly/2je6cQ Blog: http://bruceblog.org/ Twitter: http://twitter.com/brucesnyder
