Scott Chacon

> Alternatively use git the way it was meant to be used, as a distributed source control system.

Let's not be disingenuous. This is exactly what every git user does when they run `git clone`. You aren't railing against just multiple committers per public repo, you're railing against multiple clones per public repo. One user swapping between two client systems can make this error. Most public repos of any scale will have multiple committers to spread the maintenance workload.

Even Scott Chacon himself describes a simple, effective process called "GitHub Flow"[1] -- just submitting a PR against a branch for merge against master on the same repo. This is a very common workflow on private repos in my experience, and a very easy workflow for small teams.

Making all this worse, the default config setting for `push.default` will only change to "simple" in Git 2.0 -- until then any new host/account that hasn't had push.default changed in .gitconfig is a bomb waiting for the first otherwise legitimate `git push --force` to go off. I've received the batsignal from folks on small teams who've otherwise done all the right things and still been bitten by this.

Fortunately, git has the reflog[2][3] to save us from this kind of mess. It's just not readily accessible on GitHub, AFAICT.

[1] http://scottchacon.com/2011/08/31/github-flow.html
[2] http://gitready.com/intermediate/2009/02/09/reflog-your-safety-net.html
[3]…

After getting hired on my current team my first course of action was to move from gitflow to github flow.

http://scottchacon.com/2011/08/31/github-flow.html

If you break projects into small iterations made up of independent effort and continuously integrate feature branches, you should be able to get away with few long-living branches, and you can rebase the ones that you do have from their upstreams frequently enough that they don't get to where you need to expend lots of merge effort when they're ready to ship.

With gitflow, we were eating lots of effort merging caused by hotfixes. Hotfixes would have to get merged into every branch lest you risk regressing them, no rebasing of development on master (for good reason when there's so many people merging into it), people would forget - and the git extension would only do some of the required merges, so before I showed up the team had a spider's web of merges where changes would get lost and hotfixes regress.

If you must have a stable and active branches, gitflow is fine, but make sure everyone really understands git and what they are doing with it (using the gitflow extension prevents this in my experience), do your due diligence and avoid changes on the stable branch like the plague.

Branching can often be a good strategy if you have a large team and you don't want large uncompleted chunks of work to block quick fixes & deploys, etc. The situation you want to avoid is:

1. Engineers A & B are working on a medium-sized story that's not really done yet, but is in master anyway
2. Somebody discovers a small but critical bug in production
3. Engineer C can write a bugfix very soon, but can't deploy it to production because the other story isn't done yet.

But if your team never ends up saying "I'd deploy that but master isn't clean right now due to different changes", you probably just don't need to branch that much. Maybe your team is smallish or maybe you're capable of always breaking up work into really small increments. It really depends on everybody's situation.

Github does something sort of like this internally: http://scottchacon.com/2011/08/31/github-flow.html

Branching is more overhead in some circumstances but I've also found they can make things much easier. But I also wish that more people were comparing strategies and trade-offs because this stuff gets subtle and there are really lots of ways to do it.

Great read. I'm a huge advocate of using files and version control (specifically markdown and git) for published content, so I hope this workflow catches on.

Two improvements that are worth thinking about:

1) A public repository for content, separate from the main codebase. I was excited by the inclusion of "anyone" in the post title, assuming that they accepted pull requests on existing content (typos, improved documentation, FAQs) from outsiders. Turns out anyone, in this case, refers to anyone on the Pixlee team with access to the private repo.

2) Adopting the GitHub Flow [1] for content. I didn't see any mention of approval before publishing, which is an awesome freebie from piggybacking on git. They did mention that a technical member reviews all changes before deploying, but this is hardly a substitute for an editor or manager overseeing content.

[1] http://scottchacon.com/2011/08/31/github-flow.html

Offhand I can think of a few: ThoughtWorks uses it on most of their projects afaik. Github I believe does as well. They published an interesting blog on their deployment process a couple of months ago.

http://scottchacon.com/2011/08/31/github-flow.html

Where I work at LivingSocial the web application is deployed daily, sometimes dozens of times a day. I've recently taken over the Android project's infrastructure and we're in the process of implementing Continuous Delivery for that app as well.

David Anderson gives examples of implementing it at both Microsoft and Corbis, Bill Gates' other software company.

Don't know if it fits well but its a nice article talking about why github doesn't use gitflow workflow

http://scottchacon.com/2011/08/31/github-flow.html

I am not denying that automated tests are not necessary but I believe that continuously deploying code and then fixing bugs that occur in the code is atleast faster way to code.

Github flow certainly doesn't work very well with mobile development main reason being you cant deply code to production continuously but I was wondering if there is some middle way