

Git is cheap - beghbali
http://coderwall.com/p/wxowig

======
skrebbel
I strongly half-agree here.

 _Commit early_ , hell yeah!

 _Branch often_ , umm, no. I feel that the excellent branching features of
modern DVCSes have made people lazy and afraid to confront the inherent
concurrent nature of working in parallel with people on the same codebase.
Sure, if you're a 200 person team, there might be no way around it some decent
branching setup. But don't forget: _every feature branch means postponing
continuous integration_.

Continuous integration is the _core_ of any productive and effective agile-ish
team. Daily standups are nice, backlogs are lovely, but without continuous
integration you can't get that design-develop-test cycle short enough to
deploy/demo early and often.

Therefore, when working on a product or component with a limited team size
(say, up to 15 people that are in close contact with one another), I believe
that it is best to get your code on the mainline _as fast as possible_. Often,
in git terms, the simplest way to do this is simply directly committing and
pushing to master. Doing this helps signal conflicting concurrent work early,
and it helps avoid double work. It encourages necessary but unforeseen design
sessions _before_ the work is done, rather than refactoring sessions
afterwards.

The only strong downside to super-fast continuous integration that I can see
is the chance that you "break the build" (or the tests, or whatever your
situation has that needs to be OK for developers to be able to add features).
If the team is in close contact, this is typically fixed within minutes ("hey
Mike, you broke xyz.cpp" "oh damn, sorry, i'm right on it"), and if it isn't,
well, git has cherry-picking features for a reason! You can use the tools to
avoid the broken code for a few hours until the guy who broke it is back from
the hairdresser.

Sure, you can do good CI with feature branches, but people have to be
disciplined, and push their feature branch with master very often. Like,
multiple times per day. I've never seen that work in practice. This doesn't
mean that it can't work in practice, but it does mean that "branch away,
buddy!" may be bad general advice.

When committing straight to master, the danger is of course that people hold
back pushing their commits over the line entirely, which is bad too, but I
find that once the horrible, horrible "whoever breaks the build gets pie" rule
is replaced by the "whoever pushes more than x changed files/lines at a time
gets pie" rule turns that culture around just fine.

I'll be the first to admit that this might work less well with e.g. highly
distributed teams in different timezones. But that's hardly the most common
scenario.

Continuous integration is called that for a reason. If you do A-few-times-a-
week-integration, then call it that. And in my opinion, you're missing out.

~~~
i386
DVCS does not discourage Continuous Integration as long as the developer
pushes remotely on a regular basis to their own branch and the CI server is
setup so that it builds the known active branches.

I've been working on solving this problem over the last year. We added the
ability to Bamboo (CI server by Atlassian) to detect new branches as they are
created in the remote repository and automatically test the merge with master
and optionally push the branch to master if everything is OK. If the merge or
the tests fail, Bamboo lets you know immediately via email/XMPP/HipChat/etc.

Yes, it relies on developers being disciplined (read: responsible and
professional) enough to push back to master in order to have the merge tested
and the tests run.

Developers actually do it though because the benefits to having their feature
branch tested regularly against master are huge: code is regularly merged and
tested with master to ensure integration state and other team members are
isolated from changes that can potentially damage development velocity.

Anyhow, if your interested in learning more, see my blog post called "Making
Feature Branches effective with CI". I'd love more comments and thoughts if
you have them.

[http://blogs.atlassian.com/2012/04/bamboofeature-branch-
cont...](http://blogs.atlassian.com/2012/04/bamboofeature-branch-continuous-
integration-hg-git/)

Disclaimer: I am product manager for Bamboo @ Atlassian

~~~
skrebbel
that looks really interesting, thanks!

~~~
i386
No problems! If you have any questions, feel free to email me
james@atlassian.com

------
campo
I absolutely agree with this. I recently started working on a small web app as
a side project. I was dealing with a lot of elements that were new to me and
was constantly pushing the limits of my knowledge and breaking things. I
realized I wasn't using the power git provided me with branches.

Once I started branching things got quicker and more effective because I could
bounce between tasks without affecting my deployment (master branch). In five
days of frantic coding using git branching I now have a clean easy deployment
of about 750 lines, which I iterated on through four different branches and,
probably over 3000 lines of code.

It's not perfect, but it's eliminated any apprehension about aggressively
changing my application, and made me far more ambitious. I feel great about
it.

~~~
th0ma5
I've had a similar feeling of empowerment, although less structured. With
hobby projects where sometimes I realize I was thinking all wrong about a
certain solution, I'll just check in what I have and commence the deleting of
large blocks. Occasionally I'll go back and find something that maybe was a
good idea, but for the most part, having an excuse to part ways with bad ideas
has alone been really great.

~~~
campo
That's great, reducing the barrier to entry for new projects allows for more
experimentation. More experimentation increases the likelihood you'll stumble
upon something you really like!

What I meant to say more clearly is that I probably iterated through the
creation of that web application so quickly because in five days I committed
to git 75 times. In my time at Microsoft I don't know that I would have made
75 commits in a year, and creating new branches was very costly.

I got numbers on my git repository by using GitStats:
<http://gitstats.sourceforge.net/>

------
doesnt_know
There is another good reason to break commits down into small "bricks" (as the
author calls them) and that is bisect[1]. Up until very recently I only used a
tiny fraction of the git toolbox, but when I was complaining to a friend about
how an app I was working on deployed fine on one machine but not on another
with the exact same configuration he told me to run bisect.

It took me a matter of minutes to zero in on the exact commit that broke the
app on that one machine. This would have been something I would have spent
hours, possibly days trying to figure out by going over every tiny config
detail (it wasn't a config issue).

Bisect is a powerful little tool to have in your back pocket when you know
something you introduced at _some time_ broke _something_ and you need to find
out what. The smaller and more "relevant" you keep your commits, the easier it
will be to use. Obviously the opposite is true, if you have these massive
commits which change large amounts of different files and/or multiple
features, bisect becomes significantly less useful, almost worthless.

[1] <http://git-scm.com/docs/git-bisect>

------
prawks
As this is a positive article about git, if the OP reads this, I'd suggest
using the word "inexpensive" next time. Cheap often has a negative connotation
that something is low-cost at the expense of quality.

Just a pet peeve. Git is most certainly not cheaply made.

~~~
kfinley
Yes, but the phrase "x is cheap" often means -- just use it. "x is
inexpensive" doesn't have the same connotation. E.g. "memory is cheap"

------
tocomment
Is there any best practice for a large team of 50 developers to work in Git?
We have about 20 separate (almost completely separate) projects.

We currently have everything under one big SVN directory. I use git for
personal stuff so it's always a pain to work in SVN.

~~~
_ikke_
In git, I would create a seperate repository for each project. No need to mix
up history of several projects into one repsository.

~~~
Shorel
That's possible to do in SVN as well.

------
rkangel
He compares it to SVN, but makes a classic error. In SVN branches and commits
are just as cheap as in git (albeit marginally slower to create usually). It's
the _merges_ that are expensive.

It's there that git wins, with it's better understanding of how content moves
around, and the ability of the merge tool to see the history and identify the
common ancestor.

~~~
_ikke_
Branching in SVN is not cheap. It basically has to copy the entire directory
structure into a new subdirectory (branches directory).

In git, it just creates one file with a 40 byte hex.

~~~
rkangel
Errr, no - while that's what you see in the directory tree, that's not how
it's done internally. SVN has a data model where multiple paths in the repo
tree can point to the same underlying file object, so a branch requires no
file copies, just updating what the directory tree looks like. Even that is
done in a very efficient way. It might not quite be 40 bytes, but it is
negligibly small.

This technique is in fact extremely similar to how Git works.

------
ripperdoc
Sorry for going off-topic, but I tried to open this on iPhone and it never
finished loading. It's 1.25 MB for one page of 3500 chars of text. Maybe the
ratio of polish vs content is a bit too skewed here?

~~~
icebraining
It's strange that coderwall doesn't seem to gzip their CSS nor JS files. It'd
cut down their biggest file (~450k) to less than 50k.

