Git crash course E2015

Transcript

1. GTI-350 git crash course Hiver 2015 License MIT http://nitriques.mit-license.org/ © Nicolas Brassard 2015
2. Pre-requisites 1. Really basic knowledge of the command line (cd, mkdir, rm/del) 1.1. bash/csh/zsh/*sh for *nix 1.2. cmd/power shell/cygwin/mygwin for Windows 2. git installed and available in the PATH 3. git properly configured (more on that later) 4. version 1.9 or later… (Use 2.x on *nix)
3. git - The stupid content tracker 1. WTF git? 2. Vocabulary 3. Commands 3.1. Creating a repository 3.2. Commiting 3.3. Status + Log 3.4. Branching + Merging + Tagging 3.5. Remotes + Cloning 4. Github 5. Varia (Config, Aliases, Tools, etc.)
4. WTF git? "git" can mean anything, depending on your mood. - random three-letter combination that is pronounceable, and not actually used by any common UNIX command. The fact that it is a mispronounciation of "get" may or may not be relevant.
5. WTF git? - Stupid. contemptible and despicable. simple. Take your pick from the dictionary of slang. - "global information tracker": you're in a good mood, and it actually works for you. Angels sing, and a light suddenly fills the room. - "goddamn idiotic truckload of sh*t": when it breaks Initial revision of "git", the information manager from hell https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23ca2e25604af290
6. WTF git? By and for Linus Torvalds in 2005 (10 years!) Kernel maintenance Inspired by BitKeeper (proprietary) Almost 40,000 commits (version 2.4) Mostly in C/Shell http://git-scm.com/
7. git: Distributed SCM Almost every SCM systems are designed around a client-software architecture. (SVN, CVS, Visual Source Safe, TFS) git does not require a server: git does not ship with a server executable!
8. git: Distributed SCM Centralized SCM uses commit ID as ordering: This creates a linear history. All new commits goes after the last one (if not, reject it).
9. git: Distributed SCM
10. git: Distributed SCM Linus needed offline support. 1. Must be able to commit. 2. Must be able to show all history. He wanted his own copy to be the official copy. Must be provable that it is not corrupted.
11. git: Distributed SCM How ? Everything is local. Do not use incremental IDs: use hash instead. (Easy to generate uniqueness across machines) Creates an history tree not a vector.
12. git: Distributed SCM You can even build a forest! Each branch is a separate view (instances) of a tree.
13. Vocabulary (as defined by me) Git is so special, it comes with it’s own jargon. git folder: .git directory at the root of the project. Holds everything git needs to keep track of (file oriented database). git command: git offers commands. it’s the first arguement in the CLI. (git help) Object: a record (file) in the database. Referenced by its hash (SHA-1) Blob: an object that contains data (text or binary). Tree: an object that represents a structure of blob(s) (name of the files). Commit: an object that links a new tree to a parent commit and a message.
14. Vocabulary Index: “staging” area: things that are “staged” for commit. HEAD: Pointer to the current (often the last) commit the index points to. Branch: Pointer to the current tree on which the index operates. Master branch: The “default” or “main” branch, typically called master Feature branch: One of the best practice is to isolate changes into seperate branches, called feature branches. “Feature” can also mean bug fix here. Tag: Name/synonym for a commit (commit-ish or ref, see git rev-parse). Anotated tag: shareable, persistant and signable tag.
15. CLI: The best human-machine interface “For a lot of things, the CLI is still the best way for an expert user to interact with a computer.” - Me, now.
16. Creating a repository mkdir project && cd project git init That’s it. 95%* of git will work. Why? Because everything really is local. * Based on no calculation at all. Pure guess.
17. Commiting The first thing to do is to add files to the index git add . # entire folder, recursive git add *.txt # all .txt files Then you can git commit
18. Commiting Instead of returning to the prompt, an editor (vi/vim, emac, nano, notepad…) should show up… git needs a commit message. First line: Commit title (80 chars max for Linus) Second line: Empty. Third+: Commit message on multiple lines
19. Commiting One liners git commit *.txt # adds *.txt and commits git commit *.txt -m “!” # message included git commit -a # adds all “dirty” files Dirty files as files already known by git
20. Commiting Removing a change from the index ? git reset path/to/file Google for --soft and --hard options.
21. Commiting But what about removing new file from the index ? git rm --cached path/to/file BEWARE, the --cached prevents the files from being deleted! --cached only affects the index
22. Status + Log In order to check the index state, issue: git status # or git diff See the log of the current branch git log
23. Branching git init created a branch called master... Creating a branch: git branch <branch-name> Switching to a branch: git checkout <branch-name>
24. Branching git checkout is a tricky command: It can both act on branches and on files git checkout file.txt # reset the working copy # to the last commited version
25. Branching One liner git checkout -b <branch-name> # creates a # new branch and checks it out
26. Merging Merge on-top or before ? Standard merge (recursive strategry: Find the closest common parent) git checkout <base-branch> git merge <feature-branch> # merges # feature-branch on top of base-branch
27. Merging What happens if we git log now? Git may have made a merge commit! Why? git needs to create a new commit that will have two parents in order to unify things...
28. Merging Fast-foward merge: all changes are children of a know commit. No merge commit! But it’s ok to have merge commits.
29. Merging Doing the opposite: getting changes from master into feature branch, i.e. apply our commits after what’s new in master git checkout <feature-branch> git rebase <base-branch> # “inserts” all things # in base-branch before feature
30. Merging Interactive rebase git rebase -i <base-branch> Allow review and edit before the process. Easy commit by commit rebasing.
31. Merging Rebase == Rewriting history BEWARE! Commits are not lost, they are duplicated… That’s where blobs come in handy… (avoid duplication!)
32. Merging Rebase == Rewriting history BEWARE #2! Never rebase master or any integration branches! This will make sharing things a lot harder!
33. Merging Dealing with conflicts: 1. Manual edit, then git add|rm && git commit 2. Abort try other strategy (see git help merge) 3. Abort and try interactive rebase (git rebase -i <commit-ish>) Finding regression: git bisect
34. Tagging git tag <my-tag> # creates a local tag # not very usefull… git tag -a <my-tag> # annotated tag! One liner: git tag -a <my-tag> -m “msg”
35. Branching + Merging + Tagging git checkout master git checkout -b my-feature … git commit -a [-m “”] # x times git checkout master git merge my-feature git tag -a 1.0.1a -m ‘My feature’
36. Remotes + Cloning In order to share code you need to add at least one remote to your your git repo. Remotes are “remotes working copies” They can be anywhere: on your friend’s laptop or on github/gilab/bitbucket/your own server
37. Remotes By convention, the first remote is called ‘origin’ You can add as many remotes as you want! You can access read-only and read-writes remotes
38. Remotes Let’s add a origin remote for our repo git remote add origin git@github.com: nitriques/repo.git # ssh git remote add origin https://github. com/nitriques/repo.git # https Also http:// file:// smb://
39. Remotes Fetch all the history git fetch <remote-name> git fetch <remote-name> <remote-branch> git fetch --all This does not modify the working copy!
40. Remotes We need to merge with the remote. git merge <remote-name>/<branch-name> Let’s say we are in the master branch and want to update it to our local copy of the remote’s version: git merge origin/master
41. Remotes But there is a shortcut! git pull <remote-name> <branch-name> Space vs slash: The team that coded fetch won when they had to collaborate with the team responsible for merge...
42. Remotes If you are lucky enough, you have write (push) acces to the repro, you can push to any branch (as long as it does not already exist) git push origin master # pushes the current # branch into origin/master
43. Remotes If you rebased, you will need to do a forced update or else git with yell at you. git push <remote-name> <branch-name> --force Never do this on the master branch: git pull won’t work. (way out: git checkout <lastest-common-commit-ish>)
44. Remotes + Branching + Merging + Tagging git checkout master git pull origin master # makes sure local master is sync git checkout -b my-feature # creates new feature branch … git commit -a [-m “”] # x times git push origin my-feature # on another computer, we do the “release” (or integration) git checkout master git pull origin my-feature git push origin master git tag -a 1.0.1a -m ‘My feature’ # optional, but recommanded git push --tags # this is how you push anotated tags
45. Cloning git clone <repo-url> git clone git@github.com:nitriques/<repo-name>.git But cloning mostly is… mkdir <repo-name> cd <repo-name> git init git remote add origin <repo-url> git fetch origin git merge origin/master cd ..
46. Same as we saw in branch + merge! + 1. Forks: Let’s you create a remote copy of a read-only git project on which you will have read+write access. 2. Pull Requests (PR): Ask the owner of the project to git pull changes in your feature branch from your remote without any setup! https://guides.github.com/introduction/flow/ Github workflow
47. - PR are way better then sending patch files via email. (see git format-patch and git apply) - PR also works across your own branches! You can also add more commits to a PR by pushing more! - They are a great way to review code. Elect a leader for merges in master. - Integrated as a github issue == awesome emojis - git pull origin pull/<id>/head Github workflow - Pull Requests
48. Config Initial (post-install) configuration git config --global user.name "YOUR NAME" git config --global user.email "YOUR EMAIL ADDRESS" + Auth https://help.github.com/articles/set-up-git
49. Aliases git aliases are a great way to deal with git’s crazy CLI arguments… git lol... git config --global --add alias.lol "log --graph --decorate -- pretty=oneline --abbrev-commit" https://gist.github.com/nitriques/17117c251c30b72a8aff
50. Tools gitk: git’s native UI, bundle with it. ghwd: https://github.com/zeke/ghwd tortoisegit: https://code.google. com/p/tortoisegit/ dotfiles: the CLI is your friend, don’t let it suck http://dotfiles.github.io/ Google/StackOverflow: “git how to…”
51. Tools: github for windows/os x/linux How does gihub’s UI works... ? But it comes with the CLI!
52. Fun fact The only “official” linux kernel repo resides on Linus personal computer. He pulls from 5 other guys he trusts. They trust other people who trusts other people. But Linus can always be sure that his copy is intact since everything is hashed.
53. Questions? Slide are on https://speakerdeck.com/nitriques I am available on twitter and github @nitriques and sometimes on irc (freenode)... Add me as a read-only member of your private repos!
55. References Official website: http://git-scm.com/ Nice how-to: http://rogerdudler.github.io/git- guide/ Good/quick ref: http://gitref.org/ Wiki: http://en.wikipedia.org/wiki/Git_(software) Github: https://github.com/git/git