
Comparing Git Workflows - AJAlabs
https://www.atlassian.com/git/tutorials/comparing-workflows
======
drewg123
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?"

These add no benefit to history, and actually provide an impediment to
bisecting (since a lot of these intermediate revisions will not even compile).

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.

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?

~~~
mikegerwitz
> the history is littered with utter garbage commits like the following:
> "commit this before I get on the plane" "whoops, make this compile" "WTF?"

You have a problem with commits here, not the lack of squashing. A messy
history is only messy if you make it so.

> These add no benefit to history, and actually provide an impediment to
> bisecting (since a lot of these intermediate revisions will not even
> compile).

This is also a problem---every commit should compile, even if only for
precisely the reason of bisecting.

Squashing commits is avoiding the problem; instead, perhaps educate the others
on proper practices for committing, and enforce those practices.

~~~
jasode
_> \--every commit should compile,_

No, that advice is wrong and not relevant to a git _private_ branch. That
_strict & disciplined_ attitude about commits was relevant for older
centralized source control tools with lock/checkout/checkin/unlock such as CVS
and SVN. In that previous scenario, your colleagues depended on the shared
repo to properly compile and therefore, you shouldn't "break the build" and
derail the team.

 _> educate the others on proper practices for committing, _

On a private branch, people should commit _whenever they want_ on any whim of
a reason. This will result in many commits that don't compile/build. That's
ok. That's what the later step of "squash" into "logical" commits is for.

To repeat a previous comment about it:

The confusion is that the same "git commit" command is used for 2 very
different semantic purposes:

(1) git commit -m "fixed bug #23984" \--> as Logical-Unit-Work and worthy of
bisect

(2) git commit -m "wip" \--> as meaningless backup/savepoint like Ctrl+S save

The type (2) was for the programmer's internal purposes of safety backups,
cleaning up whitespace, typos in comments, reflexive muscle memory of saving
often, etc. Type (2) commits can have deliberate broken syntax and they're not
meant to be built or be bisected.

Type (2) commits should never be discouraged because saving work often
(including broken midstream work) is a good habit but from an outsiders
perspective of the reviewers upstream, they are way too noisy. The spurious
commits could be less than 30 seconds apart with no compile/build step in
between.

 _> Squashing commits is avoiding the problem_

I hope it's now clear that "squashing" is the _correct tool_ for Type 2
commits.

~~~
harperlee
But if I commit on a whim, e.g. before jumping on the plane, how can I then
patch to separate some changes in two commits?

~~~
jon-wood
I'll often use WIP commits at the end of the day, or when context switching to
something else, then when I'm ready to carry on I reset back to the previous
commit and it's like nothing happened.

------
useryMcUserface
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.

~~~
edu
This, over complicating the git workflow will make people not using it. In my
experience the feature branch works for 80% of the projects, gitflow works for
bit projects and I guess (no experience there) that the forking will work for
open source projects or HUGE code bases.

~~~
lamontcg
even reasonably large open source projects don't need anything beyond feature
branches and one long-lived master branch.

and if you're going to back port to historical releases and hotfix and or
patch them, its better to fork off master and then cherry-pick back, and then
eventually end those branches.

------
zamalek
You can also evolve, basically, to each model in the order that they appear in
the article.

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.

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.

Eventually as more devs join, we'll need the full-blown PR workflow, that also
naturally stems from its predecessor.

There's a "meta-workflow" here, which implies which workflow to use.

~~~
teen
developer branches never make sense

~~~
zamalek
Excluding the possibility of a laptop getting lost or stolen.

~~~
watersb
git is not [necessarily] a backup.

------
zmmmmm
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.

~~~
dpc_pw
"Most of these problems simply didn't exist or were not nearly as severe with
previous revision control systems"

Are you kidding? :)

CVS, Subversion, Perforce, and some propriety revisioning systems were HUGE
PITA. People used to lock files, so noone else could change them when they
were working with them. Merging different feature branches was like locking
whole repository with huge lock, so noone else could touch anything at the
time.

Any time I had to work with legacy revisioning systems I wanted to kill
myself. Git workflows are conventions to help improve small issues with staff
that wasn't even possible befor (before Distributed VCS). And a lot of these
problems are superficial ("oh those merge commit are annoying in `git log`").

It reminds me:
[https://www.youtube.com/watch?v=ZFsOUbZ0Lr0](https://www.youtube.com/watch?v=ZFsOUbZ0Lr0)

~~~
jimbobimbo
In Subversion you'd need to explicitly lock the file, it doesn't _require_ it.
Merge the is also not as bad as you're describing. I actually had more
headaches with merges in Git than in Subversion.

------
nwatson
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.

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.

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.

------
EnderMB
It'd be nice to see someone collate more git workflows, and what the
advantages and disadvantages of these are.

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.

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.

------
crispyambulance
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.

Without a firm grasp of one's intent(workflow) learning git commands is
pointless and leads to people desperately flailing out commands.

------
sytse
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
[http://docs.gitlab.com/ee/workflow/gitlab_flow.html](http://docs.gitlab.com/ee/workflow/gitlab_flow.html)

What do you think?

------
axelfontaine
Or you could actually practice _continuous integration_ and let everyone work
on master.

Much simpler, opens the door for feature toggles, continuous delivery and more
without any merge headaches.

------
jupp0r
Those are general development models and not specific to git.

------
kevinSuttle
Was this updated recently? This has been up for awhile.

~~~
AJAlabs
Yes, the article has been up for a while

------
Bromskloss
What was the workflow in mind when Git was designed?

