
Git is Not a New Subversion - tobidobi
http://www.git-tower.com/blog/git-is-not-a-new-subversion/
======
benihana
> _Using branches heavily in your development can make you a better programmer
> like few other habits can._

It was really hard to keep reading after this line. It's like saying painting
your bedroom red will make you better at sex. It's like saying getting a gas-
powered golf cart will make you better at golf. It's like saying changing your
mouse to be inverted on the Y-axis will make you better at computer games. All
of these things change the experience, but they don't make you inherently
better at anything. Just like branching during development.

~~~
jlgreco
I find it plausible that a golf cart could make somebody better at golf.
Without the cart, a non-trivial amount of exertion is spent on a tangentially
related task (getting from hole to hole) instead of on the primary task
(getting the ball from hole to hole). Something that allows golfers to better
focus on golfing could conceivably improve their game.

~~~
kristopolous
ok then: "A paintbrush in hand doesn't make you Monet"

~~~
sp332
"Using paintbrushes heavily in your painting can make you a better painter
like few other habits can."

Still seems to work.

------
atonse
The other really powerful thing with git is the ability to keep a long running
branch and continually rebase with something like develop/master. That way you
can resolve conflicts outside of the main line and then reduce the chances of
a hairy merge.

I've found this to be very useful with large refactorings. It eases the
pressure of having to stabilize everything before a release. If the
refactoring isn't ready for this release, don't merge it back in.

~~~
tobidobi
Absolutely agree! Rebase is a great alternative to standard merges: it keeps
your line of development clean and avoids having tons of "merge knots" in your
commit graph.

------
anton_gogolev
Well, this is Tower's blog, but stating that Git was "the first system that
was deliberately built around" branching is too arrogant.

Nevertheless, branches are really just a (albeit nice) side-effect of the fact
that Git (and Mercurial, for that matter) explicitly tracks _changesets_, not
just _revisions_.

~~~
mhaymo
> stating that Git was "the first system that was deliberately built around"
> branching is too arrogant.

Do you have a counter-example?

~~~
anton_gogolev
For one, Mercurial has branching as well. Although technically it was released
12 days later than Git, the motivation for both of them was that Linus
Torvalds decided (for legal reasons) not to use BitKeeper for Linux kernel
development and was in need for a replacement version control system.

Besides Git, Mercurial and BitKeeper, there is also Monotone, which is also a
DVCS.

~~~
stock_toaster
and Darcs. Which is more "patch based". Never used it much, but it has been
around for quite a while (march 2003).

arch/tla/ArX was also an early one (2001? 2003?). I recall it was distributed
and had branching.

------
parennoob
This misses the biggest thing that made me initially switch to git: local
commits.

I can do with only a single branch if necessary, but how the f*ck are you
supposed to develop anything locally and roll back changes in subversion if
you are never allowed to commit because it might break someone else's stuff?

I think there are other svn-alikes that might solve this problem (svk?), but
with pure subversion it is the biggest roadblock for me (and I bet, a lot of
other new coders).

~~~
aidos
It's something you can do in svn already. Granted, it's not as streamlined as
it is in git, and you would need to commit to the remote server, but that's
not the end of the world.

In the old days, before git existed, we used to have a space in the repo for
each developer. You could put whatever you wanted in there. So if you wanted
to go off on a tangent you just copied the code via svn, switched to that
copy, do your work, commit as you please. When you were happy you could
cherrypick / merge into the main branches of the code.

Git makes this stuff easier, but it was all possible with svn. Hell, it was
probably even possible with cvs if you jumped through the right hoops.

~~~
parennoob
Firstly -- it's on the server, as you said, which slows things down. Also, is
there an easy way to rollback, if you don't have certain privileges on the
server?

~~~
aidos
True, but it's a trade off. I've run big svn repos before where we couldn't
have used git because it would have taken up too much space on the client
machines.

In terms of editing the history it's generally just considered something that
you don't need to do.

My point was not so much that git isn't better. It was more that the desire
for the new tech makes people forget what the old tech could do. It happened
when svn took over from cvs. It'll happen when the next tech comes along to
replace it. That's life.

------
caelum
This is nothing that anyone here doesn't already know and agree with. This is
pure blog spam to drive traffic to your application

~~~
garethadams
Amazing! Maybe I could see your blog post where you harnessed the collective
mind of all HackerNews users and became aware of what everyone knows?

------
sergiotapia
It's useful to follow a proper branching model.

Where I work we use master as the release-production-ready code. We branch of
version branches from there. So a 2.5 release will be based off of master.

We work off of develop, and branch out topical branches from there, once
complete merge to develop, test, once approved merge develop towards master.

And so on and so forth. It's very clean and makes it easy to test out other
developer's feature as everything is encapsulated in a branch.

~~~
tobidobi
Same approach here in our team! Basically a very similar model to what "git-
flow" propagates. And actually one that is very easy to understand.

~~~
rallison
And same here. The general git-flow workflow has worked extremely well for us
and has cut down on almost all version control issues we previously had.

------
jebblue
What would be nice is some kind of simple Git that consolidates some of the
multiple command sets that I have to use to do things that are just one
command with SVN.

Also I miss the deterministic nature of SVN Revert, when I run that in SVN it
really makes my working directory exactly as it was that morning before I
started typing. With Git, well with EGit this isn't too hard, Team | Reset |
Hard | References | ORIG_HEAD. It works for me.

------
Touche
I don't trust git stash and prefer to instead commit, leaving some message
like "This is the first commit of branch foo", then rebase when I'm done. That
way I don't have to worry about forgetting that I stashed changes earlier, or
not being able to find the stash that I thought I did. The branch always has
the latest code and i'll just rebase when it's ready.

------
zachsmith
This looks very interesting. I've been reviewing a number of the Git clients
(SmartGit, SourceTree, etc.) It appears that this client integrates features
and context that help one use Git. But I am not clear on how it improves on
Git itself. What are the strengths of Tower beyond those features that are
provided through SmartGit?

~~~
tobidobi
First, let me say that SmartGit is an excellent application, too. However,
most people that chose Tower over SmartGit prefer our approach in regard to
user interface, workflows, usability, etc. Tower goes a long way to make using
Git both as easy and as comfortable as possible.

However, don't believe me ;-) I recommend you download the free trial from our
website and see for yourself.

------
grault
I'm still interested in something which tracks "moves" well. Moving a big
block of text/code into a different file is still lacks the easy-to-see
guarantee that the disappearing and appearing two blocks are the same. Do you
know any techniques for this?

~~~
tbrownaw
Moving a block of code within a file is just a delete+insert as well. I don't
think git differentiates between moving something within a file and moving it
between files the way other systems do, but as far as I know there aren't any
systems that actually understand and track refactorings rather than tracking
diffs.

------
EGreg
I used to think that branching was awesome. And then I realized that what was
REALLY awesome were small, atomic commits. They are the thins that make code
increments readable and let you find the problems better.

Branches are good for isolating longer-running changes but the merges are
often not small. The longer the branch the more chance the merge will
introduce subtle bugs. And the merge has so many lines change, where do you
begin to see where the bug is once you've combined branch A and B?

I've had a coworker argue that NOT having long lived branches avoids this. And
he said at Microsoft they were just fine with mainline - and as soon as they
started branching the trouble always started during the merge.

So what about that?

~~~
tobidobi
I guess it's a combination: a) Granular commits are an essential basis of good
version control. Big, bloated commits (maybe even combining code from
multiple, different topics) will sooner or later bite you. b) Integrating
often. I think you can be successful with long-lived branches, but you need to
have more discipline and not forget to re-integrate from time to time.
Integrating late will naturally raise the risk of conflicts - because, simply,
more changes accumulate.

~~~
EGreg
Why have long lived branches at all?

~~~
tobidobi
A lot of teams have, for example, a "development" branch next to "master"
through the whole project - and are doing fine.

It's a matter of taste and agreement within the team, I'd say.

------
zobzu
When I read that title, I thought this is "GIT is not a failure like SVN".
Oops.

------
angersock
So, here's a story.

My first attempt at "revision control" was multiple copies of files:
"main.cpp", "main_2.cpp", "main_2final.cpp", "main_2finalb.cpp",
"main_2finalb_forreal.cpp", and so on.

This scheme clearly doesn't work.

So, in highschool, we started using SVN. We used it less for its versioning
abilities than we did for its ability to function like a distributed file
share (this was before Dropbox, which sucks rocks anyways). We stored lots of
binary files in it (images, models, etc.), and sadness resulted, but it beat
the hell out of the alternative.

In college, my SVN-foo upgraded--we used SVN properly: updating, resolving
conflicts, and committing changes. It worked well enough, though it still
sucked for binary stuff--and merging conflicts was a pain in the neck.

After college, we started using SVN more cleverly. We started limiting our
commits to functional changes, and documenting very carefully what changed and
why. We tagged branches for release, and kept the repo clean. We moved
binaries off into their own repo.

At my first gig, we used SVN with Eclipse, which was pretty awesome. It had
great merge functionality, it had great team support, and I even learned how
to branch from mainline development in order to do my own projects. I did not
learn, however, how to merge said branches back in any way which did not
involve madness and suffering. Oh, and people would sometimes break the build,
and if you were lucky you read that email (if they sent it!) before you
updated in the morning.

My first few encounters with git were again using it as a distributed file
share, this time hosted on Github--from hackathons and the like. I did not
receive a very good explanation of it other than "that's what we're using for
this project"; I suspect that unless you are really careful it is hard to
explain to somebody new to git how to use it if you have experience yourself.

I later learned to use git to have multiple repos to push to, one for code,
one for staging, and one for production. It was the most magical thing in the
world--`git push production master` and then Heroku is showing my new website.

I finally learned branching and merging when doing my startup earlier this
year; I'd heard about doing topic/feature branches, and we developed a
workflow somewhat like GitFlow. I learned how that worked, and barring the
occasional screwup found it very, very useful.

I'm currently implementing a helper tool for CI and issue tracking with
GitFlow-style workflows. I've had to learn more about how to use the tool, how
to manage branches, and all other things.

~

git is a much more complicated tool to use, effectively, than SVN--at the same
time, I think that getting there is worth it.

I further think that people starting out learning a VCS would be well-served
to use SVN; combine it with TortoiseSVN on Windows and it's pretty simple.
`svn update`, `svn commit`.

That done, when you have a workflow where it makes sense, switch to git. Git
shines for letting you rapidly test things out, and keeping you from stepping
on other people's toes.

I have used SVN for remote team work, and for certain things it's great--
library development, things where you _need_ people not to sit on commits
easily, etc. I think that SVN is a great tool for newer developers, and I
think that it has uses to this day.

That said, once everyone is up to speed on basic git, your team should make
the transition, because it enables you to have more complex workflows and do
more powerful work.

