Git Gud

A basic introduction to Git and how to use it effectively as a team of developers. Topics covered include:
- Cloning
- Branching
- Merging
- Pull requests
- Rebasing
- Reviewing
- Keeping history clean
- Making messages meaningful

Transcript

1. View Slide

2. Crazy Linus Torvalds magic
   

   View Slide

3. What makes git different from
   something like svn?
   

   View Slide

4. fun main(args: Array) {
   println(“git gud”)
   }
   You write some code
   then you execute
   git commit
   but to actually get the code off your computer
   git push
   

   View Slide

5. git stores things differently
   ch/feature1 ch/feature2
   SomeFile.kt
   .git
   another_file.png
   another_file.png
   .git
   CompleteDifferent.kt
   WhereDidThisComeFrom.txt
   

   View Slide

6. Where does Github fit into this?
   

   View Slide

7. So how do I start?
   

   View Slide

8. Cloning
   $ git clone git@github.com:Gridstone/... repoDir
   $ cd repoDir
   $ git status
   On branch master
   Your branch is up-to date with ‘origin/master’.

   nothing to commit, working tree clean
   

   View Slide

9. Now what?
   master
   jp/add-login-button
   ch/change-login-params
   

   View Slide

10. Branching
    $ git branch ch/change-login-params
    $ git checkout ch/change-login-params
    $ git branch
    * ch/change-login-params
    jp/add-login-button
    master
    

    View Slide

11. So now I write code?
    • Yes. But be mindful of what you write
    
    • When you’re done writing code, you’re going to make a
    commit
    
    • What will it contain? What message will describe it?
    

    View Slide

12. What changes were made?
    

    View Slide

13. History matters
    Good commit messages speed up reviews, release notes, and
    future debugging
    

    View Slide

14. Each commit represents an action
    $ git log --oneline
    57d969e Remove password from login screen.
    6ccf065 Configure email validation in login screen.
    27e5021 Add email to login screen.
    8c6bf5c Merge pull request #37 from sm/settings-screen
    You should be able to replay a set of commits on a
    codebase and watch the changes take effect.
    

    View Slide

15. Committing
    $ git status
    Changes not staged for commit
    modified: LoginScreen.kt
    $ git add LoginScreen.kt
    $ git status
    Changes to be committed:
    modified: LoginScreen.kt
    $ git commit -m “Change login params to have phone number.”
    

    View Slide

16. So now I merge into master, right?
    $ git checkout master
    $ git merge ch/change-login-params
    Updating bcbdb68..da85c24
    Fast-forward
    LoginScreen.kt | 2 ++
    1 file changed, 2 insertions(+)
    $ git push
    

    View Slide

17. Pull request
    Github is usually smart enough to know what you want.
    

    View Slide

18. Creating a PR manually
    

    View Slide

19. Why submit pull requests?
    

    View Slide

20. How do reviews work?
    

    View Slide

21. Reviews are worth taking seriously
    • Everyone needs to be 100% proud of the codebase.
    You’re a team
    
    • People make mistakes all the time. Fresh eyes are
    useful.
    
    • It’s good for many people to be across a feature’s
    implementation.
    

    View Slide

22. What’s worked for Team Android
    • No one is allowed to merge their own PR
    
    • A PR must have at least two approvals before it can be
    merged
    
    • Everyone must try hard not to make a PR with over
    500 modified lines
    
    • Consider opening the branch in your IDE locally
    

    View Slide

23. Size really matters
    Which of these would you rather deal with?
    

    View Slide

24. Always try for constructive feedback
    • You’re going to fail PRs because you see something’s
    not right, or you know there’s a better way
    
    • Take advantage of Github’s Markdown. Embed the
    code you think is a good replacement
    

    View Slide

25. Think about the commits in the PR
    • Both PR submitter and merger need to consider what
    commits are about to be merged into master
    • The submitter needs to proactively push amend
    commits
    
    • The merger needs to consider squash-merging
    

    View Slide

26. But then there are these…
    master
    jp/add-login-button
    ch/change-login-params
    

    View Slide

27. How can we get up-to-date?
    master
    jp/add-login-button
    ch/change-login-params
    The scary R word.
    

    View Slide

28. Rebasing
    $ git rebase master --interactive
    WHAT THE HELL. WHY IS VIM NOW POPPING UP!?
    WHY DO MY FILES HAVE <<<<<<< EVERYWHERE IN THEM!?
    $ git rebase --abort
    My first rebase.
    

    View Slide

29. Let’s see an example!
    

    View Slide