incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Omar Gonzalez <>
Subject Re: Discuss: Branching Strategy and SCM
Date Tue, 14 Aug 2012 23:49:27 GMT
On Tue, Aug 14, 2012 at 7:58 AM, Greg Reddin <> wrote:

> On Tue, Aug 14, 2012 at 9:53 AM, Omar Gonzalez
> <> wrote:
> > It sounds like hell to me.
> I don't see the hell in it -- at least I don't see the hell that would
> be avoided under a distributed SCM. How would that use case play out
> in git?

This is how it would play out in Git.

1. Greg: git branch maven-support from the dev branch, creating a Maven
Support feature branch
2. Alex: git branch UIComponent-refactor from the dev branch, creating a
UIComponent refactor feature branch
3. Over the course of two or three weeks people commit to both of these
branches. People also commit to trunk.
4. Om decides to make a release from dev branch. A release branch is
created: git branch release-v.1.1.4
5. Updates are made to release to prepare the new version.
6. Om is done preparing the release so he: git checkout dev to go back to
dev branch.
7. Om runs: git merge release-v.1.1.4 on the master branch, triggering a
Jenkins build and deploy of a new production version
8. Om runs: git merge release-v.1.1.4 on the dev branch to catch up the
Flex.Next branch
9. The release branch is tagged "v.1.1.4" and then the release branch can
be deleted
10. Greg and Alex continue to work and not worry about what is happening in
dev or master.
11. Alex completes his work first because he's much faster than Greg :-)
12. After some discussion on flex-dev everybody agrees Alex's work is worth
13. Alex does a git rebase. This takes Alex's current changes and puts them
in a git stash. Git pulls all the latest changes to the trunk since the
point that the branch was created, including latest release, etc. Rebase
reapplies all the changes that were pulled from the dev branch as well as
Alex's changes, in chronological order. This makes merging a lot easier
because you are merging smaller chunks of much more digestable code as
opposed to a huge merge or syncing over and over (disrupting actual
development of the feature).
14. Once the rebase is complete Alex goes to dev branch (git checkout dev)
and runs: git merge my-feature-branch
15. Alex is done merging his new feature to dev branch (
16. Greg does the same process whenever his feature is ready, not having to
constantly merge to make sure he doesn't diverge too much.
17. Alex makes a release from dev the same as Om.
18. Greg continues working not caring what goes on in dev.
19. Eventually Greg & team *finally* finish their work.
20. After discussion on flex-dev everybody agrees that Greg's work is
indispensable and needs to be integrated.
21. Greg does the same as step 10. Easily reapplies all changes to the dev
branch since his original creation of the branch.
22. Greg does a git merge gregs-feature-branch
23. Greg is done integrating his work to dev.
24. Greg makes a release from dev following same steps Om did in step 9.

The main differences are that you don't have to continuously stop your
development in a feature branch to merge code that's been added to the
trunk or dev branches. Git rebase makes rebasing/resyncing your branch with
the latest features a lot nicer. This leads to less time spent in an SCM
program and more time developing Flex. Less time doing svn merge, more time
adding new features. And merging in Git is much easier, and to run into
"merge hell" you have to try really hard to do so.

Branching is different in that in SVN when you branch you copy all the
files of the repository into a new location inside the repository. When you
branch in Git you're not duplicating files to a new location within the
repository, the entire repository becomes a new branch. You view them by
typing "git branch" to see what branches are available, as opposed to
looking in a folder to see the thousands of files that have been put into
branches. When Git creates new branches it is only dealing in metadata that
logs what the new changes are. This not only makes the storage more
efficient and Git itself faster, but it makes managing merges more


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