For the "know your tools" series: let's study the pros and cons of the different GIT workflows and when to apply them, through the story of Eddie, a developer with a constantly evolving project.
his project ➢ Eddie starts a new project, alone ➢ He decides to version with Git ➢ The project become bigger ➢ The team become bigger ➢ Which Git workflow will he use?
master local Eddie’s master ➢ Mike starts working on the repository ➢ Eddie is working on the same commit ➢ Mike pushes a new commit on master ➢ Eddie works on the same file as Mike
workflow ➢ Every feature is isolated in its own branch ➢ Conflicts must be solved in feature branch ➢ When finished it will be merged in master ➢ Eddie can control what’s going on with pull requests
workflow ➢ The application must be delivered in production in short cycles, with new features and bug fixing ➢ There will be many environments (development, staging and production) ➢ Anything on master branch must be deployable in production at anytime
workflow ➢ One “integration” branch for each environment (develop, stage, master) ➢ New feature (or hotfix) branches start from master ➢ A feature (or hotfix) branch can be merged in one of the integration branches ➢ When a feature (or hotfix) branch is ready for production there will be a pull request to master
➢ Made popular by Vincent Driessen (nvie) ➢ Suitable for fixed releases cycle projects ➢ Specific role for each branch ◦ develop and master ◦ feature/hotfix branches ◦ release branches ➢ Command line tool: https://github.com/nvie/gitflow
master contains the release history, with tags develop contains the complete history, and it’s the integration branch for new features feature branches branch off of develop are merged back into develop
release branches branch off of develop when a release is (almost) ready are merged into master and tagged when is ready hotfix branches branch off of master are merged into develop (or the release branch) are merged into master (tagging)
feature and bug fixing process: 1. Mike branches feature/new-feature off of develop 2. Mike works on his branch getting updates from develop sometimes 3. Mike submit a PR to develop and Eddie merges the PR 4. When the new release is almost ready, Eddie branches off release/1.x of develop 5. Eddie merges release/1.x to master tagging with the release number 6. After some time, Eddie report a new bug to Mike 7. Mike branches hotfix/new-bug off of master 8. Eddie merges hotfix/new-bug into master, tagging 9. Eddie merges the hotfix/new-bug into develop and release/1.x Gitflow workflow
➢ Developers who wants to contribute fork the main repository, instead of cloning ➢ They start a new feature branch in their forked repository ➢ They make a PR to the original repository ➢ Eddie merges the PR in the original repository ➢ Developers pull the changes in their forked repository
antodippo
kwakeuijin
javiergs
yusukebe
mackee
igreenwood
pekepek
kentatada
yoshifumi_ishikura
onihusube
seyfoyun
stoneream
tomokusaba
deanohume
addyosmani
kneath
zakiyama
bermonpainter
eileencodes
holman
chriscoyier
shpigford
lemiorhan
