3 reasons to switch to git

http://markmcb.com/2008/10/18/3-reasons-to-switch-to-git-from-subversion/

by jwilliams • 18 years ago

40 37 18 years ago

sfamiliar• 18 years ago

seems like git isn't designed to handle long-running branches, or branches with more than one committer. i'm still pretty novice at git, and was hoping this article could clear that up, but mailing patches around seems .. inefficient.

anyone want to correct me? i like git in most respects, and am now using it on a few projects.

jotto• 18 years ago

with git you don't checkout, you clone. then you branch that clone locally. if you want other people to work on that branch, you can git push that branch to the origin server repository, and other people can then git pull it, and of course any member can then simply git push it whenever they commit and it will be widely available.

orib2• 18 years ago

Hm? Why would you think that?

Did you realize that your master/ branch is just one such long-running branch, and one that's not special in any way other than being the default for some commands...

As far as multiple committers on one branch -- well, you can do it, but with 'git rebase' and friends, it's just easier to do your own work on a short lived branch off your primary branch, and just merge in stuff as you get it done.

It's not that git makes it difficult to do it compared to other version control systems; it's just that it's a nicer workflow if you use short-lived topic branches to do development because you don't to worry about what other people are doing until you decide you want to take a look at it and merge it in. The short-lived private branch + lots of merges workflow is just easier because it prevents interruptions in your workflow.

As far as emailing patches, it's a matter of taste. It's certainly easier to make sure all changes get reviewed if patches are mailed around, because people tend to read their mails. Personally, I just use a post-update hook to mail out a list of changes for each commit, and review them later, since it's always relatively easy to back out or fix a patch -- after all, it is a version control system.

axod• 18 years ago

"You’d like to work on each of your 4 features A, B, C, and D independently and somewhat in parallel, though B looks like a quick win."

Does anyone here seriously work like that?

Seems like git has some advantages if you branch a lot, but I don't think branching too much is particularly healthy. I can see why it's good for open source if you have a ton of contributers, but what's the win for a small team who hardly ever branch?

astrec• 18 years ago

I don't use git, I use bazaar - but yes, I often work like that. Why? Sometimes my headspace fits one class of problem better than another, other times I might want to push a largish patch early to another team member, sometimes you want to break a lot of stuff as is often the case with exploratory programming. Short lived branches can be very handy.

timtrueman• 18 years ago

Yes. At work we've got several small teams (sometimes just one person), and each work on their own branches (basically, there's release branches and branches with shared content too). With a single team or just a handful of people this may seem crazy but honestly not branching often just doesn't scale well beyond a certain number of engineers. So you're right, for a small team it may not be worth it. Yeah it's easy to lean across the table and tell your cofounder they broke the build but I'd still say it's a good habit, since you can always launch versioned code and not include any unfinished features (and potential security holes).

LogicHoleFlaw• 18 years ago

At work here we have separate branches for each major feature release under parallel development. There's another branch for any high-priority fixes going into production outside of the normal release schedule. There's a lot of merging going on cross-branch and git would make this whole structure much easier to follow. We're using CVS and honestly it's a huge pain for our workflow.

mojombo• 18 years ago

I do this all the time on the GitHub repo itself. I'll have an idea for a small tangential feature (like per-repo pageview stats) that I want to spend an hour hacking on to see if it goes anywhere. By branching off master, I can experiment to my heart's content and then just shelve the feature easily if I don't finish it. Then later on, getting it back is just a single command away. Git really is a hacker's best friend. It facilitates exploration and experimentation of code. Fits perfectly with a startup mentality.

timr• 18 years ago

You can branch and merge easily with SVN, too. What does Git add, other than the ability to do it locally?

maw• 18 years ago

Does anyone here seriously work like that?

Sure, why not? I create a branch for nearly every series of edits (aside from tyop-fixing bugfixes) that I do, usually to fix a bigger bug or to create a new feature. If it works out, great: I merge it into the master. If it turns out to be a dead end, or is taking too long, I can delete the branch, or just put it aside with the intention of rebasing it later.

...but I don't think branching too much is particularly healthy.

Again, why not? Ignoring for the moment problems which are social at their root and not a dvcs' fault, most likely either you're creating lots of dead ends in those branches, which isn't such a bad thing because it also means that you're also trying out lots of ideas and exploring the problem space; or you're merging those branches, so you're doing good work and getting it integrated into the project.

nihilocrat• 18 years ago

I think it's considered unhealthy because it's another layer of complexity you have to deal with, and a many-branched environment without any system-enforced meta-structure can result in huge amounts of confusion when things don't go right. You have to train your team and trust everyone to avoid all human error. Example: "whoops, I just merged a bad branch into the master one, but I just left work for the day and I don't find this out until tomorrow morning, let's hope no one checked it out in the interim or we're boned!"

With a centralized VCS (or more specifically a single- or few-branched repo), you just tell people to checkout code, commit their changes, and you're done. There are less places to screw up because you don't have a bunch of branches you have to manage. You are less flexible, but this lack of flexibility only becomes a huge burden in a truly distributed (i.e. open source) environment.

It's sort of like arguing static vs. dynamic typing. There are many cases where dynamic typing resulted in very painful errors because some variable along the line didn't follow the "gentleman's agreement" that it should be a list and not a string. Though dynamic typing is more flexible and powerful, sometimes you just succumb to human error because the computer trusts you.

dzorz• 18 years ago

An appeal to authority argument: newly released Android code is kept in git repository. Google built a new wrapper around git called "repo".

bradgessler2• 18 years ago

When you delete the master branch, you are enlightened.

silentbicycle• 18 years ago

Explain.

astine• 18 years ago

The concept of a primary working tree is a relic of non-distributed VCS? I could see working with several branches or versions of a project but not having any single canonical version. I've never done it, but I could see working that way.

eltiare• 18 years ago

Ha! That's awesome!

mtodd• 18 years ago

Haha, nice.

swombat• 18 years ago

Only one reason needed:

git > svn

artificer2• 18 years ago

Each version control model has it's own merits and drawbacks, and there will always be situations where one is good and another isn't. For example, while many OSS projects have switched to distributed vc's such as git and mercurial, two of the largest oss projects still remain loyal to Subversion, FreeBSD and KDE. If you search their mailing list archives, you will see that after long thought, both projects decided that the Subversion model reflects better their development style. So, no, git is not simply "better" than subversion, it just reflects a different development methodology.

albertcardona• 18 years ago

The nice part is that with git, one can interact with svn projects seamlessly via git-svn -- so endless local commits may be repacked to one single remote commit or push.

But svn lacks suh flexibility to interact with others. Hence git > svn, as in svn is a tiny subset of git.

artificer2• 18 years ago

It's not so simple. For example, if I remember correctly,git lacks a way to checkout and work on a small subset of a development tree, as it tracks whole trees at a time. This feature is something that svn and cvs offered long ago. To do that with git you have to break the tree into small sub-trees, as the X.org guys have done. This may be considered as a drawback for some people.

For more information on why git was not chosen instead of svn for FreeBSD you can look at http://wiki.freebsd.org/VCSWhy

Again, each vc has it's uses, and nothing is merely a 'subset' of another.

pmjordan4• 18 years ago

I'll add a fourth, which is the "killer feature" for me and my current workflow:

Git allows working from more than one system at once without requiring a constant server connection. When I'm on the go and want to make changes to my code from my laptop, I can make commits, I've got access to the full history, etc. All that's required is a pull from my desktop before I leave my office, and I've got a shell script that pulls the repositories for all my projects at once.

With something like SVN, this kind of thing was a major pain, as I'd either have to work just with my local copy on the laptop (leading to poorly tracked mega-commits), or copy the whole file system structure of the repository to the laptop, which quickly gets you into desynchronised territory. Add another developer and you're instantly dead with that kind of system.

lliles• 18 years ago

Same here... I work on the train during my morning/evening commute to the office. Being able to commit and branch offline is a major win.

thomasmallen3• 18 years ago

Mercurial provides the same "killer feature", which I think nullifies any "killer feature" status for git (implies exclusivity, I believe).

pmjordan4• 18 years ago

Fine. Call it the killer feature of distributed version control systems. Works for me, in any case.

markessien• 18 years ago

I sometimes feel like the technology world is similar to the fashion industry - this year CVS is, then it's suddenly SVN, and when I make the switch, everyone is using GIT, and I'm sooo last year with my SVN.

I'll wait out the GIT wave. If it's more dominant than SVN in 2011, that's when I'll switch.

mechanical_fish• 18 years ago

As others have mentioned already in this thread, the git-svn bridge works very well. You can adopt git and get a bunch of its features (local repository mirrors and multiple local branches) while still working atop your SVN repository. You give up some things (you can't really do cross-repository merges with git-svn -- when you want to communicate with your peers you have to do it via the SVN repo) but it is still great. It's not worth waiting another five years for the extra features. ;)

I've found that the CVS-to-git workflow is a bit more annoying. You can import CVS repos into git, but you can't really push anything back without using patches.

MicahWedemeyer• 18 years ago

As a recent switcher to git, I like your fashion analogy. It's like I'm wearing what others call the latest fashion, but it sure looks the same to me. All the colors are different, but I end up wearing it the exact same way.

davidw• 18 years ago

I just started playing with git, and yeah, it's definitely better in a few ways, but it didn't jump up and start writing code for me, so your approach is a sensible one. My guess is that companies are not made or broken on the differences between vc systems - as long as you have a decent one, you're ok.

3 reasons to switch to git

Related Stories