MadinaB/git-commands

## git-commands
 .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
===================================================
	.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
	===================================================