flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Omar Gonzalez <omarg.develo...@gmail.com>
Subject Re: [DISCUSS] Re: [VOTE] Branching Strategy and SCM
Date Tue, 14 Aug 2012 00:31:24 GMT
On Mon, Aug 13, 2012 at 5:19 PM, Gordon Smith <gosmith@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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message