Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>It really depends on your workflow. Do you work often from places where you cannot reach your svn server? Do your projects have a large number of branches because you like working on several (big) things at the same time? Do you copy working copies between machines? Do you split off new branches from an existing branch? Do you sometimes work on the trunk and halfway through a bunch of changes think "I should have done this in a branch"? If so, then it may be useful.</p> <p>From a single developer's point of view, the main difference between a central system like svn and a decentral system like git is that in svn the revisions are linear. With git it's a tree. This is useful when you work on bigger features that you want to do in multiple commits.</p> <p>Example: You have a big feature F that consists of changes a, b, c and d. With Subversion you'd either commit a, b, c and d separately on the trunk, or you'd create a branch which means you have to do a lot of merging. With git you check out a working copy, commit a, b, c, and d on it. Then you'd push that as a single change F to your master. So, instead of four commits you see just one commit on the trunk. This makes it easier to see from the log what is going on.</p> <p>You could do this with svn branches as well. But now suppose that part a also consists of multiple parts, like a1 and a2.</p> <p>Such a development model can be done with Subversion. Python Twisted is done that way for example. All development is done on branches and nobody works on the trunk. But git makes such a workflow easier.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload