Advanced Git¶
Or: more than you wanted to know, but just touching the surface
Overview¶
- quick recap
- GitHub Forks
Issues and Pull Requests
Ignoring Files with
.gitignore- Hosting your own repositories with
bare repositories - Branches (with
git checkout) - Undoing your mistakes with
git resetandgit revert - Rewriting history with
git rebase - Rewriting history, like, totally. with
git rebase -i - The last resort:
git reflog - My GitHub workflow
Quick Recap¶
Configuration¶
git config --list
Initialization¶
mkdir myrepo
cd myrepo
git init
ls -a
git status
Adding and committing¶
echo "first line in file myfile" > myfile.txt
git status
git add myfile.txt
git status
git commit -m "added a first line to my file"
git status
git log
Changing and committing again¶
echo "second line in myfile is not much more interesting" >> myfile.txt
git status
git add myfile.txt
git status
git commit -m "I added a second line"
git log
Reverting a file to an older version¶
echo "omg a third line" >> myfile.txt
cat myfile.txt
Reverting to the last commit:
git checkout myfile.txt
cat myfile.txt
Reverting to a previous commit:
git checkout HEAD~1 myfile.txt
cat myfile.txt
git status
git commit -m "checked out myfile from first commit"
git log
Comparing files between versions¶
Compare all files to the previous commit (HEAD "minus" one).
git diff HEAD~1
Compare only myfile.txt to the previous commit.
git diff HEAD~1 myfile.txt
GitHub¶
GitHub is a way to host and share repos, but also a social network. GitHub makes it easy to contribute to existing repositories.
GitHub Recap¶
To work on a project with a project partner you:
- create a repo
- push your code to the repo
- have them
pullfrom your repo - add them as a "collaborator" on GitHub
- now they can
pushtheir changes
Problems with the pull / push model:¶
- Lack of transparency (you need to study the log)
- Need to give out write permission to collaborators
Alternative model: Forks and Pull requests¶
To work on someone else's project you:
- Fork (make your own copy) of the project
- Change your project
- Ask then to
pullyour changes into the main project - the pull request
Exercise¶
- Fork my repository at http://github.com/amueller/repo_to_fork
- Clone your forked version of the project (so you have a copy on your hard disk)
- Create a new file, add and commit it.
- Push the file to your forked repository.
- Create a Pull Request to my original repository.
AKA "the simplified workflow"
Back to the command line!¶
Ignoring things¶
touch stupidtempfile.swp
touch whycompiling.pyc
git status
Each line in .gitignore specifies one (kind of) file to ignore:
echo "*.swp" >> .gitignore
echo "*.pyc" >> .gitignore
ls -a
Ignored files will not show up in git status and will not be added when doing git add --all
git status
Exercise¶
- Create a new repo
- Add file
awesome_content.txtyou want to commit. - Add a file
local_notes.txtthat you don't want to track. - do a
git status - add
local_notes.txtto.gitignore - do a
git status local_notes.txtshould not show up in the status.- Add and commit
awesome_content.txt. - Try adding
local_notes.txt. - Should you add
.gitignore?
Making Remotes¶
pwd
cd ..
mkdir cloned_repo
cd cloned_repo
I can clone a local directory!
git clone ../myrepo
tree ..
cd myrepo
ls
git remote -v
git log
Change something in the original repo:
cd ../../myrepo
cat myfile.txt
echo "another line committed to the original repo" >> myfile.txt
git add myfile.txt
git commit -m "new commit in the original repo"
git log
Update the cloned repo ...
cd ../cloned_repo/myrepo
git pull origin
git log
Change something in the cloned repo:
echo "new line in cloned repo" >> myfile.txt
git add myfile.txt
git commit -m "new line in cloned repo"
But I can't push to the original repo. (Someone might have edited the files but not checked them in)
git push origin
true
bare repositories¶
Allow pushing to them, but not directly editing them. They are used only as remotes.
cd ../..
ls
mkdir bare_repo
cd bare_repo
git init --bare
Bare repos don't look like the content of the repository:
ls
Adding the bare repository as a remote to the existing repository myrepo:
cd ../myrepo
git remote add new_bare ../bare_repo
git remote -v
Pushing master of myrepo to the bare_repo:
git push new_bare master
Add bare_repo as a remote in the cloned repo:
cd ../cloned_repo/myrepo
git remote add new_bare ../../bare_repo
Push the new changes we made in the clone to the bare repo:
git push new_bare master
Pull the changes from the clone to the original repo via the bare repo:
cd ../../myrepo
git pull new_bare master
git log
Bare repos are like your own personal GitHub! (kinda)¶
Exercise¶
- Create a new bare repo and push to it form your original repository.
clonethe bare repo.- change the clone and push to the bare repo.
- Go to your original repository and pull from the bare repo.
Undoing your mistakes sneak preview¶
Remove all files:
rm *
ls
Get them back!
From the last commit:
git reset --hard
From any commit or remote:
git reset --hard new_bare/master
The last line rescues you after screwing up your local copy.
Exercise¶
- make sure your changes are pushed to the remote (bare) repository
- delete all your files
- commit deleting all files (
git rm, notgit addto stage that) - check the log
git reset --hardto your remote repository.- marvel at how everything turned out alright.
Branches¶
Allow parallel lines of development.
Create new branches with git checkout -b
git checkout -b new_branch_with_descriptive_name
echo "new stuff that is reeeeaaally cool and maybe even works" > myfile.txt
git add myfile.txt
git commit -m "hurray, new stuff."
git log
Where is the branch?¶
git log --graph --decorate --all --oneline
master is at "new line in cloned repo", new_branch_with_descriptive_name is at "hurray, new stuff"
HEAD points to new_branch_with_descriptive_name.
alias nicelog="git log --graph --decorate --all --oneline"
Move to another branch with git checkout
git checkout master
git log --graph --decorate --all --oneline
HEAD points at master.
The content of myfile.txt is the one at "new line in cloned repo", not "hurray, new stuff":
cat myfile.txt
We add another commit to master:
echo "add to the old stuff " >> another_file.txt
git add another_file.txt
git commit -m "working on another file on the master"
An now we see why it's called branch!
git log --graph --decorate --all --oneline
ls
Check out the "new_branch" again:
git checkout new_branch_with_descriptive_name
another_file.txt has disappeared:
ls
Exercise¶
- Create add and commit an empty file "homer_is_in.txt" in master.
- Create a branch called "australia".
- Change the content of
homer_is_in.txtto "australia" and commit it. - Go back to the master branch, and then create a branch called "america"
- Change the content of the file to "america" and commit it.
- Check out the branch "australia" and check the content of the file.
- Look at the log.
Merging Branches¶
Or reuniting the lines of development.
git checkout master
Merge branches with git merge. Provide a message with -m.
git merge new_branch_with_descriptive_name -m "merge descriptive branch with cool feature"
git merge --abort is your friend if there are many conflicts and you start to panic.
After a successful merge, all is clean:
git status
Changes from both branches are there:
cat myfile.txt
The merge created a new commit:
git log --graph --decorate --all --oneline
Exercise.¶
- Check out master. Change the content of
homer_is_in.txtto "doughnut plant" and commit it. - Look at the log.
- Merge
americaintomasterand resolve the conflict so that the file contains "america". - In the master branch, the content of the file should now be "america".
Creating branches starting at commits¶
git checkout -b branch_started_further_back HEAD~3
git log --graph --decorate --all --oneline
Deleting branches¶
git checkout -b another_new_branch
git log --graph --decorate --all --oneline
We can't delete the branch we're on so we go back to master:
git checkout master
git branch -d another_new_branch
Exercise¶
- Delete the branch
america - Delete the branch
australia
Concept Review¶
DAG (directed acyclic graph) of commits = branches¶
Index vs staging area vs working tree¶
HEAD¶
Remotes¶
So far we have:
- Added commits to the DAG (
git commit), branched (git checkout -b) and merged branches (git merge). - Moved the HEAD from branch to branch (
git checkout) - Moved HEAD to a commit and started a branch there (
git checkout -b <branchname> <commit>) - Pushed and pulled from Remotes (that kind of work like branches)
Most commands impact the DAG, and some of the Index, staging area and working tree.
- The index stores commits.
- The staging area stores a diff (lines added and removed).
- The working tree stores files.
Undoing your mistakes¶
git revert and git reset
git checkout master
git log --graph --decorate --all --oneline
ls
git revert HEAD~1 --no-edit
git log --graph --decorate --all --oneline
ls
Exercise¶
- Revert the commit that merged
americaintomaster.
git reset¶
- hard: working dir & move HEAD
- mixed (default): only move HEAD
Moving head when on a branch (not headless) also moves where the branch is pointing!
git reset branch_started_further_back
git log --graph --decorate --all --oneline
git status
cat myfile.txt
git add myfile.txt
git commit -m "new stuff from the feature branch that I did stuff with"
git log --graph --decorate --all --oneline
--hard fixes (aka destroys) everything!
git checkout -b branch_well_move_back
git log --graph --decorate --all --oneline
git reset --hard HEAD~3
git status
git log --graph --decorate --all --oneline
Exercise¶
- Create a new branch
way_back_machine. - Reset it to the first commit in your repository
- Add a new commit
- look at the graph.
rebase only works on the DAG (and moves HEAD)
rebase basically does every possible thing with the DAG
changing the tree means changing hashes!
"simple" form:
git rebase basebranch otherbranchequivalently
git checkout otherbranch
git rebase basebranchPut everything in otherbranch that is not in basebranch on top of otherbranch. (compute common root, cut of there)
git log --graph --decorate --all --oneline
git checkout branch_started_further_back
echo "Change in back branch" > new_file_in_back_branch.txt
git add new_file_in_back_branch.txt
git commit -m "added a file in the branch_started_further_back"
echo "more lines" >> new_file_in_back_branch.txt
git add new_file_in_back_branch.txt
git commit -m "second commit in the branch_started_further_back"
git log --graph --decorate --all --oneline
git rebase master
git log --graph --decorate --all --oneline
"advanced form"¶
using --onto
Three parts in rebase:
- The branch to move (current HEAD or second in command)
- The branch to compute the common parent with
- The branch to put the stuff on top of
For the "simple" version 2 and 3 are the same.
For the --onto version, you can specify 3 separately.
git log --graph --decorate --all --oneline
git rebase master --onto new_branch_with_descriptive_name
git log --graph --decorate --all --oneline
Exercise¶
- Add a second commit to your branch
way_back_machine(from the last exercise) adding a new file. - Rebase only this second commit on top of master.
- Feel like a git guru.
- What do you expect the graph to look like?
- Look at the graph.
Interactive rebase¶
(or you could apply a rusty nail to your retina)
We'll only discuss squashing and skipping. Needs to be done on the command line!
# git rebase -i new_branch_with_descriptive_name
false
git log --graph --decorate --all --oneline
Exercise¶
- Add two new commits to master
- Squash them
Git reflog¶
Seek and ye shall find
git reflog -n 10
git checkout -b before_interactive_rebase HEAD@{3}
git log --graph --decorate --all --oneline
Rebasing requires force-push!!¶
Exercise¶
Remember that first commit in the way_back_machine branch? It's not in the graph any more, is it?
Get it back with reflog!
The Real GitHub Workflow¶
(to make the project maintainer love you)
- Fork and clone the repository (you did that already)
- Create a feature branch that contains your changes.
- Work on your changes.
- Push to your repository.
- Create a pull request.
Do it!
While you where away¶
- Oh no! While you were working, someone added a conflicting change - your pull request can't be merged!
- You need to resolve the conflict!
- Syncing with the original (aka upstream) repo:
add
git@github.com:amueller/repo_to_fork.gitas a remote to your cloned repo check out local master. Pull upstream master. This is why you don't want to change master. Ever! - Rebase your branch on top of master. Oh no, the conflict!
- Resolve the conflict.
- Look at your log. Damn lies! (but pretty)
- Push to your remote. (You have to force it)
- Your PR can now be merged!