Edward Diener wrote:
Tell me how git magically manages to merge changes by multiple developers to the same file when a local repository is pushed to another one somewhere else.
I feel like the little boy declaring that the emperor has no clothes. No need - a certain amount of scepticism and critically questioning a
of course git does not magically solve that. i think the difference between svn and git to some extent is a different mentality: while both technically do support branching and merging, the process is much more heavyweight in svn than in git: an svn branch is often considered to last for weeks or months or even permanently - and once the big new feature it was created for has reached release maturity, merging the changes back in is a rather massive job. releases have failed because of this - code builds fine in dev branches, but once it's all merged, nothing compiles. this integration problem is one of the reasons why the whole continuous integration concept has come up in the last decade, see http://en.wikipedia.org/wiki/Continuous_integration. git circumvents this problem to some extent by anticipating the need for branches and merges as a central concept and incorporating it on a much lower level than svn; branches are much more lightweight and are possibly created and merged back in several times a day. Edward Diener wrote: proposed change is necessary to verify a concept is sound. I was not really convinced of git's benefits until I actually gave it a good test run on a small open source project on github. Takes only a couple of minutes. I also found I had to let go of my conventional understanding of source control systems: In contrast to a central svn server where one single head revision is pushed forward by changes from the team, git feels to me more like sets of changes are passed around between local repos - and one of them - one that gets special TLC - is the master branch. Does that makes sense ? # ssc