Created
August 22, 2018 08:01
-
-
Save MadinaB/7af3cedc439cb8a97e59c5ec819bb57d to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
.gitignore file | |
To see the file in folder make 'ls a', to modify do 'vi .gitignore file'. Use this file to insert there full pathes and names of folders/files/objects you would not want to commit to the repo. | |
git init | |
To create a new, empty repository in the current directory | |
git status | |
Shows status of current repo | |
git log | |
To see all history of commits | |
git log --oneline | |
To see short version of git log: with SHA and message commit only | |
git log --stat | |
Displays the files that have been changed in the commit, as well as the number of lines that have been added or deleted | |
git log -p | |
Displays all commits with: the author, the date, the commit mesage, the patch information | |
git log -p 'commit's SHA' | |
By supplying a SHA, the git log -p command will start at that commit! No need to scroll through everything! Keep in mind that it will also show all of the commits that were made prior to the supplied SHA. | |
git show 'commit's SHA' | |
Displays the commit, the author, the date, the commit mesage, the patch information | |
git diff | |
The git diff command can be used to see changes that have been made but haven't been committed, yet. | |
git tag -a 'Tag Name' | |
Creation of annotated flag to current commit | |
git tag -a 'Tag Name' -m 'Tag Message' | |
Creating tag without commit message returns me fatal error, so I use -m flag to add mesage. ex: git tag -a 'Udacity2.1-2.6' -m 'All info till module 2.6' | |
git tag -a 'Tag Namee' 'SHA of commit to be annotated with tag' | |
Create tag for some specific commit | |
git tag -d 'Tag Name' | |
Deleter tag with 'Tag Name' | |
git tag | |
Displays all tags that are in the repository | |
git log --decorate | |
Displays as git log, but with tag messages | |
git branch | |
List all branch names in the repository, create new branches, delete branches. It also shows the current branch, by inserting star (*) before an active branch in ouput list | |
git branch 'Branch Name' | |
Create new branch with branch name | |
git branch 'Branch Name' 'commit's SHA' | |
Will create new branch starting from specific commit | |
git branch -d 'Branch Name' | |
Deletes branch with branch name. You can't delete a branch that you're currently on.(After a branch's changes have been merged, you probably won't need the branch anymore.). However github WON'T LET you delete a branch if it has commits on it that aren't on any other branch. | |
git branch -D 'Branch Name' | |
Force delete since 'git branch -d' does not delete branch if there are commits which are not commited yet. | |
git checkout 'Branch Name' | |
To switch between branches, we need to use Git's checkout command. It will remove all files and directories from the Working Directory that Git is tracking (files that Git tracks are stored in the repository, so nothing is lost), go into the repository and pull out all of the files and directories of the commit that the branch points to. So this will remove all of the files that are referenced by commits in the master branch. It will replace them with the files that are referenced by the commits in the sidebar branch. | |
git checkout -b 'Branch Name' | |
Creates new branch and moves there in one command. | |
git log --oneline --decorate | |
But just like we had to use the --decorate flag to display Git tags, we need it to display branches. | |
git log --oneline --decorate --graph --all | |
See All Branches At Once. The --graph flag adds the bullets and lines to the leftmost part of the output. This shows the actual branching that's happening. The --all flag is what displays all of the branches in the repository. | |
git commit --amend | |
With the --amend flag, you can alter the most-recent commit. | |
-> If your Working Directory is clean), then running git commit --amend will let you provide a new commit message. Just fix a misspelling or completely reword it! | |
-> Alternatively, git commit --amend will let you include files (or changes to files) you might've forgotten to include. => 1) edit the file(s). 2) save the file(s) 3) stage the file(s) 4) and run git commit --amend | |
git revert <SHA-of-commit-to-revert> | |
If a character is added in commit A, if Git reverts commit A, then Git will make a new commit where that character is deleted. Something that's also important is that it creates a new commit. | |
git reset <reference-to-commit> | |
Resetting Is Dangerous. Reverting creates a new commit that reverts or undos a previous commit. Resetting, on the other hand, erases commits! | |
git reflog | |
Git does keep track of everything for about 30 days before it completely erases anything. To access this content, you'll need to use the git reflog command. | |
^ | |
^ – indicates the parent commit | |
~ | |
~ – indicates the first parent commit | |
The main difference between the ^ and the ~ | |
The main difference between the ^ and the ~ is when a commit is created from a merge. A merge commit has two parents. With a merge commit, the ^ reference is used to indicate the first parent of the commit while ^2 indicates the second parent. The first parent is the branch you were on when you ran git merge while the second parent is the branch that was merged in. | |
the parent commit | |
the parent commit – the following indicate the parent commit of the current commit: 1) HEAD^ 2) HEAD~ 3) HEAD~1 | |
the grandparent commit | |
the grandparent commit – the following indicate the grandparent commit of the current commit: 1) HEAD^^ 2) HEAD~2 | |
the great-grandparent commit | |
the great-grandparent commit – the following indicate the great-grandparent commit of the current commit: 1) HEAD^^^ 2) HEAD~3 | |
git reset HEAD~1 | |
is same with | |
git reset --mixed HEAD~1 | |
Moves head and master to previous commit. Changes made to current commit are moved to working directory(not trash and not staging index), you can add them and commit again. All will be the same, but woth different SHA since it is different commit already. | |
git reset --softed HEAD~1 | |
Moves head and master to previous commit. Changes made to current commit are moved to staging index. | |
git reset --hard HEAD~1 | |
Moves head and master to previous commit. This will remove all changes that were made with last commit. Assume, that it is not possible, to retutn changes back. But remember about git reflog. | |
git branch backup | |
Before I do any resetting, I usually create a backup branch on the most-recent commit so that I can get back to the commits if I make a mistake | |
git remote | |
Will let you manage and interact with remote repositories. If you haven't configured a remote repository then this command will display nothing. You can: 1) Create folder 2) Run 'git init' to convert this folder to git repository 3) Add some files to it 4) Add README.md 5) Go to github and intialize new repo without README.md 6) Copy link to newly created repo 7) Run 'git remote add origin <link>' in your folder 8) Run 'git push -u origin master' to upload files to Github | |
git remote -v | |
Verify that I've added the remote repository correctly | |
git clone <link> | |
Clone repo to your computer | |
git push <remote-shortname> <branch> | |
git push origin master | |
git pull | |
git pull origin master | |
git fetch origin master | |
The important thing to note is that the local branch does not change at all. It creates new local tracking branch (e.g. origin/master) and makes it point to most recent commit. You can simply make 'git merge origin/master' after 'git fetch origin master' and it will be the same as you made 'git pull origin master'. !!! One main point when you want to use git fetch rather than git pull is if your remote branch and your local branch both have changes that neither of the other ones has. In this case, you want to fetch the remote changes to get them in your local branch and then perform a merge manually. Then you can push that new merge commit back to the remote. | |
git shortlog | |
A quick way that we can see how many commits each contributor has added to the repository. git shortlog displays an alphabetical list of names and the commit messages that go along with them. | |
git shortlog -s -n | |
If we just want to see just the number of commits that each developer has made, we can add a couple of flags: -s to show just the number of commits (rather than each commit's message) and -n to sort them numerically | |
git log --author=Surma | |
Filter by author | |
git log --author="Paul Lewis" | |
Pay attention to the use of the quotes in the previous command. If it were written without the quotes like this git log --author=Paul Lewis, it would not work. If it's formatted this way without the quotes, Git would think that Lewis is not part of the "author" flag, and it would cause an error. | |
git show 'commit's SHA' | |
Shows log for specific commit | |
git log --grep=bug | |
git log --grep bug | |
How about we filter down to just the commits that reference the word "bug". We can do that with either of the following commands. | |
git remote add upstream <link> | |
As with the origin shortname, the word upstream here is not special in any way. 'upstream' is just the shortname to reference the source repository. What might be confusing is that origin does not refer to the source repository (also known as the "original" repository) that we forked from. Instead, it's pointing to our forked repository. So even though it has the word origin is not actually the original repository. | |
git remote rename before after | |
git remote rename mine origin, git remote rename source-repo upstream | |
git fetch upstream master | |
To get the changes from upstream remote repository, all we have to do is run a git fetch and use the upstream shortname rather than the origin shortname | |
==================================================== | |
# to make sure I'm on the correct branch for merging | |
$ git checkout master | |
# merge in Lam's changes | |
$ git merge upstream/master | |
# send Lam's changes to *my* remote | |
$ git push origin master | |
==================================================== | |
git rebase | |
git rebase -i HEAD~3 | |
git rebase -i <base> | |
The git rebase command will move commits to have a new base. It is very powerful tool to squash your commits into one, but be aware: it can be very dangerous to use since can fully delete commits. So always create backup branch, so commits left out of git log after squashing will not be deleted. If you want to squash 17 commands, just use that number HEAD~17. So running 'git rebase -i HEAD~17' will take 17 last commits and squash them into one having absolutely new SHA. | |
git push -f | |
Force push => using git rebase creates a new commit with a new SHA. When I tried using git push to send this commit up to GitHub, GitHub knew that accepting the push would erase the three separate commits, so it rejected it. So I had to force push the commits through using git push -f. | |
=================================================== | |
Other different commands that you can do with git rebase: | |
use p or pick – to keep the commit as is | |
use r or reword – to keep the commit's content but alter the commit message | |
use e or edit – to keep the commit's content but stop before committing so that you can: | |
add new content or files | |
remove content or files | |
alter the content that was going to be committed | |
=================================================== |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment