5 ms·

3 reasons to switch to git

40 points by jwilliams 18y ago

sfamiliar 18y 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 18y 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.
- orib 18y 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 18y 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 18y 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 18y 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 18y 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 18y 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.
dzorz 18y ago
An appeal to authority argument: newly released Android code is kept in git repository. Google built a new wrapper around git called "repo".
bradgessler 18y ago
When you delete the master branch, you are enlightened.
- silentbicycle 18y ago
  Explain.
  - astine 18y 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.
    - bradgessler 18y ago
      Exactly. On our project we deleted the master branch in favor of having two branches we work off of: production and development. The production branch reflects what is in production while development contains new completed features that each developer builds in all of their own branches.
- eltiare 18y ago
  Ha! That's awesome!
- mtodd 18y ago
  Haha, nice.
swombat 18y ago
Only one reason needed: git > svn
artificer 18y 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 18y 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.
  - artificer 18y 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 http://wiki.freebsd.org/VCSWhy Again, each vc has it's uses, and nothing is merely a 'subset' of another.
pmjordan 18y 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 18y 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.
- thomasmallen 18y ago
  Mercurial provides the same "killer feature", which I think nullifies any "killer feature" status for git (implies exclusivity, I believe).
  - pmjordan 18y ago
    Fine. Call it the killer feature of distributed version control systems. Works for me, in any case.
    - thomasmallen 18y ago
      Why do you prefer Git to Mercurial? I've only used Mercurial.
      - pmjordan 18y ago
        I'm not an expert in git (still learning) and I've hardly used Mercurial at all, so right now there's no particular reason. There are probably better people to ask that question. :) I'll try hg in a project sooner or later, but learning to get to grips with 2 version control systems at once while trying to do something productive seemed a bit much. There wasn't really anything on the feature lists that tipped the scales; the Linus Torvalds association and the resulting curiosity probably did. I can't believe I fell for a celebrity endorsement. ;)
markessien 18y 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.
- MicahWedemeyer 18y 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 18y 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.
- mechanical_fish 18y 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.

40 points by jwilliams 18y 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 18y 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.
orib 18y 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 18y 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 18y 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 18y 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 18y 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 18y 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.

dzorz 18y ago

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

bradgessler 18y ago

When you delete the master branch, you are enlightened.

silentbicycle 18y ago
Explain.
- astine 18y 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.
  - bradgessler 18y ago
    Exactly. On our project we deleted the master branch in favor of having two branches we work off of: production and development. The production branch reflects what is in production while development contains new completed features that each developer builds in all of their own branches.
eltiare 18y ago
Ha! That's awesome!
mtodd 18y ago
Haha, nice.

swombat 18y ago

Only one reason needed: git > svn

artificer 18y 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 18y 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.
- artificer 18y 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 http://wiki.freebsd.org/VCSWhy Again, each vc has it's uses, and nothing is merely a 'subset' of another.

pmjordan 18y 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 18y 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.
thomasmallen 18y ago
Mercurial provides the same "killer feature", which I think nullifies any "killer feature" status for git (implies exclusivity, I believe).
- pmjordan 18y ago
  Fine. Call it the killer feature of distributed version control systems. Works for me, in any case.
  - thomasmallen 18y ago
    Why do you prefer Git to Mercurial? I've only used Mercurial.
    - pmjordan 18y ago
      I'm not an expert in git (still learning) and I've hardly used Mercurial at all, so right now there's no particular reason. There are probably better people to ask that question. :) I'll try hg in a project sooner or later, but learning to get to grips with 2 version control systems at once while trying to do something productive seemed a bit much. There wasn't really anything on the feature lists that tipped the scales; the Linus Torvalds association and the resulting curiosity probably did. I can't believe I fell for a celebrity endorsement. ;)

markessien 18y 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.

MicahWedemeyer 18y 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 18y 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.
mechanical_fish 18y 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.