Git Workflows

Comparison and examples of four popular Git workflows: centralized, feature branch, git flow and forking.

Transcript

1. git workflows Tomche Delev M.Sc.
2. Workflow The way you use and incorporate some technology in the daily work process. Guidelines rather than concrete rules
3. Centralized workflow
4. How it works? • Central repository to serve as the single point-of-entry for all changes to the project (master <-> trunk) • Developers clone the central repository • Everything is stored locally isolated from the central repository
5. Push changes
6. Managing conflicts
7. Example
8. Someone initializes empty repository ssh user@host git init --bare /path/to/repo.git
9. Everybody clones the central repository git clone ssh://user@host/path/to/repo.git
10. John works on his feature git status # View the state of the repo git add <some-file> # Stage a file git commit # Commit a file</some-file>
11. Mary works on her feature git status # View the state of the repo git add <some-file> # Stage a file git commit # Commit a file</some-file>
12. John publishes his feature git push origin master
13. Mary tries to publish her feature git push origin master error: failed to push some refs to '/path/to/repo.git' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Merge the remote changes (e.g. 'git pull') hint: before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.
14. Mary rebases on top of John’s commit(s) git pull --rebase origin master
15. Mary rebases on top of John’s commit(s)
16. Mary resolves a merge conflict CONFLICT (content): Merge conflict in <some-file>
17. Mary resolves a merge conflict
18. Mary resolves a merge conflict # Unmerged paths: # (use "git reset HEAD <some-file>..." to unstage) # (use "git add/rm <some-file>..." as appropriate to mark resolution) # # both modified: <some-file> git add <some-file> git rebase --continue git rebase --abort
19. Mary successfully publishes her feature git push origin master
20. Feature Branch Workflow
21. Basic ideas • The core idea behind the Feature Branch Workflow is that all feature development should take place in a dedicated branch instead of the master branch. • Pull requests (easy way for your team to comment on each other’s work)
22. How it works? • Still uses a central repository, and master still represents the official project history • Developers create a new branch every time they start work on a new feature (feature branch) ◦ animated-menu-items, issue-#1662 • Feature branches can (and should) be pushed to the central repository
23. Pull Requests • Discuss changes before merge or ask for help • Once a pull request is accepted, the actual act of publishing a feature is much the same as in the Centralized Workflow
24. Example
25. Mary begins a new feature git checkout -b marys-feature master git status git add <some-file> git commit
26. Mary goes to lunch git push -u origin marys-feature
27. Mary finishes her feature git push
28. Bill receives the pull request
29. Mary makes the changes
30. Mary publishes her feature git checkout master git pull git pull origin marys-feature git push
31. Meanwhile, John is doing the exact same thing
32. Gitflow Workflow
33. http://nvie.com/posts/a-successful-git-branching-model/
34. How it works? • The only difference… • It assigns very specific roles to different branches and defines how and when they should interact. • In addition to feature branches, it uses individual branches for preparing, maintaining, and recording releases
35. Historical Branches
36. Feature Branches
37. Release Branches
38. Maintenance Branches
39. Example
40. Create a develop branch git branch develop git push -u origin develop git clone ssh://user@host/path/to/repo.git git checkout -b develop origin/develop
41. Mary and John begin new features git checkout -b some-feature develop git status git add <some-file> git commit
42. Mary finishes her feature git pull origin develop git checkout develop git merge some-feature git push git branch -d some-feature
43. Mary begins to prepare a release git checkout -b release-0.1 develop
44. Mary finishes the release git checkout master git merge release-0.1 git push git checkout develop git merge release-0.1 git push git branch -d release-0.1 git tag -a 0.1 -m "Initial public release" master git push --tags
45. End-user discovers a bug git checkout -b issue-#001 master # Fix the bug git checkout master git merge issue-#001 git push git checkout develop git merge issue-#001 git push git branch -d issue-#001
46. Forking workflow
47. How it works? • fork the official repository to create a copy of it on the server • git clone to get a copy of it onto local machine • When ready to publish a local commit, push the commit to own public repository - not the official one • File a pull request with the main repository, which lets the project maintainer know that an update is ready to be integrated
48. How it works? • The maintainer pulls the contributor’s changes into their local repository, checks to make sure it doesn’t break the project, merges it into his local master branch • Then pushes the master branch to the official repository on the server. • The contribution is now part of the project, and other developers should pull from the official repository to synchronize their local repositories
49. The Official Repository? Branching in the Forking Workflow
50. Example
51. The project maintainer initializes the official repository ssh user@host git init --bare /path/to/repo.git
52. Developers fork the official repository
53. Developers clone their forked repositories git clone https://user@bitbucket.org/user/repo.git git remote add upstream https://bitbucket.org/maintainer/repo git remote add upstream https://user@bitbucket.org/maintainer/repo.git
54. Developers work on their features git checkout -b some-feature # Edit some code git commit -a -m "Add first draft of some feature" git pull upstream master
55. Developers publish their features git push origin feature-branch
56. The project maintainer integrates their features git fetch https://bitbucket.org/user/repo feature-branch # Inspect the changes git checkout master git merge FETCH_HEAD git push origin master
57. Developers synchronize with the official repository git pull upstream master
58. The End https://twitter.com/joserobleda/status/707846636345683968
59. References: https://www.atlassian.com/git/tutorials/comparing-workflows http://nvie.com/posts/a-successful-git-branching-model/ Questions? Thank you for your attention!