A collection of convenient git commands I’ve collected over the years. Github - using Git is a good resource to understand the commands provided in Git.
| Action | Description |
|---|---|
commit |
Creating a commit to your local branch |
push |
Pushing commits to a remote repository |
fetch |
Getting changes made from a remote repository |
merge |
Merges online changes into your local branch |
pull |
Does fetch and merge |
rebase |
Edit previous commit messages, combine multiple commits into one, delete or revert commits that are no longer necessary |
checkout |
Checking out a branch (local or remote) to work on |
diff |
Compares changes made locally to what’s online |
cherry-pick |
choose a commit from one branch and apply it onto another. |
| Action | Description |
|---|---|
whatchanged |
Shows a detailed history of what has changed |
log |
Shows a brief history of what has changed |
clone |
Cloning a repository |
This will take all the commits from the bugfix branch, squash them into 1 commit and then merge it with your master branch.
git checkout master
git merge --squash bugfix
git commitThe below steps is something I’ve dug out of StackOverFlow. It’s good for when many people are working on a repository, but the better practice is maybe doing a pull request merge.
From Github’s website:
Warning: Because changing your commit history can make things difficult for everyone else using the repository, it’s considered bad practice to rebase commits when you’ve already pushed to a repository. To learn how to safely rebase on GitHub, see “About pull request merges.”
git checkout -b developgit checkout mastergit pullgit checkout developgit rebase mastergit checkout mastergit pullgit merge developUse git rebase -i <after-this-commit> and replace “pick” on the second and subsequent commits with “squash” or “fixup”, as described in the manual.
In this example, <after-this-commit> is either the SHA1 hash or the relative location from the HEAD of the current branch from which commits are analyzed for the rebase command. For example, if the user wishes to view 5 commits from the current HEAD in the past the command is git rebase -i HEAD~5.
git diff --name-only --diff-filter=U
git diff branch1:full/path/to/foo.txt branch2:full/path/to/foo-another.txt
You can also use relative paths:
git diff branch1:./relative/path/to/foo.txt branch2:./relative/path/to/foo-another.txt
Link to an article for a detailed explanation
From SOF:
git checkout mastergit cherry-pick <commit-hash>If you cherry-pick from a public branch, you should consider using:
git cherry-pick -x <commit-hash>
This will generate a standardized commit message. This way, you (and your co-workers) can still keep track of the origin of the commit and may avoid merge conflicts in the future.
If you have notes attached to the commit they do not follow the cherry-pick. To bring them over as well, you have to use:
git notes copy <from> <to>
Fork documentation from Github
$ git checkout master$ git pull https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git BRANCH_NAME$ git push origin mastertl;dr:
$ git checkout master
$ git branch -r --merged
$ git branch -d old-merged-feature $ git branch --no-merged
$ git branch -r$ git remote prune origin
$ git fetch -p
$ git branch --v | grep "\[gone\]" | awk '{print \$1}' | xargs git branch -DBFG is great for cleaning up if a commit that you want to get rid of (e.g. passwords, big files) has been pushed.
Otherwise, you can also hard reset and force update. This article is insightful about the dangers of doing something like that, as the repo could be easily destroyed. Act with caution and care. This works only if you were the last person to push to master. You cannot force push once other people have pushed, as it the commits they made will be gone forever.