Git-flow workflow and pull-requests
22 likes16,937 views
Git-flow is a Git workflow that advocates using separate branches for features, releases, and hotfixes. It uses a master branch for production-ready code and a develop branch as the main branch where features are integrated. Feature branches are created from develop and merged back after completion. Release branches are created from develop for final testing before merging to both master and develop. Hotfix branches are directly created from master to quickly patch production releases. Pull requests are recommended to communicate changes between branches.
![Workflows
● like SVN
● based on rebasing
one master branch
● full & light
● master, develop, feature, hotfix and
release branches
● [optional] pull-requests - recommended
● all feature development in a
dedicated branch
● master branch will never
contain broken code
● feature-branches are merged
to master branch
● [optional] pull-requests
LIGHT HEAVY
● fork
● every developer has two
repositories - private local and
server-side public
● feature-branch with pull request
as added functionality/feedback
● popular on github libraries
where we do not have write
access to repository
● [required] pull-requests
images: atlassian](https://image.slidesharecdn.com/gitflowandpullrequests-160415113954/85/Git-flow-workflow-and-pull-requests-5-320.jpg)
![Summary
Git-flow workflow:
Git flow [...] advocates a master branch and a
separate develop branch. [...] [ There are ] supporting
branches for features, releases and hotfixes. The
development happens on the develop branch,
moves to a release branch and is finally merged
into the master branch.
source: http://gitlab.com](https://image.slidesharecdn.com/gitflowandpullrequests-160415113954/85/Git-flow-workflow-and-pull-requests-13-320.jpg)
Git-flow workflow and pull-requests
- 1. Git-flow & pull requests Bartosz Kosarzycki Apr 15, 2016
- 2. Git-flow & pull requests AGENDA ❏ Git competition? ❏ Git workflows ❏ Gitflow workflow ❏ GF: Historical branches ❏ GF: Feature branches ❏ GF: Maintenance & Release branches ❏ Pull-requests ❏ Issues with gitflow ❏ Github-flow, git-lab flow ❏ Merge vs rebase ❏ Git stash vs temporary branches ❏ Reflog ❏ Commit granularity ❏ Comparison of git desktop clients
- 3. Git competition ? ● mercurial is almost history ● main difference was better windows support in mercurial and discouraging rebasing as faking history of commits Stackoverflow: questions tagged7,103 68,906
- 5. Workflows ● like SVN ● based on rebasing one master branch ● full & light ● master, develop, feature, hotfix and release branches ● [optional] pull-requests - recommended ● all feature development in a dedicated branch ● master branch will never contain broken code ● feature-branches are merged to master branch ● [optional] pull-requests LIGHT HEAVY ● fork ● every developer has two repositories - private local and server-side public ● feature-branch with pull request as added functionality/feedback ● popular on github libraries where we do not have write access to repository ● [required] pull-requests images: atlassian
- 6. Gitflow workflow Git-flow workflow: ● has two historical branches - master & develop ● feature branches ● release & maintenance branches ● based on merging ● git plugin is available on github (link) ● is derived from the work of Vincent Driessen (blog)
- 7. Historical branches ● two branches to record history ● usually master & develop ● master is the release-only branch with releases marked as tags; contains only release-ready code ● develop is the progression branch into which cumulative feature-branch funtionality is merged ● when develop reaches a stable state it is merged into master master develop
- 8. Feature branches ● each new feature in its own branch ● only complete, working and tested features get merged back to develop ● develop should be stable so that other devs can branch off it Feature develop feature/a.b.c.functionality
- 9. Feature branches ● synch work with rebasing ● either rebase all commits which are not pushed or branch off and rebase entire local branch and later cherry-pick changes to feature without merge Feature Multiple devs work on a single feature develop feature/a.b.c develop feature/a.b.c feature/a.b.c.local rebasing commits approach origin/feature/a.b.c
- 10. Feature branches ● synch work with rebasing ● either rebase all commits which are not pushed or branch off and rebase entire local branch and later cherry-pick changes to feature without merge Feature Multiple devs work on a single feature develop feature/a.b.c feature/a.b.c.local develop feature/a.b.c feature/a.b.c.local local branch approach
- 11. Maintenance & Release Release Release branches ● where development branch is constantly changing and new feature branches are often merged ● large teams, no feature-freeze? ● minor bug fixes, prepare meta-data for release ● branch off from develop when develop (almost) reflects the desired state
- 12. Maintenance & Release Maintenance branches Maintenance ● “hotfix” branches ● the only branches which fork directly off of master ● should be merged into both master and develop ● quickly fix production releases
- 13. Summary Git-flow workflow: Git flow [...] advocates a master branch and a separate develop branch. [...] [ There are ] supporting branches for features, releases and hotfixes. The development happens on the develop branch, moves to a release branch and is finally merged into the master branch. source: http://gitlab.com
- 14. Pull requests INTERACTION WITH OTHER DEVS COMMUNICATION SKILLS CLEAN DEVEL BRANCH
- 15. Issues with gitflow ● gitflow seems too complex for simple projects ● release & hotfix branches seem redundant (introduce complexity and are an overkill for most projects) ● git log graph is crowded with paths ● alternative github-flow (link) ● alternative gitlab-flow (link)
- 16. Github-flow Gitlab-flow Github-flow Gitlab-flow - master branch as main development branch - new functionality merged via feature branches straight to master - master always ready to deploy - add stable branches like production, pre-production, release etc.
- 17. Merge vs rebase Rebasing Pros Cons ● easiest way to keep feature branch up-to-date with a develop branch ● no redundant merges ● clean, however rewritten history ● easiest and clutter-free way of working on a single shared branch ● merging preserves context ● rebasing pushed commits breaks history for other developers
- 18. Merge vs rebase Rebasing
- 19. Git stash vs temporary branches Temporary branchKeeping temporary changes on local branches: ● enables easy checkout/rebasing/ cherry picking/resetting between branches and commits ● is way safer ● one can have multiple, visible on a graph, temporary changes which branch of in a specific point in development REMEMBER TO PRUNE TEMPORARY BRANCHES REGULARLY!
- 20. Reflog ● enables EMERGENCY rollback of deleted branches ● is GARBAGE COLLECTED automatically (~30 days) ● or manually via git-gc command ● “inception” - revision to your revisions $ git reflog $ git reset --hard ece080d
- 21. ● always compile! ● contain single action/ functionality/ addition/ change ● be well described Commit granularity Keeping well-maintained granularity enables: ● easy rollback when you decide to implement the feature differently ● easy cherry-picking of specific functionality from a feature branch (every commit is separate!) ● describes feature branch and its contents without looking into the files ● makes you safer - you can always use reflog to go back to anything you commited A commit should:
- 22. Git desktop clients OS support: ● OS X ● Windows PROS: ● Free of charge ● Git-flow native support ● very popular CONS: ● no advanced features Atlassian SourceTree
- 23. Git desktop clients OS support: ● OS X ● Windows PROS: ● Free of charge ● Git-flow native support CONS: ● no advanced features Github desktop
- 24. Git desktop clients OS support: ● OS X ● Linux ● Windows PROS: ● Free of charge for non- commercial ● Git-flow support ● Pull-request on internal repositories ● distributed reviews ● excellent git-hub integration CONS: ● PAID for commercial ● appearance SmartGit
- 25. Git desktop clients OS support: ● OS X PROS: ● appearance ● excellent git-hub integration ● stage separate lines ● display changes in tree-view ● Git-flow support ● excellent search ● new-branch, merge by dragging branches ● visual conflict resolution CONS: ● PAID Tower 2
- 26. Resources RESOURCES: ● https://www.google.com/trends/explore#q=mercurial,git ● https://about.gitlab.com/2014/09/29/gitlab-flow/ ● http://nvie.com/posts/a-successful-git-branching-model/ ● https://guides.github.com/introduction/flow/ ● https://leanpub.com/git-flow/read