One of the things I hate about the traditional git workflows describe there is that there is no squashing and the history is basically unusable. We have developers where I work that use our repo as a backup, then when things are merged to master, the history is littered with utter garbage commits like the following:
"commit this before I get on the plane"
"whoops, make this compile"
"WTF?"<p>These add no benefit to history, and actually provide an impediment to bisecting (since a lot of these intermediate revisions will not even compile).<p>At my previous job, we used gerrit. The nice thing about gerrit from my perspective is that it kind of "hid" all of the intermediary stages in the gerrit review. So you could push all you wanted to your gerrit review fake-branch thing, and when you finally pushed to master, there would just be a nice, clean atomic change for your feature. If you needed more detailed history of the steps during review, it was there in gerrit. But master was clean, and bisectable.<p>Is there any git other git tool or workflow which both allows people to back things up to the central git repo AND which allows squashing changes down to meaningful bits, AND which does not loose the history of review iterations?
This article has actually been around for a while. Explains it really great. But one advice from me is that try to choose only what is sufficient to your project and team. No benefit in being overequipped for a simple job.
You can also evolve, basically, to each model in the order that they appear in the article.<p>As an example: I've been working on a new spike for the past 2 weeks with one other developer. Maybe 10 times a day we'll need something that the other person has committed, so we work against one branch (master). The workflow suits this extremely rapid iteration.<p>One repo has now matured to the point where developer branches make sense. We created "develop" on it as well as our own branches off that. We're not close to a v0.1 yet - but we'll be evolving to git flow the minute we want to ship.<p>Eventually as more devs join, we'll need the full-blown PR workflow, that also naturally stems from its predecessor.<p>There's a "meta-workflow" here, which implies which workflow to use.
It amazes me how the entire software industry seems to be adapting its workflows around the necessity of making Git usable. While there are certainly other positive attributes about some of these workflows, the main reason people use them in my experience is because "if you don't use workflow X you get undesirable problem Y with Git". Most of these problems simply didn't exist or were not nearly as severe with previous revision control systems, so we never needed these elaborate workflows. Now suddenly Git is considered a defacto tool, and downstream effects of using it are transforming the entire software development process.
The article completely mischaracterizes Subversion workflows, making the mistake of treating a Subversion repo just like developers typically use git repos ... one-repo-per-project.<p>Subversion instead is a tree with projects as nodes toward the leaves, each project with its own trunk, branch, tags. It's each of these projects that corresponds to a git repo. Teams I worked on always treated each project as its own "repo" ... so the central single Subversion tree became like our 'github' or 'bitbucket' ... and one could do all the lockless branching within each project, no problem. YOU COULD BE AS NON-LINEAR IN THIS APPROACH AS YOU NEED TO BE, with full support for branching, tagging, merging, etc.<p>Where Subversion was much better was in supporting consolidated views of multi-project build / release environments, or in mixing sub-project code in parent-project code. Using svn:external it was each to put "that subproject in this place in my own project". Using git submodules and other approaches is a pain. You end up having to check out a bunch of git repos and managing your own glue.
It'd be nice to see someone collate more git workflows, and what the advantages and disadvantages of these are.<p>Over time, my workflow has become simpler and simpler. I've worked with some weird and wacky workflows before, which have been born from a given requirement, such as quick deployment to a number of different environments, or two separate teams working on separate parts of one codebase while maintaining separate CI workflows. Some of these workflows have seemed absolutely mental, but I've seen them several times over in different places, so there must be some kind of logic to the madness.<p>Different dev teams have wildly different practices, so it'd be good to acknowledge the "typical" way of doing things, and embracing the workflows that work if you need to do something out of the ordinary.
Kudos to atlassian for bringing some much needed clarity to a confusing topic. So many people that claim mastery of git only know particular workflows and, when attempting to mentor others, just mansplain whatever they know without consideration that there are alternative valid ways of doing things.<p>Without a firm grasp of one's intent(workflow) learning git commands is pointless and leads to people desperately flailing out commands.
I think the ideal workflow depends on the complexity you need. I've tried to write about what kind of requirements cause what kind of workflow in <a href="http://docs.gitlab.com/ee/workflow/gitlab_flow.html" rel="nofollow">http://docs.gitlab.com/ee/workflow/gitlab_flow.html</a><p>What do you think?
Or you could actually practice <i>continuous integration</i> and let everyone work on master.<p>Much simpler, opens the door for feature toggles, continuous delivery and more without any merge headaches.