My Git workflow
Download as PPTX, PDF5 likes2,930 views
The document discusses Git workflows and best practices for managing source code versions. It recommends using small, focused branches for new features or bug fixes, then pushing branches to the remote repository for review and merging. It also recommends forking repositories for outside contributions, where others can submit pull requests to merge changes into the main repository. Following these practices helps keep code organized, allows for easy integration of new changes, and facilitates collaboration.
My Git workflow
- 1. My Git WorkFlow The GitHub Patterns Rui Carvalho @rhwy
- 2. The origin of the problem How code lives @rhwy // Rui Carvalho
- 3. lifecycle New Features New Features Projects and code evolve with time Bug Fix In Production Testing Next Version @rhwy // Rui Carvalho Troubles !
- 4. Solutions ? How people code @rhwy // Rui Carvalho
- 5. Classic VCS Habits • • • • • • Do a project “Long running” branch Continue that ugly coding Pray to be the first to merge Deploy monthly to avoid conflicts Iterate for X years (average 5?) Big bang the project and create a new VCS root @rhwy // Rui Carvalho
- 6. Sounds good ? @rhwy // Rui Carvalho
- 7. Should I care ? Source Code @rhwy // Rui Carvalho
- 8. Code Matters! • Your code and your VCS are your only valid documentation • Your code is living and your VCS is the open book of that History @rhwy // Rui Carvalho
- 9. Keep calm and code Rules @rhwy // Rui Carvalho
- 10. Objectives ? • Always be able to build a production version • Always be able to build a stable version • Easily integrate new features • Avoid long term “out of space” code (aka project branches) • Produce Value on each commit @rhwy // Rui Carvalho
- 11. Simple model git branch @rhwy // Rui Carvalho
- 12. Small branches • • • • • Very small branches Keep central repository clean Work localy then push your branch Someone else review & merge Update your master @rhwy // Rui Carvalho
- 13. Small branches • No learning curve • Near classic VCS patterns – But, better isolation – Easier, due to no-cost branching • Work remotely • No side effects @rhwy // Rui Carvalho
- 14. Distant merge 4 Project A master 1 clone Project A Small_work pull 5 push 3 6 rebase Project A master 2 branch Local Project A Small_work
- 15. //2 step branching $> git branch “create_login_box” $> git checkout create_login_box //1 command branching $> git checkout –b create_login_box Create Branch, then Checkout
- 16. $> $> $> $> $> //add files, do some code git add loginViewModel.cs git commit –m “created view model for login” //more core, finish git commit –m “created html login UI” //then push your branch with that commits $> git push origin create_login_box Code, Add to index, Commit, push branch
- 17. $> //on the remote repo $> git checkout master $> git create_login_box $> //on your box, sync the master from remote $> git pull origin master Someone merge, then you can update your local master
- 18. $> it $> $> //if you need to continue on the repo, sync with the updated master git checkout create_login_box git rebase master $> //if not delete it $> git branch –d create_login_box Then continue your work, Or simply delete your branch
- 19. A better model git fork @rhwy // Rui Carvalho
- 20. Fork what? • • • • • Protect your central repository Restrict rights, accept external work Your branches, your mess Your own builds, easier team work Not git, but quite all online services support it – = clone on server side @rhwy // Rui Carvalho
- 21. Other benefits • • • • Easier remote work YOU, sure to always have a clean master Easier code review across teams It opens a discussion @rhwy // Rui Carvalho
- 22. Distant 1 Fork Team Account ProjectA repository 6 master merge Upstream branch1 pull Request branch1 5 My Account ProjectA repository Origin 8 Push origin master 2 clone 7 pull Upstream master branch1 master My Account ProjectA repository 3 master Local branch branch1 9 Rebase / delete 4 Push Origin branch1
- 23. $> //remotely: $> //fork it/clone it on the server side from company/projectA to myaccount/projectA $> //locally: $> git clone myrepo/projectA $> git checkout –b my_feature 1. Fork, clone & branch
- 24. $> git add myfile $> git commit –m “I added some value” $> git push origin my_feature 2. Work, add, commit, push origin
- 25. $> //remotely: $> //pull request : ask to push your branch my_feature from myaccount/projectA to company/projectA $> //then merge on company/projectA account(probably someone else) $> //locally: $> //update your master with the merged one $> git pull upstream master 3.Pull request, merge, re-sync
- 26. $> //locally $> //to be sure to always have a clean master available everywher, you need to update it $> git push origin master $> $> $> $> $> $> //continue to work git checkout my_feature //sync your branch from updated master git rebase master //if not delete it git branch –d create_login_box Then, update your remote fork, And continue your work, Or simply delete your branch
- 27. Better code, more fun Github workflow style @rhwy // Rui Carvalho
- 28. Practice, practice, practice Want to be a Ninja? @rhwy // Rui Carvalho
Editor's Notes
- #2: This Talk is about common git workflows that most people use and targets people still using standard VCS (cvs, svn, tfs…) in their company.
- #4: Code is living and at every moment, depending on the project size, the team size, the project age and many other factors, you need to have different “versions” of you code available