nlivaic
10/24/2018 - 2:01 PM
Git cheatsheet
Git cheatsheet
/*******************************************************
* Git and Github - Command
*******************************************************/
$ git --version
$ git init -- Creates a repository and a .git folder. Doesn't perform the initial commit.
$ git log -- Shows log on currently checked out branch.
$ git log <branch>|<remote>/<branch> -- Shows log on <branch>.
$ git log -n 1 -- Show n commits.
$ git log --stat -- Show filename in each commit + number of changes in each file.
$ git log --name-only -- Show filename in each commit.
$ git log --graph <branch_1> <branch_2> -- Show branches visually. Try adding a --oneline to make it easier to read.
-- You can graph more than two branches (if you like).
$ git diff <older_id> <newer_id> -- Difference between commits <older_id> and <newer_id>.
$ git diff -- Difference between the Working directory and Staging area.
$ git diff --staged -- Difference between the Staging area and Repository.
$ git show -- Diff last commit with its parent
-- (Please note: PARENT!!!, not necessarily the commit prior to the one you are interested in - think merging!).
$ git show <commit_id> -- Diff between <commit_id> and its parent (Please note: PARENT!!!, see above for details).
$ git reset --hard -- Revert changes in Working directory and Staging area. Irreversible change!!!
$ git reset <file> -- Removed file from staging. Changes are kept.
$ git checkout -f -- Force checking out HEAD. Resets tracked files. Does not affect untracked files.
$ git clean -fd -- Remove untracked files and directories (e.g., new files, new folder, generated files)
$ git clean -fX -- Remove EVERYTHING, including ignored and untracked files (e.g., new files, generated files)
$ git revert -n <commit_id> -- Revert, but keep in Working Copy (do not commit reverted version automatically).
$ git revert -m 1 <commit_id> -- Revert a merge commit. Reverts all commits that were part of that merge.
-- You can't revert a merge commit if you used fast-forward commit.
$ git branch -- View branches on the current repository.
$ git branch <name> -- Create new branch (this branch will not be checked out automatically) on the current repository,
-- from the current HEAD. It essentially labels the current head with <name>.
$ git branch -d <branch_name> -- Create a branch from detached HEAD. It is the same thing as doing the following set of commands:
-- $ git branch <new_branch_name>
-- $ git checkout <new_branch_name>
$ git merge <branch_1> <branch_2> ... -- Merge specified branches into currently checked out branch.
$ git merge --abort -- Revert branches to state before the merge. Useful if you have a merge conflict.
$ git checkout -b <name> <from_branch> -- Create new branch and check out automatically.
$ git checkout <commit_id> -- Use an older commit (detached HEAD state).
$ git checkout master -- Use last commit as HEAD.
$ git checkout -b <name> -- Use with detached HEAD state, in a situation where you added new commits to the
detached HEAD and now want to make it into a new branch.
$ git checkout --track origin/branch -- Feature branch was created on remote. You have to checkout the branch from remote repo + start tracking immediately.
-- Branch must have a commit on remote repo, otherwise you must first do a # git pull origin
$ git stash -- Git moves uncommited changes along when you switch branches. If you want to "save" the changes without committing them,
$ git stash pop -- you have to stash them. Once you're done working on the other branch, you can retrieve the changes. If you have created new files (but
-- haven't committed them yet), you must first stage them before you can stash them.
$ git rc -- Garbage collection (removing deleted branches whose commits have not been merged and are therefore unreachable).
-- Committing process.
$ git status -- 1. Shows current branch working directory and staging area,
-- changed files, latest commit, untracked files. Also shows if there is any difference
-- in number/status of commits between local repo and repo on GitHub.
$ git add <filename> -- 2. Add entire file to Staging area.
$ git add --patch <filename> Or part of file.
$ git diff -- 3. Difference between the Working directory and Staging area.
$ git commit -- 4. Commits to repository. If a branch is checked out, it will commit to that branch.
-- Merging process
$ git checkout <branch> -- 1. checkout <branch> you want to merge into.
$ git merge --no-ff <branch_1> -- 2. merge the branche into the checked out branch.
$ -- 3. resolve conflicts by opening the conflicted file. 3 sections:
-- <<<<<<< HEAD <branch we're merging into>
-- ||||||| merged common ancestor
-- =======
-- >>>>>>> master <branch we're merging from>
$ git add <files> -- 4. add files to Staging area.
-- Conflict resolution is also signalled this way (no special "Resolved" option).
$ git rebase master -- Alternatively, you can rebase current branch on the tip of master.
$ git remote prune origin -- Once the feature branch has been merged back, you can stop tracking stale branches.
-- Creating a repository on GitHub and connecting it with our local repo - first approach.
$ -- 1. Create a new repo on GitHub directly (via GitHub website).
-- Give it any name, e.g. "reflections".
$ git init -- 2. Create a local directory and run this command in it.
$ git remote add <remote_repo_name> <url> -- 3. Add the remote repository (found in <url>) to the local repository
-- and name it <remote_repo_name>. <remote_repo_name> is a way to reference
-- the remote repo from within current local repository.
-- <remote_repo_name> is usually "origin" if we have only one remote.
-- Remote repo is a version/representation of the local project (repo),
-- but stored on a server. When the branch is pushed, the remote repo is
-- named same as the branch.
-- For simplicity, use HTTPS!
$ git remote -- 4. View all remotes (created by you or by repository owner).
$ git remote -v -- 5. Check if URL was added correctly.
-- Shows the URL you will fetch from and the URL you will push to.
-- Creating a repository on GitHub and connecting it with our local repo - second approach
$ -- 1. Create a new repo on GitHub directly (via GitHub website).
-- Give it any name, e.g. "reflections".
$ git clone <url> -- 2. Downloads a repository. It also sets up the remote to point to <url>.
-- Communicating with the repository
$ git push <target_remote> <branch_to_push> -- Push branch to remote. Branch on remote repo will have the same
-- name as the local branch that was just pushed.
$ git pull <target_remote> <remote_branch> -- Pull commits from remote repo's <branch> to a local <branch> of the same name.
-- e.g. $ git pull origin master -> local master
-- Merge differences immediately.
-- If local branch HEAD is an ancestor of new commits, then a "fast-forward commit" is done.
-- If local branch HEAD is not an ancestor of new commits (local and remote branch have diverged,
-- NO conflicting changes introduced), a new merge commit is created.
-- Same as: (master)$ git fetch origin + git merge master origin/master
-- If local and remote repo have diverged and you are NOT aware of it!
$ -- See above about pulling. You will have to resolve and then proceed with staging and commiting.
-- No big deal. Below is a more in-depth approach (same outcome).
-- If local and remote repo have diverged and you are aware of it!
(master)$ git fetch origin -- Pull commits from remote repo's branch with the same name as the local checked out branch:
-- e.g. GitHub origin/master -> Local origin/master
-- Updates local version of origin/<branch>. Does not affect your local <branch>,
-- only the local origin/<branch>
-- You can check log for your local origin/<branch> by doing $ git log origin/<branch>
-- Does not merge local <branch> and origin/<branch>!
$ git merge master origin/master -- Merge. Might warn of a conflict.
$ code <conflicted_file> -- Edit conflicted file.
$ git add <conflicted_file> -- Signal conflict resolution by staging the file.
$ git commit -- Commit the resolved file.
-- Forking a repository on GitHub.
$ -- 1. Go to GitHub and press "Fork" (upper left corner).
$ git clone <url> -- 2. Download repo to local computer.
-- Remote repo is already added, pointing to original repo on GitHub.
$ -- 3. Add collaborators: GitHub repo -> Settings -> Collaborators.
-- Pull request
$ -- A request towards someone (branch owner) to review and merge our branch.
-- It can also be thought of as a "merge request".
-- Every step is done on GitHub:
-- 1. Choose a branch you want the Pull request to be created for.
-- 2. Choose "Pull Request" option.
-- 3. GitHub assumes you want the original repository (if you forked)
-- to be the destination repo.
-- Set base fork to be e.g. master.
-- If the branch you are requesting to merge into has had additional commits
-- that will cause a conflict, you will have to resolve this locally. Please consult
-- the "Pull requests and conflicts" section further below.
/*******************************************************
* Git and Github - Concepts
*******************************************************/
# Row width: 80. -- Try to keep row width to 80 chars, it helps Git visualize changes better.
# Working directory --
# Staging Area -- Contains a copy of your local repository. When you stage a certain change, it gets moved to this staged copy.
-- When you commit the staged change, it remains in the Staging area.
-- Commit makes the staged area and local repository equal.
# Local repository --
# Remote repository --
# Reachability -- Each commit has a parent. Each commit stores its commit parent.
-- When you commit, current head becomes the new commit's parent (head moves, of course).
-- Log shows commits starting with the head and goes back to the first commit that does not
-- have a parent (usually this is the initial commit). Commits in different branches are
-- not visible from one another - this is what "reachability" means. When you do a commit
-- from the detached head state and then checkout an existing branch, that commit is now
-- lost, since it is not reachable from any of the current branches (to better visualize
-- this: create a commit graph with two concurrent branches and a commit from some detached
-- head. Now checkout one of the branches - there is no way for you to see that lost commit in
-- logs and you cannot do a checkout using branch names - you can do a checkout if you
-- remember the commit id).
# HEAD -- Current commit. When you make a new commit, head is moved to this new commit.
# Detached HEAD -- this means that we're looking at a commit that was not labeled with a branch name.
-- We can create a branch from this using: git branch -d <branch_name>
# Branch name -- A branch is actually a labeled commit. Head commit of a particular branch is the one
-- that is labeled. If the head is the same commit that is labeled as branch, when you
-- commit, the label moves to the new head.
-- Commits themselved do not know anything about the branches they belong to.
# Head and checkout -- When you do a checkout, you make some commit the new Head. Which commit? This depends: if you are
-- checking out a branch, then the new head becomes the branch's head. If you do a checkout on a specific
-- commit id, then that commit becomes the new head (detached HEAD state).
# Merge branch -- Once one branch is merged into another, all the commits from the merged branch are visible in the main branch.
-- Merge process compares three commits: heads of both branches and their common parent.
-- Merge and reachability: merge commit has two parents (one from each branch).
# Cloning -- A Git concept. We can clone a remote repository (from GitHub url) to our local computer.
-- We can clone a repo from a local computer as another (new) local repo.
# Remote branch -- A branch created on the remote repository. We can do a checkout and use it as if it were a regular branch.
-- Git stores locally state of all remote branches:<remote>/<branch>. Local Git stores last known position (commit ID)
-- and the repository. This way when you do a "git fetch", you get all the newest changes from origin <branch>, but this does not
-- affect your local <branch>, only local origin/<branch>.
-- State is updated everytime we push or pull.
# Fast-forward merge -- Occur when one commit (the one with the branch tag) is the ancestor of another commit (the other branch tag).
-- When merging, if local branch HEAD is an ancestor of new commits,
-- then a "fast-forward commit" is done (no new commit). It simply moves the HEAD of the current branch.
-- It is easy to do a fast-forward merge when you first perform a rebase.
-- HOWEVER, if you merge on GitHub, it does create a new commit (even if the new commit wasn't necessary).
# Pull request -- A purely GitHub concept! Merging a pull request results in a new commit, even if a ff-commit would have sufficed.
# Pull requests and -- All such conflicts must be resolved LOCALLY. GitHub will notify you of conflicts, but it will not
conflicts -- resolve conflicts - you must pull conflicting branches and resolve locally. PLEASE CONSULT POINTS BELLOW.
# Pull request conflict -- Merging directly on GitHub is not allowed in such cases. Such conflict must be resolved locally.
in your repo -- You must first merge master into branch LOCALLY. Then push (this updates the pull request).
-- Only then can you merge the pull request directly on GitHub.
# Pull request conflict -- So you have a fork and on it a branch - and want to do a pull request from the branch towards
towards fork's orig. -- the original repo, but there are conflicting changes present. You first create a new remote to point
repo -- to original repo, called "upstream". Checkout the master. Do a "$ git pull upstream/master" to update
-- the local master branch to the latest commit on the original repo. Merge master into branch.
-- Push branch (this updates the pull request as well). Your branch is now up-to-date with the
-- original repo's + it has your changes that you want to pull into original repo.
# Rebase -- Useful for integrating smaller feature branches. For longer-running feature branches, use 3-way --no-ff merge commits.
# Forking -- A purely GitHub concept! Cloning a repository directly on GitHub, under your own account.
-- When you do a fork, it is customary to immediately create another branch. This way
-- your master can be kept synchronized with the original repo and branch can be used for development.
-- You fork directly via GitHub web UI.
# Collaborators -- A purely GitHub concept! A list of people you allow psuhing to your repository.
-- Settings -> Collaboration