3 ms·

In the basic use case (changes into a central repo), git and svn look similar. Git's power is revealed when you realize how it tracks changes individually -- it

by kalid 15y ago

In the basic use case (changes into a central repo), git and svn look similar. Git's power is revealed when you realize how it tracks changes individually -- it's super easy to branch and move changes around. The decentralization isn't just on a team level, it's on a per-developer level. Let's say you have 3 bugs to fix. In SVN you might work on them 1 at a time (start to finish -- hopefully no blockers!), or descend into madness and try to work on all 3 simultaneously. In git, you'd make 3 branches and work on each separately. Oh, a hotfix came along while you're halfway through a bugfix? In SVN, you cringe: do I manually copy my changes somewhere else and revert? Ugh. In git, you just make another branch from your clean master, do the hotfix, and pull that change into your bug branches at your leisure. In svn, this branching is theoretically possible, but not used practically -- they are too cumbersome and manual (you need to track what changes went where, and could accidentally apply them twice). I've written more about it here, if you're interested: http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ http://betterexplained.com/articles/intro-to-distributed-ver...

jeltz 15y ago
Additionally for working with multiple fixes at the same time git stash -p, git add -p and friends are great tools. I sometimes see a bug when either fixing another bug or implementing a feature. And if that bug is trivial (i.e. it would take less work to fix it right away compared to remembering it) I can fix it right away, and commit it later in a new branch unrelated to the one I was actually working on. With svn you really do not want to do this since in my experience you can only work at one thing at a time per checked out directory. Instead you have to write it down or try to remember.
- kalid 15y ago
  Totally agree. When first learning git, I got comfortable with git stash: work work, bug comes along, git stash, apply bug to master, git stash apply to get back to my state, work work. Then I started getting comfortable with branches. Git stash is a killer feature that every developer can relate to, and highlights git's power.
- nupark2 15y ago
  > With svn you really do not want to do this since in my experience you can only work at one thing at a time per checked out directory. Instead you have to write it down or try to remember. svn diff >patch-saved-changes svn revert -R . (work work work) svn patch <patch-saved-changes
  - jeltz 15y ago
    I used that all the time when coding with svn, and while not as handy has git stash it is workable. But what I was specifically referring to is the -p flags of various git commands (stash, reset, add, checkout, ...) so you can interactively only stash away what you wish instead of the entire working directory (or an entire subdirectory of it).
    - nupark2 15y ago
      When using git in that way, I spend more time mucking around with cherry picking than I would to just treat things atomically. The tools are more powerful, but they're also correspondingly more complex, and the net value is in my experience negative. People simply feel more productive as the number of knobs they're turning increases. However, SCM is the least important knob in my day-to-day development. What matters to me is turning around quick changes with associated unit tests and ultimately committing code that works the first time. The less I think about SCM knobs, the sooner I can move on to the next piece of actual work.
  - deleted 15y ago
    [deleted]

by kalid 15y ago

jeltz 15y ago

Additionally for working with multiple fixes at the same time git stash -p, git add -p and friends are great tools. I sometimes see a bug when either fixing another bug or implementing a feature. And if that bug is trivial (i.e. it would take less work to fix it right away compared to remembering it) I can fix it right away, and commit it later in a new branch unrelated to the one I was actually working on. With svn you really do not want to do this since in my experience you can only work at one thing at a time per checked out directory. Instead you have to write it down or try to remember.

kalid 15y ago
Totally agree. When first learning git, I got comfortable with git stash: work work, bug comes along, git stash, apply bug to master, git stash apply to get back to my state, work work. Then I started getting comfortable with branches. Git stash is a killer feature that every developer can relate to, and highlights git's power.
nupark2 15y ago
> With svn you really do not want to do this since in my experience you can only work at one thing at a time per checked out directory. Instead you have to write it down or try to remember. svn diff >patch-saved-changes svn revert -R . (work work work) svn patch <patch-saved-changes
- jeltz 15y ago
  I used that all the time when coding with svn, and while not as handy has git stash it is workable. But what I was specifically referring to is the -p flags of various git commands (stash, reset, add, checkout, ...) so you can interactively only stash away what you wish instead of the entire working directory (or an entire subdirectory of it).
  - nupark2 15y ago
    When using git in that way, I spend more time mucking around with cherry picking than I would to just treat things atomically. The tools are more powerful, but they're also correspondingly more complex, and the net value is in my experience negative. People simply feel more productive as the number of knobs they're turning increases. However, SCM is the least important knob in my day-to-day development. What matters to me is turning around quick changes with associated unit tests and ultimately committing code that works the first time. The less I think about SCM knobs, the sooner I can move on to the next piece of actual work.
- deleted 15y ago
  [deleted]