git time!

just a whirlwind runthrough of git basics and a few ways to get yourself out of trouble if you need them.

Transcript

1. ok, git time. 1. some basics 2. some neat tricks (feel free to ask me questions on twitter, i’m sure i forgot stuff - i’m @crebma)
2. the basics
3. how git works git works using changesets, as opposed to saving a snapshot of your fi le system as subversion would. this makes the repository smaller, as well as makes branching and merging a much easier thing to deal with. git is a distributed version control system. that means that almost everything you do is local, until you push your changes out to a remote shared respository. what else? i don’t know, ask me!
4. setting up git https://git-scm.com/book/en/v1/Getting-Started- Installing-Git
5. git init this is how you start! take a folder, cd to it in your terminal, type ‘git init’, and hit enter! now, git knows about your folder, but it doesn’t know what to pay attention to yet. that’s the next step.
6. git status git status is essential. you should type “git status” more than any other git command ever. de fi nitely before any add or commit. staged working directory untracked
7. git add you’ll do this right after git init, but also every time you want to make a commit. this is the thing that tells git a) what to pay attention to or b) what changes to include, if it’s already paying attention. there are three stages to git. •in the working directory (tracked/untracked) •staged •all up in the repo
8. git add you have changes! you haven’t added them yet. if they are untracked fi les, the whole fi le is a change. if they are tracked fi les, git knows what the change is. in the working directory you have added your changes so that you can commit them. staged you have committed these changes... so they’re not changes anymore. all up in the repo
9. git add now, back to the adding part. there are a few different options here. actually, there are a lot, but lets just cover the common ones. add by path git add Source/Whatever/ fi le.thinger this adds the changes in this fi le, to the staging area. remember, if it was previously untracked, the changes will be the entire fi le.
10. git add add all the things! git add . you’re saying add everything that isn’t ignored. you probably don’t want to do this, but hey it’s a thing you can do.
11. git add wait, i said, “isn’t ignored”, what does that mean?! .gitignore this is where you put stuff that you don’t want in version control. for example, .DS_Store, or a top secret fi le of top secrets keys and secrets! you never need or want that in version control.
12. git add add just bits and pieces of changes git add -p this lets you add your changes in patch mode, which will essentially break up the changes in each fi le into smaller chunks for separate commits. this is particularly useful if you just implemented like 8 things without committing at all, and want to be a good person and make 8 separate small related commits instead of one big scary one.
13. git diff sometimes you want to see what your changes are before you commit them. you can see these changes in either your working directory or your staged area. you can also see the changes in just one fi le, and any of these options without whitespace.
14. git diff look at the diff for a path git diff Source/blah/stuff.txt shows you all the changes in that fi le. look at the diff for everything in the working directory (unstaged) git diff
15. git diff look at the diff for staged fi les git diff --staged any of these diffs, but ignoring whitespace/ formatting git diff -w Source/blah/stuff.txt git diff -w git diff -w --staged
16. git commit this is how you get the staged changes into your local repository. again, there are lots of options, but let’s go with the most common ones. commit with no options git commit commits your staged changes and opens whatever text editor is default on your machine for you to enter a commit message.
17. git commit commit with message inline git commit -m ‘this is the commit msg!’ commits your staged changes and uses the given message for your commit. commit all tracked changes with message inline git commit -am ‘this is the commit msg!’ the only way this differs from the previous is that it also adds all tracked changes in your working directory. remember, the danger zone!
18. git commit commit in patch mode git commit -p commits all staged changes, as well as allows you to add changes from your working directory in patch mode, similar to add -p. still opens an editor to add your commit message.
19. git rm i don’t use this often, but this will remove the fi le as well as remove it from git.... that’s about it. you can also use git rm —cached to remove things from the git index without _actually_ deleting them.
20. git checkout checkout a commit. if you tell it to checkout a branch, it checks out the latest commit on that branch. you can also use this as a cheat to make a new branch checkout a branch git checkout branch-face-mcgee checks out the latest commit on that branch. if you have any local changes, they will be carried over with you as local changes. if you have local changes that don’t merge nice, git will tell you to fi gure it out before you can switch branches.
21. git checkout checkout a commit git checkout 04dd74 checks out that commit in ‘detached head state’. i know, sounds spooky, but that just means you can’t commit, because you’re not on a branch and git would not know what history to put that in. luckily, you can
22. checkout a new branch based on wherever you are git checkout -b some-pants now you have a new branch called some-pants that is based on whatever branch you were in. you can do this from a branch, or detached head state, whatevs. git checkout
23. git restore checkout changes in your working directory to remove them git restore path/to/the/thing.rb checkout changes that are already staged to remove them from staging but keep them in your working directory git restore —staged path/to/the/thing.rb
24. git branch delete a branch git branch -D branch-to-delete make a new branch based on the current one git branch the-new-branch keep in mind, you’ll still have to checkout this branch, since we didn’t do the super awesome mega checkout -b combo.
25. git remote how you work with remote repositories in git, like the repos on github or heroku. add a remote repo to track git remote add origin git@github.com:crebma/git- demo.git remove a remote git remote remove origin use a remote git pull origin main git push origin main git reset --hard origin/main
26. git reset for when you made a mess. unstage your changes git reset remove staged AND working directory changes git reset --hard remove all of the above and reset your history to a known good place, like upstream main git reset --hard origin/main
27. git clean when you want to just clean up all the untracked fi les hanging around, like those pesky .orig or diff fi les from merge con fl icts. remove untracked fi les git clean -f remove directories git clean -df you need all those f’s because they mean “force”, and as a safety feature, git by default requires force on a clean. you can change that setting if you’re feeling wild.
28. git fetch this fetches history from a speci fi ed remote, like upstream. fetch history for a remote git fetch remote-name fetch all the history for all remotes and branches git fetch --all
29. git merge merges given local or remote branch into your current branch. merge a local branch git merge main merge a remote branch git merge upstream main if you run into merge con fl icts, you can resolve them however you like. personally, i set up p4merge with git so that i can just use ‘git mergetool’. escaping when everything goes wrong git merge --abort
30. git pull pull is an awesome thing. it combines a fetch and a merge to pull the latest change into your current branch. it’s smart to name the remote and upstream as opposed to just doing a blind pull, though there are settings you can set to have a default. i prefer to be explicit. pull a remote branch git pull origin main this will have the same deal as merge; you may run into con fl icts and resolve them.
31. git push push takes the commits you have in your local repository and pushes them to a remote and branch you specify. again, it is smart to always name the remote and branch, though you can do the same settings thing as with pull. you can also push to remote HEAD which will push to the same branch on a given remote as your current branch. push explicitly git push origin main push using head git push origin HEAD
32. git push you can also set the upstream branch when you do a push, so that you wouldn’t have to name them again in the future. push with a set upstream git push -u origin main subsequent pushes will go to origin/main git push
33. git tag this is how you tag a commit as the latest one released in some environment. once you create a tag, you push it or fetch it just like a branch. list all tags git tag -l push a tag git push v1.5.7 make a tag git tag -a v1.5.7 checkout a tag git checkout v.1.5.7
34. git rebase destroyer of histories. well, not really... more like rearranger of histories. it takes all of your divergent commits in a branch and stashes them, applies all divergent commits from the branch you’re rebasing to and puts those on the history stack, and then applies all of your divergent commits one by one. there is a lot of room for trouble here, like merge con fl icts or messing up everybody else. the basic rule is, if you have ever pushed this history to a remote repository, don’t rebase it. if git ever tells you you need to do a force push and you are using a shared repo, don’t do it. undo what you did, and just do a merge.
35. git rebase rebasing to a local branch git rebase main rebasing to a remote branch git rebase origin main escaping when everything goes wrong git rebase --abort
36. whoops, committed to main as long as you haven’t pushed, you’re fi ne! just checkout a new branch from your current main, go back to main, and reset —hard to origin/main, then head back to your branch to continue: git checkout -b feature git checkout main git reset —hard origin/main git checkout feature
37. git cherry-pick for when you only want one commit applied to your branch. say you have this feature branch and you fi x a bug in a commit on it. suddenly you realize the bug exists in main! just take a look at your log to fi nd the SHA of the commit, say its abc123, checkout main, and then cherry-pick that commit onto main! git log git checkout main git cherry-pick abc123
38. git bisect for when you have a bug, and you have no idea when it was introduced. git bisect does a binary search through your commits, allowing you to pinpoint the commit in which the bug was introduced without too much hassle. this is a super good time to be reminded about only making working commits.
39. moar resources git immersion: http://gitimmersion.com/ git book by scott chacon: http://git-scm.com/book/