

Bye Bye SVN, Hello Git - chrisferry
http://engineering.secondmarket.com/post/21209487839/bye-bye-svn-hello-git

======
compay
It's 2012, not 2008. Why is the #2 story right now about a company that
switched from SVN to Git?

~~~
recursive
I think there are a lot of people that use subversion.

~~~
compay
At the risk of sounding like an elitist hipster hacker, the core audience of
this site comes here looking to read articles about innovation, not staid,
conservative companies slowly transitioning to established and proven
technologies.

~~~
elliottcarlson
A common issue, especially with fast paced startups, is technical debt. This
debt can show itself in various ways, and the underlying technology that one
uses could be one of those debts. SVN was the popular choice in version
control for a long time, and it wouldn't surprise me that there may have been
startups that chose this because of comfort-ability in the technology, which
has now become a technical debt that will need to be taken care of.

Just because you are an elitist hipster hacker, doesn't mean that this issue
will only pertain to staid, conservative companies.

------
Osiris
I just recently switched to Git after joining a new company. The team I'm on
was just in the process of switching from SVN to Git, so we were all spending
a lot of time online in Pro Git as well as researching various workflows.

I think that we're still not fully taking advantage of Git because the other
members of the team tend to commit and push all the time (so the code is
backed up) but that makes rebasing and squashing quite difficult.

Git has also allowed us to work better with maintaining feature branches and
bug fix branches which helps us to give individual branches to QA for test and
only release those features/fixes that have been QA approved. If a feature
isn't ready on time for deployment, it just doesn't get added to the
integration branch and it'll go out the next release. That's pretty cool.

Personally, I've settled on using SourceTree as a GUI with a fallback to the
command-line for certain operations.

~~~
leetrout
Do you have an anecdote about why having more commits have made rebasing /
squashing difficult? Is it just that team members are pushing their numerous
changes to the central repo? I'm wondering if I'm missing something because I
never squash commits...

~~~
maw
Chances are they're pushing to the same branch or to the same small number of
branches instead of to private-ish branches. This is an easy trap to fall
into: lots of people have a hard time getting used to using branches for
everything.

As for squashing or not, I rarely do, and in general only squash commits that
are simple typo fixes. This makes bisecting much easier.

Also, and this may or may not be relevant, maybe some people are reluctant to
spam the central repository with their own temporary branches. To avoid this,
I have everyone in my team set up a personal, backed up repository. Anyone can
pull from these personal repos, but only their owners can push to them. When
the temporary branches are done, they can be merged.

------
leetrout
Is there a big performance boost for squashing when rebasing? Is it just
housekeeping?

I like what Paul Stadig had to say on the topic
[http://paul.stadig.name/2010/12/thou-shalt-not-lie-git-
rebas...](http://paul.stadig.name/2010/12/thou-shalt-not-lie-git-rebase-
ammend.html)

~~~
nirvdrum
It can make reverting a feature easier if the branch being merged had
intermingled with master several times. You could avoid that by rebasing your
topic branch before merging, but that's lying too. I personally never rebase
unless I need to fix a commit message and I only squash merge if I had a
series of ping-pong commits while trying to fix something.

------
rjzzleep
i think this is the place to remind of torvalds git talk
<http://www.youtube.com/watch?v=4XpnKHJAok8>

------
eblume
I personally discourage the use of squash, I think that everyone benefits with
more granular commits. Is this not common practice?

~~~
mlysaght
We think that a repository with too much noise isn't so useful. When you
squash you should use common sense and aggregate the commit comments as you
see fit.

------
ankimal
The best practices for git IMHO:

<https://github.com/nvie/gitflow>

~~~
thibaut_barrere
We used that a bit but in the end it it was overkill for our needs. All our
projects are now handled in "githubflow" mode.

------
georgieporgie
_Historically with SVN, branching was skittish._

Really? How? I've always found Subversion branching to be painless, reliable,
fast enough, and merges often go flawlessly, and it's really not been that
hard to resolve merge conflicts.

~~~
cheald
Branching with SVN requires creating a separate copy of the entire repository,
effectively. It rapidly becomes unwieldy with larger projects.

