Cheat sheets can be really helpful when you’re trying a set of exercises related to a specific topic, or working on a project. Because you can only fit so much information on a single sheet of paper, most cheat sheets are a simple listing of syntax rules. Git cheat sheet for network nuts students. Contribute to kehbixgit/git-cheat-sheet development by creating an account on GitHub. GitHub - abdullah-ch/Git-Cheat-Sheet: A Cheat Sheet which covers commands which do most of the work you want to do with git.
- Github Git Cheat Sheet Template
- Github Git Cheat Sheet For Beginners
- Github Git Cheat Sheet
- Github Commands Cheat Sheet
Create repositories
GitHub is one of the most popular services for hosting software development version control using Git.If you still aren’t familiar with Version Control and Git, you can check out my previous post, The Git Cheat Sheet, where I explain the basics.
A new repository can either be created locally, or an existing repository can be cloned. When a repository was initialized locally, you have to push it to GitHub afterwards.
$ git init
Github Git Cheat Sheet Template
The git init command turns an existing directory into a new Git repository inside the folder you are running this command. After using the git init
command, link the local repository to an empty GitHub repository using the following command:
$ git remote add origin [url]
Specifies the remote repository for your local repository. The url points to a repository on GitHub.
$ git clone [url]
Clone (download) a repository that already exists on GitHub, including all of the files, branches, and commits
The .gitignore file
Sometimes it may be a good idea to exclude files from being tracked with Git. This is typically done in a special file named .gitignore
. You can find helpful templates for .gitignore
files at github.com/github/gitignore.
Synchronize changes
Synchronize your local repository with the remote repository on GitHub.com
$ git fetch
Downloads all history from the remote tracking branches
$ git merge
Combines remote tracking branches into current local branch
$ git push
Uploads all local branch commits to GitHub
$ git pull
Updates your current local working branch with all new commits from the corresponding remote branch on GitHub. git pull
is a combination of git fetch
and git merge
- Legend:
<>
required,[]
optional
Common Terminology
- commit ≙ object with annotated changes in relation other commits
- branch ≙ collection of commits
- stage ≙ files earmarked for the next commit
- HEAD ≙ reference to the top commit in the current branch
- remote = bookmark for a repository origin (a repository may have several remotes)
Create & Clone
Clone an existing repository
Default protocoll is SSH, eg. »git@example.com:repo.git«. HTTPS would be »https://example.com/repo.git«, another local repo »/home/user/repo.git«
Creates a subfolder with the repo, if the folder name is not given, then the repo name is used (»foo.git« = »./foo« subfolder)
Create a new local repository
If a folder name is given, a subfolder is created, otherwise the current folder is used
Send existing local repository to remote
Special: Create an empty repository on a remote server
Connect with the remote server first
The remote repository has to be »bare« (does not contain a working filetree, but a special .git subdirectory only) in order to accept a push
Show changes
Show working status - show current branch name and changed or new files
Hint: Set a short alias for often used commands, like
git st
forgit status
→ see »Configuration«Difference between HEAD and files not yet staged
Note: This ignores new files = files which were not added to the repository yet and therefore arent »tracked«
Difference between HEAD and staged files
Difference between HEAD and all files (staged and not staged)
Difference between branches, two commits, etc
»+« line does exist in »bar« but not in »foo«, »-« reverse
Difference to another branch and show names of changed files only
Show all commits of current branch which are not merged into another branch
The reference may be a branch or a tag, note the two dots at the end
Show branches in which one commit exists
Show history
Show all commits of current branch
Show all commits of current branch and names of each changed file
Show commits and each difference for a specific file
Examination: Show who changed what and when in a file
Left side shows the last commit ID for the content on the right side
Show a single commit and its differences
Show all commits with a certain word in the commit message
Commit
Stage all (even untracked) files
Stage a tracked and modified file
Add hand-picked changes in a file to the next commit (≙ partial commit)
y
Yes, add this part to the next commitn
No, skip this partd
Don’t add this and all remaining parts of the files
Try to split the current part into smaller onese
Manually edit the partStage all changes in tracked files and start a commit
Commit all previously staged changes
Branches
List local branches
*
marks the current branchList remote branches
use
-a
to show local and remote branches at onceSwitch to a different branch
-t
checkout a new branch based on remote branch and save their connectionCreate a new branch based on HEAD
use
git checkout -b <branch>
to create a branch and switch right into itCreate a new branch based on a remote branch
use
--no-track
to create a new branch based on a remote branch, but don't save a connection between bothConnect a remote branch with a local branch
Show merged branches
--no-merged
will show branches not merged yetDelete a local branch
-d
will only delete the branch if it is merged with its remote branch (if set),-D
will force the deletionDelete a remote branch
Tags
Use tags to save a specific version (the commit relations up to this point) of a project. Merging older commits into the branch afterwards hence wont affect the tag.
Show all tags
-l
will show tag names only,-n<num>
will add a number of lines from the annotation (default is one)Mark the current commit with a tag
Hint: Use semantic version numbers as tags
Update
Download all changes from , but don't merge to HEAD yet
A manual merge is required now
Download changes and directly merge to HEAD
If the connection between remote & local branch is saved, then
git pull
is sufficientList all currently configured remote repositories
Show information about a remote, eg. which branches exist in this remote
Remove stale remote branch trackings (outdated connections)
Remove connections to branches deleted on the remote by now - does not delete the local branch
Add a new remote repository
Publish
Push local branch or tag to remote
use »-u« to push the branch and automatically save the connection between local & remote
Push all local branches to remote
Push all tags to remote
Merge
Merge a branch into your current HEAD
Manually solve conflicts and mark file as resolved
Use a tool to solve merge conflicts
will use tool set in »merge.tool«, use »-t « to start a custom tool
Use a merge strategy
»recursive« is the default merge strategy when pulling or merging one branch, so this param may be redundant
»ours« merge commits but try to ignore all conflicting changes from the other branch
»theirs« merge commits but try to ignore conflicts introduced by the own branch
»patience« will cause GIT run rather time-consuming intelligent merge routines to avoid merge conflicts and errors in the first placeCancel merge
Rebase
Use rebase with care! It will rewrite the history and therefore requires additional efforts when working with a team! Dont rebase unless every project member knows about the required workflow!
Rewrite commits from HEAD until given commit
Opens an editable rebase command list - reorder the commands to change commit order, remove a line to delete the commit, change the preceded keyword to change the command
p|pick
keep commitr|reword
use commit, but edit the commit messagee|edit
use commit, but halt the rebase sequence to change the commit (usegit commit --amend -a
)s|squash
use commit, but meld into previous commitRebase your current HEAD onto
Merges all commits of given branch and applies new commits of the local branch on top (creates new commit IDs for these)
Abort a rebase
Continue a rebase after resolving conflicts
Stash
Use stash to save all current changes to a clipboard and retrieve them later.
Stash all changes away
Show all available stashes
»stash@{0}« is the rather unreadable name of the stash state, where 0 is the latest
Retrieve a state form the stash list
default is »stash@{0}«, use
git stash pop <stash-name>
to apply changes and remove the state from stash listRemove a state from the stash list
Remove all the stashed states
Revert
Git is merciful and lets you undo allmost all changes with ease.
Clear stage (≙ unadd files)
Discard all changes
Change the last commit
Replaces the last commit (new ID), so it should only be used if the modified branch was not pushed yet
Special: Change author of the last commit
Remove the last commit but keep all files and changes
Removes the last commit from the local history
Revert a commit (≙ apply inversion)
Inverts changes of the given commit, applies them to the working directory and starts a new commit
Undo a local merge
Use only if the branch wasn't pushed yet, otherwise rebase or revert
Remove a file
Removes the file from the git repository index but keeps it on the file system
Configuration
Get configuration option
Set configuration option
»local« will write to ».git/config« in current repository, »global« to »~/.gitconfig» and »system« to your systems »/etc/gitconfig«
Set username and e-mail
Ignore mode changes (chmod)
Set alias »st« for »status«
Commit Message Format
Github Git Cheat Sheet For Beginners
shortened, detailed example at http://is.gd/commitformat
Best practices
- Commit related changes
- Each commit should adress one logical unit. Two different bugs should result into two commits.
- Commit early & often
- Keep your commits small and comprehensible, split large features into logical chunks.
- Test code before committing
- Make sure the code works, don't guess. Or let tools test your commit automatically. Revert faulty commits if necessary.
- Don't commit half-done work
- Commit only complete, logical changes, not half-done chunks. »Stash« changes if applicable.
- Don't commit hot files
- Don't commit configuration files (commit a config template instead), personal data, temporary files (GIT is no backup system) or things that can be regenerated form other commited things.
- Write good commit messages
- Help others to understand what you did (Motivation for the change? Whats the difference to the previous version?)
- Useless commit messages may be forwarded to whatthecommit.com
- Write in imperative present tense («change», not «changed» or «changes»)
- A commit is a set of instructions for how to go from a previous state to a new state, so you should describe was the commit does and not what it did to your repository.
- Don't panic
- GIT lets you undo, fix or remove a bunch of actions
- Don't change published history
- GIT allows you to rewrite public history, but it is problematic for everyone and thus it is just not best practice to do so.
- Use branches
- Branching is cheap. Use separate branches for each bugfix, feature & idea. Make branching a part of your local workflow.
- Merge regularly
- Don't merge a huge feature into the master, instead merge the master regularly with your branch.
- Use conventions
- As with every development process: use conventions. For naming of branches and tags, how to write commit messages, when to commit into what branch, etc.
Github Git Cheat Sheet
Sources
About
Github Commands Cheat Sheet
- Supervisor: Dan Untenzu @pixelbrackets
- License: CC-BY-SA 3.0
- Download & Contribution: pixelbrackets.de/git-cheat-sheet