Git workflows and keeping your sanity

A quick Git primer for introducing new team members to Git

Transcript

2. Git is a version a version control system - stores your source code - keeps a history of changes (Who, What & When?) - It does a lot more, that we don't care about for this presentation
3. Git is not SVN - SVN offers a subset of Git - SVN + Quilt + (a few more tools) == Git - more stuff => more complexity - It gets even more confusing: * git commit != svn commit * git pull -> does the opposite of what you expect
5. Why is it so complicated - Because Git is geared for workflows, i.e.: 1. Linus Torvalds built a VCS for the Linux Kernel 2. Someone decided they wanted another workflow -> and added another tool 3. Repeat step 2, a few hundred times - Git is not a single tool, it is a set of tools to support multiple workflows - There is no such thing as a default workflow
6. Scary for new users
7. Stop being a wuss - git has 125 commands - I know 26 commands well - I never used them all in the same project - 6/25 are rarelly used - weird operations or low level config - 8/25 deal with local branches and low level management - New users should survive with at most 12
8. How do we address this - Establish the workflow -> set it on stone for others to see - In small (2 person) project this can be debated - In larger projects there is usually a mantainer to decide - If you are the mantainer and are not doing this -> you suck If the tool does not enforce the workflow, then you must!
9. Workflows - Define tools and procedures - Rules of engagement - Choose wisely ...
10. Workflow recipe #74 - the "lazy" flow - Take it for what it is. - Made for small teams with a lazy team leader - Two main roles: the mantainer, and the others - Two main goals 1. The others do most of the work, the mantainer sleeps 2. Keep the history clean. Avoid circular commit history. - Rules of engagement * The mantainer is the only guy that can run a merge * Others rebase code on conflicts to avoid weird history graphs
11. The Others - git clone - <... do some work ... > - git status + git add + git commit - git fetch - git rebase [if needed] - git push 1. commits are local 2. fetch avoids stupid automatic merge errors 3. rebase forces you to think and keeps the history clean 4. git pull/merge is forbidden
12. The Mantainer - git clone - <...stage a branch.. > - git branch fix master - git push - <...when work is done...> - git fetch - git checkout master - git merge fix - git push - <... pick recent bug fixes...> git checkout stable git cherry-pick ... 1. Typicall lazy mantainer, manages work assigment, does not code 2. Merge different work branches 3. Picks bug fixes into other branches
13. Why git? Developers - Local patch management - commits are local - Local branches - organize you local work - stop poluting the central repository Mantainers - Disk space efficiency - Weird workflows - use email or carrier pidgeon instead of git push - Some insane tools for merge and migration - Security - commit hashes and signatures
14. Git is not a hammer
15. Just because it does a lot of crap doesn't mean you should use it for all your crap.
16. Bonus Slide - Stay away from crappy IDE integration (Eclipse :S) - Disable IDE automatic code re-formatting - makes history unreadable - There are good GUIs (I'm not talking of gitk) - Practice good karma - Git gives you tools for you: - Create small commits - Split you work into branches - reorder/rearrange them when you are done - Write decent commit messages
17. Thanks for your patience.
18. References - http://yanpritzker.com/git-book/ - http://git-scm.com/book/ - http://randyfay.com/node/91 - http://randyfay.com/node/89