# Another important difference to understand is that you '''always have a complete copy of the remote repository on your machine'''. In git you'll never commit to the server but always to your local repository. This is nice as you can commit wherever you are, even without connectivity and in any case much faster than over the net. From time to time you'll synchronize your local repository with the server to publish your changes to others on the web and to receive changes others have published in the meantime. The downside of this flexibility: Not only do you need version control commands as in CVS (checkout, branch, merge, commit, ...). You also need a whole suite of synchronization commands (pull, push, fetch, remote, ...).

# Another important difference to understand is that you '''always have a complete copy of the remote repository on your machine'''. In git you'll never commit to the server but always to your local repository. This is nice as you can commit wherever you are, even without connectivity and in any case much faster than over the net. From time to time you'll synchronize your local repository with the server to publish your changes to others on the web and to receive changes others have published in the meantime. The downside of this flexibility: Not only do you need version control commands as in CVS (checkout, branch, merge, commit, ...). You also need a whole suite of synchronization commands (pull, push, fetch, remote, ...).

# And finally a big warning: Git gives you a lot more (too much?) freedom to manipulate version history than CVS. In git there is no separation between repository administration and usage. This includes that git imposes no real constraints on retrospective changes (including commit comments, parent-child relationships between versions, changes contained in commits, etc.). If, however, you do these retrospective changes after others already have copied them from your public repository then you'll cause your colleagues a lot of headache. They'll not be able to merge from your development branch as you've destroyed the "historical link" that binds the state of their local repositories to your repository. In other words: There is no danger if you change whatever you've not yet published. That's what git's freedom is for. But '''never change what you've published'''. Whenever you use the -f/--force switch, keep in mind that you're about to change history (how pathetic ;-)).

# And finally a big warning: Git gives you a lot more (too much?) freedom to manipulate version history than CVS. In git there is no separation between repository administration and usage. This includes that git imposes no real constraints on retrospective changes (including commit comments, parent-child relationships between versions, changes contained in commits, etc.). If, however, you do these retrospective changes after others already have copied them from your public repository then you'll cause your colleagues a lot of headache. They'll not be able to merge from your development branch as you've destroyed the "historical link" that binds the state of their local repositories to your repository. In other words: There is no danger if you change whatever you've not yet published. That's what git's freedom is for. But '''never change what you've published'''. Whenever you use the -f/--force switch, keep in mind that you're about to change history (how pathetic ;-)).

+

+

[http://schurmanjessica.wordpress.com/ Stryker Hip Replacement Blog]

Revision as of 08:29, 30 January 2013

The most fundamental difference between git and CVS is that git never keeps files but always full repository directory trees versioned. You simply cannot "commit a file" in git. You'll always commit snapshots of the whole project which are uniquely identified by an SHA hash over the whole code source tree! These snapshots can then be linked to each other arbitrarily. That's why in git it is so easy to have several parents to a current version (=merging) or several children (=branching) to a common ancestor. In CVS branching and merging is extremely complex as all changes have to be expressed as patches between file versions.

Another important difference to understand is that you always have a complete copy of the remote repository on your machine. In git you'll never commit to the server but always to your local repository. This is nice as you can commit wherever you are, even without connectivity and in any case much faster than over the net. From time to time you'll synchronize your local repository with the server to publish your changes to others on the web and to receive changes others have published in the meantime. The downside of this flexibility: Not only do you need version control commands as in CVS (checkout, branch, merge, commit, ...). You also need a whole suite of synchronization commands (pull, push, fetch, remote, ...).

And finally a big warning: Git gives you a lot more (too much?) freedom to manipulate version history than CVS. In git there is no separation between repository administration and usage. This includes that git imposes no real constraints on retrospective changes (including commit comments, parent-child relationships between versions, changes contained in commits, etc.). If, however, you do these retrospective changes after others already have copied them from your public repository then you'll cause your colleagues a lot of headache. They'll not be able to merge from your development branch as you've destroyed the "historical link" that binds the state of their local repositories to your repository. In other words: There is no danger if you change whatever you've not yet published. That's what git's freedom is for. But never change what you've published. Whenever you use the -f/--force switch, keep in mind that you're about to change history (how pathetic ;-)).