Save 37% off PRO during our Black Friday Sale! »

Git Gud

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

7b1e567c19126de48554fe8e5e767395?s=128

Chris Horner

June 22, 2017
Tweet

Transcript

  1. None
  2. Crazy Linus Torvalds magic

  3. What makes git different from something like svn?

  4. fun main(args: Array<String>) { println(“git gud”) } You write some

    code then you execute git commit but to actually get the code off your computer git push
  5. git stores things differently ch/feature1 ch/feature2 SomeFile.kt .git another_file.png another_file.png

    .git CompleteDifferent.kt WhereDidThisComeFrom.txt
  6. Where does Github fit into this?

  7. So how do I start?

  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
  9. Now what? master jp/add-login-button ch/change-login-params

  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
  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?
  12. What changes were made?

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

    and future debugging
  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.
  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.”
  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
  17. Pull request Github is usually smart enough to know what

    you want.
  18. Creating a PR manually

  19. Why submit pull requests?

  20. How do reviews work?

  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.
  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
  23. Size really matters Which of these would you rather deal

    with?
  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
  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
  26. But then there are these… master jp/add-login-button ch/change-login-params

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

    R word.
  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.
  29. Let’s see an example!