On Mon, Aug 13, 2012 at 5:19 PM, Gordon Smith <gosm...@adobe.com> wrote:
> How does Git make merges better than in SVN? > > - Gordon > > In SVN when you make a branch you can essentially move it to any folder when you choose a location. The /branches folder is the typical target by convention, but you can place it anywhere in the repository and that's where your branch goes. In Git when you branch it is actually a project wide atomic snapshot, that is, you don't choose a 'location' for your branch, the entire repository contents are considered a different branch of the project. That is one fundamental difference. Git also has 'rebase', which lets you handle merging different than SVN merging resulting in a much more linear and clearer history. Instead of having "merge commits" where a bunch of code meets together and is merged a rebase handles things differently. When you 'rebase' what happens is Git knows what the 'parent' commit was and it unrolls all of your changes as if you've just made the new branch, and then it puts them away in a 'stash'. Git will then retrieve all of the new commits made to the originating branch, after those are retrieved each commit is re-applied to your branch in chronological order, allowing you to resolve conflicts as they happen as if all commits on both branches were occurring one after the other. Because of this you can handle updating old branches more efficiently and resulting in a cleaner project repository history. -omar
