Git of every day
Upcoming SlideShare
Loading in...5
×
 

Git of every day

on

  • 206 views

Notions of git, important commands and use cases.

Notions of git, important commands and use cases.

Statistics

Views

Total Views
206
Views on SlideShare
178
Embed Views
28

Actions

Likes
1
Downloads
0
Comments
0

1 Embed 28

http://www.tryolabs.com 28

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Git of every day Git of every day Presentation Transcript

  • of every day Notions and more Alan Descoins Tryolabs, 2014
  • Goals ● Better understand what we do every day ● Ask less questions (understand the man) ● Improve some practices ● Make fewer mistakes ● Do something super specific ;)
  • ● 2005, Linux kernel ● Efficiency, simple design ● Non-linear development (thousands of parallel branches) ● Completely distributed Origins and philosophy
  • Distributed ● Nearly all operations are local ● All the machines have ALL the information ● Contrast with SVN, CVS, etc.
  • Some theory ● git init initializes a repository ● Creates only one .git directory in the root (doesn’t pollute) ● Mini filesystem ● Snapshots, not differences!
  • Git and the content ● Tracking of content, NOT files ● Vocabulary: tracked / untracked ● Git objects ○ Blob (content) ○ Tree (structure) ○ Commit (points to a tree, + data) ○ Tag (points to a commit, + data) SHA-1
  • ● One file per “content” ● SHA-1 of the content (zlib) + a header ● Initially, loose object ● Then packfile (efficiency, heuristics…) ● Example: find .git/objects -type f Blob
  • Tree ● Like a directory structure ● Pointers to blobs or other trees ● Represents a complete snapshot of the state ● Example: git ls-tree <sha-1>
  • Commit ● Information about the trees ● Who, when, why saved the tree ● Points to the top level tree of the project ● Tree hierarchy ● Also SHA-1, different hash than the tree it points to
  • Commit (2)
  • Tags ● Pointer to a commit ● Additional information, signature ● So we don’t have to remember the SHA-1...
  • The Holy Trinity A content may be in three states: ● Committed ● Modified ● Staged
  • The Holy Trinity (2) Three parts of a project: ● Working directory ● Staging area (or index) ● .git (repository)
  • Basic commands ● git add - adds to the index (staging) ● git commit - saves the index together with author, message, date, etc. ● git status - shows the file with differences between the working dir, staging, and the untracked ● git diff - what changed but is not staged ● git diff --cached - what is going in the next commit ● git log
  • Avoiding the staging ● Sometimes, it may be easier to avoid the staging area ● git commit -a | git commit <archivo> ● Automatically add to the staging, then commit
  • Branches ● Simply a pointer to a commit ● As fast as it is to write 41 characters to a file (SHA-1 + n) ● By default master ● Special pointer HEAD (current branch) ● Example: cat .git/HEAD
  • Branches (2) ● git checkout to switch branches
  • References ● The HEAD pointer is a special case ● Tags too: “an unmovable branch” (lightweight tags) Example: find .git/refs
  • Remotes ● No central server ● Can add several remotes, external copies of the repo (URL) ● The famous origin :)
  • Remote branches ● Save the state of branches in remote repositories ● They are local, but cannot be moved, only when you do network operations (eg. git fetch). ● The form is <remote>/<branch> Example: cat .git/refs/remotes/origin/master
  • Fetch, push ● git fetch - sync and update remote branches (moves pointers) ● Eg. git fetch <remote> ● git pull - equivalent to git fetch and the git merge, merges the local branch with the changes in the remote ● git push - update the remote branch with the local data ● Eg. git push <remote> <branch>
  • Tracking branches ● Local branches can “track” remote ones ● Two possibilities: ○ git checkout --track <remote>/<branch> ○ git push --set-upstream <remote> <branch> ● Now, when pushing you don’t have to type the name of the remote and the branch :)
  • Merges ● Fast-forward: git is smart and only needs to move a pointer ● Integrate changes of one branch into another
  • Merges (2) ● Three way merge: commit not direct ancestor of what I am merging in (non linear) ● Git determines the best common ancestor ● A merge commit is created, special because it has more than one parent ● Conflicts...
  • Three way merge
  • Rebasing ● Another way to introduce changes of one branch into another ● Rewind & replay, rewrites the commits ● From a common ancestor ● History is always linear, even though it was work originally done in parallel
  • Rebasing (2) ● git rebase <new-base> moves the commits from the current branch to the new base ● git rebase -i <new-base> lets us select actions for every commit ● git pull --rebase
  • ● Never do rebase of a branch that is already pushed, or you pulled from somebody else ○ Duplicate commits if someone does merge ○ Arguable: if the remote branch is yours and used as backup ○ Use git push --force, if you are certain nobody else works in the branch ● If you rebase to get changes by other developers locally, do it as often as possible. Golden rules
  • Rebase vs Merge Why rebase? ● Clean, linear history ● Open-source collaboration, many demand it ● Easier for code review Why merge? ● Easier to solve conflicts (only once) ● Less risk
  • git reset ● Often used ● Used wrong, can cause loss of data (workdir unsafe) ● Three most used options: ○ --soft ○ --mixed ○ --hard
  • git reset... ● move the branch HEAD points to so it points to target commit (stop if --soft) ● then make the staging look like that (stop if --mixed, default option) ● then make the working dir look like that (if --hard, it is workdir usafe!)
  • Examples of git reset ● With HEAD in dev branch, do git reset master ○ now dev y master point to the same commit ● With HEAD in branch master, do git reset --hard origin/master ○ now my local master branch is identical to the remote (discard local changes) ● git reset --soft HEAD~ ○ Undo the last commit without losing changes
  • Unstaging files ● When doing git reset <file> we don’t specify a branch or commit SHA ● Equivalent to git reset --mixed HEAD <file> ● Moves a particular file out of staging, opposite of git add :)
  • git checkout ● git checkout <branch> is superficially similar to git reset --hard <branch> ● Two differences: ○ Workdir safe! :D Checks to avoid data loss. ○ reset moves the branch that HEAD points to, checkout moves the HEAD pointer itself.
  • git checkout of a file ● git checkout <branch> <file> ○ As with reset, now it doesn’t make sense for it to move HEAD. Replaces only <file> in the workdir (workdir usafe!). ○ Would be the same as git reset --hard <branch> <file> ○ But that command does not exist :)
  • Common situations (1) ● “I need to pull but there are changes I am working on, and I don’t want to commit yet” ○ git stash ○ It’s a stack ○ Apply with git stash pop.
  • Common situations (2) ● “There is a bug in a branch, I need to know what commit introduced it” ○ git bisect ○ Binary search, driven by git. Very easy! ○ git bisect start git bisect bad <commit> git bisect good <commit> ● Test on every step (git makes a checkout)
  • Common situations (3) ● “I made one (or several) commits in the wrong branch, haven’t yet pushed though!” ○ If the correct branch does not yet exist ■ git checkout -b <correct branch> ■ git reset over the old branch ○ If the branch already existed ■ git cherry-pick (or git rebase --onto) ■ git reset over the old branch
  • Common situations (4) ● “I have many changes in a file and only want to commit some of them” ○ git add -p or git commit -p ○ git will ask for every part, whether to add it or not
  • Common situations (5) ● “I need to change some commits” ● “I need to delete some commits” ● “I need to change the order of some commits” ○ git rebase -i (--interactive) ○ Easy to use ○ Rewrites history, asking us what to do for each commit
  • Common situations (6) ● “I am doing a merge with many conflicts and I want to stop it and get back to where I was before” ○ git merge --abort
  • (Images from git-scm and others ;) ) Didn’t learn git