Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Chris Horner

June 22, 2017

More Decks by Chris Horner

Other Decks in Programming


  1. 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
  2. Cloning $ git clone [email protected]:Gridstone/... repoDir $ cd repoDir $

    git status On branch master Your branch is up-to date with ‘origin/master’.
 nothing to commit, working tree clean
  3. Branching $ git branch ch/change-login-params $ git checkout ch/change-login-params $

    git branch * ch/change-login-params jp/add-login-button master
  4. 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?
  5. 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.
  6. 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.”
  7. 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
  8. 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.
  9. 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
  10. 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
  11. 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
  12. 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.