| Next revision | Previous revision |
| docs:git:git_vs_svn [2009/11/04 21:49] – created billh | docs:git:git_vs_svn [2010/03/05 16:00] (current) – billh |
|---|
| * git allows multiple "remotes" which are connections to other repositories for the same project. This could be a connection to a public repository, and/or other developer's repositories. Changes from any of these remotes can be "pulled" and merged easily, as well as "pushing" local changes to a remote if allowed. | * git allows multiple "remotes" which are connections to other repositories for the same project. This could be a connection to a public repository, and/or other developer's repositories. Changes from any of these remotes can be "pulled" and merged easily, as well as "pushing" local changes to a remote if allowed. |
| * because git is stored in the .git folder in the local project directory, each developer has an entire copy of the repository. This instantly provides redundancy for failures. If a centralized svn repository suddenly becomes unavailable, all developers will lose work because of the inability to commit. | * because git is stored in the .git folder in the local project directory, each developer has an entire copy of the repository. This instantly provides redundancy for failures. If a centralized svn repository suddenly becomes unavailable, all developers will lose work because of the inability to commit. |
| * git allows a developer to commit when they need to, pull from others and merge later. In contrast, if two developers are using svn and make changes, and one developer commits, the other developer will need to checkout and merge those changes before he is allowed to continue. This commit "race" will slow development since it may be more efficient for the developer to wait until a later time to merge changes from another developer. git allows each developer to make decisions of when to commit and merge. | |
| * git allows commits of portions of changes, instead of just the entire file. This is actually the way git works because it tracks "content changes", not files. You may want a DEBUG variable set for development that shouldn't be committed. git allows you to "stage" any specific change to a file. | * git allows commits of portions of changes, instead of just the entire file. This is actually the way git works because it tracks "content changes", not files. You may want a DEBUG variable set for development that shouldn't be committed. git allows you to "stage" any specific change to a file. |
| * git allows you to easily go back and change the log message of a previous commit to correct mistakes | * git allows you to easily go back and change the log message of a previous commit to correct mistakes |
| * tortoisesvn on windows is awesome (tortoisegit is available, but not as refined just yet) | * tortoisesvn on windows is awesome (tortoisegit is available, but not as refined just yet) |
| * you can version an empty directory (with git, you need to do something like add a .gitignore file to the folder). In case you are wondering why anyone would want to version an empty folder, it could be for something like a log folder or conf folder where files shouldn't be versioned. | * you can version an empty directory (with git, you need to do something like add a .gitignore file to the folder). In case you are wondering why anyone would want to version an empty folder, it could be for something like a log folder or conf folder where files shouldn't be versioned. |
| * since the repository can be controlled by an admin, you can ensure that every developer's commits always exist. With git you have the option to actually "reset" the repository to a previous state. In svn, you need to merge an older revision and commit it in order to "go back in time". FIXME - this is all assuming that the shared git folder is just a publicly available folder. This all may be the same if using apache or a git daemon. | * since the repository can be controlled by an admin, you can ensure that every developer's commits always exist. With git you have the option to actually "reset" the repository to a previous state. In svn, you need to merge an older revision and commit it in order to "go back in time". |
| * since you have a central repository, each commit is automatically giving you a "backup" of your work | * since you have a central repository, each commit is automatically giving you a "backup" of your work |
| |
| ===== svn cons ===== | ===== svn cons ===== |
| * it is common for the sake of administration to keep few repositories. This causes totally unrelated projects to be stored in that repository, such as the development of web sites for clients. Once development of a site is finished, it may never be needed again, but it will always remain and take up space in the svn repository. Since it is advised for git to be used on a project by project basis, all you need to do is delete the project directory. | * it is common for the sake of administration to keep few repositories. This causes totally unrelated projects to be stored in that repository, such as the development of web sites for clients. Once development of a site is finished, it may never be needed again, but it will always remain and take up space in the svn repository. In contrast, since it is advised for git to be used on a project by project basis, all you need to do in git is delete the project directory. |
| |