No content

Crazy Linus Torvalds magic 

What makes git different from something like svn? 

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 

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

Where does Github fit into this? 

So how do I start? 

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 

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

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

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? 

What changes were made? 

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

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. 

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.” 

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 

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

Creating a PR manually 

Why submit pull requests? 

How do reviews work? 

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. 

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 

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

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 

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 

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

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

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. 

Let’s see an example!