On Tue, Aug 14, 2012 at 7:58 AM, Greg Reddin <gred...@gmail.com> wrote:
> On Tue, Aug 14, 2012 at 9:53 AM, Omar Gonzalez > <omarg.develo...@gmail.com> 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 integrating. 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 (flex.next). 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 efficient. -omar
