rrubiorr81/gist course

## gist course

//when working on a wrong branch-- to apply these changes to the interested branch...
git stash
git checkout branch123
git stash apply

//assuring that the file is updated in git index.. and therefore, can be included in the .gitignore...
git update-index --assume-unchanged path/to/file

//git diff can show you the difference between two commits:
git diff mybranch master -- myfile.cs

//browsing the branches in origin... and greping inside...
git ls-remote | grep hotfi

//bad git pull on the wrong branch...
git pull ---> whoops?

git reset HEAD@{1}

Git course notes
//powerful blame GUI
git gui blame filename

//storing git credentials to avoid re-entering them in every push, pull, fetch...
$ git config credential.helper store
$ git push http://example.com/repo.git
Username: <type your username>
Password: <type your password>

[several days later]
$ git push http://example.com/repo.git
[your credentials are used automatically]

//changes on a file.. author and dates.. SHA
git gui blame includes\core_excel_gen.inc.php


apparently with u do 'add' you are adding to the stagig area, and commiting u are puting to the final area. Then what does the 'commit -ma' does? The '-m' option stands for nameing the name of the change made. But the '-a' means the direct path to staging and automaticly to the final step. É?

**** some site where u can find some interesting cheatsheets...
https://github.com/github/teach.github.com/blob/gh-pages/cheatsheets/_posts/2001-01-01-git-cheatsheets.md


//a diagram about git command {i found this in a page explaining why the blogger hates GIT}
http://steveko.files.wordpress.com/2012/02/git-arrows31.png

/*Lynda GIT course*/
/*git is based in the distributed version control. That means that there is no master repos, but just a list of changes on
every station. So u have a set of deltas, that's it..  of course, by convention u can define a master repo, where everyone
submits their changes..
so in some point u want to apply some of the changes from developper Z, u can do it. This gives as result a faster VCS
wit no central server, no need of dedicated network access
-encourages participation and forking
 */
/*	git can be used in no matter what resource although it works better with text*/
//helping address in github
https://help.github.com/articles/set-up-git

//getting the directory where git lies
which git
//the version
git --version
//there are 3 diff kinds of configuration level.. System (Program Files\git\etc\gitconfig) , User , Project (my_prject/.git/config)
//commonly, the user config are in $home/.gitconfig
//my actual content in .gitconfig: --user
[gui]
        recentrepo = C:/Projects/GIT/test-repo
        recentrepo = C:/Projects/GIT/prueba
[user]
        email = rrubiorr81@gmail.com
        name = Richard Rubio
[color]
        diff = auto
        status = auto
        branch = auto

//in the command line
git config --system 	//system
git config --global		//user
git config 				//project

git config --global user.name "Richard Rubio"
git config --global user.email "rrubiorr81@gmail.com"

//establishing the editor for git in config..  in this case sublime.. with the wait flag
git config --global core.editor "'c:/program files/sublime text 2/sublime_text.exe' -w"
//giving color responses
git config --global color.ui=true
//prompt from the git help...
$ git help
usage: git [--version] [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
           [-p|--paginate|--no-pager] [--no-replace-objects] [--bare]
           [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
           [-c name=value] [--help]
           <command> [<args>]

The most commonly used git commands are:
   add        //Add file contents to the index
   bisect     //Find by binary search the change that introduced a bug
   branch     //List, create, or delete branches
   checkout   //Checkout a branch or paths to the working tree
   clone      //Clone a repository into a new directory
   commit     //Record changes to the repository
   diff       //Show changes between commits, commit and working tree, etc
   fetch      //Download objects and refs from another repository
   grep       //Print lines matching a pattern
   init       //Create an empty git repository or reinitialize an existing one
   log        //Show commit logs
   merge      //Join two or more development histories together
   mv         //Move or rename a file, a directory, or a symlink
   pull       //Fetch from and merge with another repository or a local branch
   push       //Update remote refs along with associated objects
   rebase     //Forward-port local commits to the updated upstream head
   reset      //Reset current HEAD to the specified state
   rm         //Remove files from the working tree and from the index
   show       //Show various types of objects
   status     //Show the working tree status
   tag        //Create, list, delete or verify a tag object signed with GPG
//in windows when u do
git help log //for an specific command manual, the app launches the browser for displaying the help page..
//initializing
git init 	//tells git to start tracking changes in current folder...
git add . 	//tells git to add all in the folder...
git commit -m "a message"	//comminting with a message
--usual process
*--make the changes
*--add the changes
*--commit the changes to the repository with a message

git log 		//getting logs
git log -n 1	//getting logs, only 1
git log --since=2013-11-10
git log --until=2013-11-10
git log --author="Rubio"	//just a part of the name
git log --grep="nit" 		//searches for coincidences in all parts of the log...

//differently than SVN, git uses three trees. 1- working copy 2- the staging area and 3- the repository.
//this means that if for example we have made 10 changes, we can decide to add 5 to the staging area and
//then in a single commit, to tags all 5 of them, keeping in the working area some unsaved changes...

**---https://docs.google.com/file/d/0B6OcYM1tY4goNmNaM1ZWUzhrZGM/edit?usp=sharing

//on every change, commited to the staging area and then to the working directory, we are dealing with deltas on several files
//they are snapshots of the stage of the whole changes files in that commint wheter in 2 or 3.

***---https://drive.google.com/file/d/0B6OcYM1tY4goU2JPOVhnYjB6b1U/edit?usp=sharing

//git stores a pointer to the HEAD. (and its called like that), to the most recent commint in the repository, in the current branch.
//its the place we are going to start recording the next time. If u enter in the .git directory, u will find
//a file called HEAD. This file points to a folder (refs/head/master {master if this is the branch we are working on})
//and in this referenced file we find a SHA (694e1135bec15d3e4973c2e8191ab3b71e781725). This is the code for the next parent in the repository tree.

***---https://drive.google.com/file/d/0B6OcYM1tY4goNENMT2VEelY2SW8/edit?usp=sharing

git status 	//its going to gives us the differences between the three trees. (1, 2 and 3)
//example-
//# On branch master
//nothing to commit, working directory clean		--this means, nothing new in 1, 2... the staging directory is clean and the working directory exactly matches the repository directory.

git reset HEAD second_file.txt 		//to pull out something from the staging directory. reseting its correspondig head in reference pointer.

//after a modification, the process to add to git is the same as if it was a new file...

//to see the differences among what is present in the working directory and the repository just type...
 git diff [the_file_to_inspect] 		//info on all the diff files, only the changed lines...
 //to see differences among the staging area and the repository
 git diff --staged [the_file_to_inspect]
 //to delete a file from the repository (and from the working directory), u pass throught the staging area like other times, with the command
 git rm delete1.txt 	//and then  u can commit this change... in this case the deletion of this file....

//to rename a file
git mv second_file.txt secondary_file.txt 	//this would rename the file and add it to the staging area, in one step
//moving and renaming here is the same
git mv third_file.php first_directory/third_file_.php 	//moving and renaming at the same time..

//before the first commit, there is nothing in the log, of course...

//N-- in the editor, when typing
git diff one_file.txt
//u can type -S [enter] to be able to see the whole line in the screen, in those cases where the lines are too long...
//to toggle back... just do the same...
git diff --color-words contact.html 	//this one, instead of giving u the diff in two lines, points incolors the differences.. great!
//* giving differences from this commit to the present...
git diff ac1d2c4

//commiting directly from the working directory... its only good if u want to put everything present in the working directory in git
//and if u are adding modifications only... it doesnt work well with new files or adding deleted files...
git commit -am "change the phone 24 hours number to 4314"
//
git add tours/ 	//its going to add everything inside this directory...
//N-- its desirable to make connected commits, and not mix them... in every commit a problem solved or a bug or a fix or an addd.. but all of them related stuff

git checkout -- index.html 	// git checkout index.html would work, but this double dash is to specify that we are not talking about a branch...
							//it could work git checkout index.html, but its a good practice to use the '--'
							//'--' => we are talking about a file in the current branch
git checkout HEAD~3           //bringing the commit tree three iterations in the past
git checkout master           //to return to the prior state, the most recent commits on top...
//to unstage some file
git reset HEAD <file> 		//reset the this file to the head last commited related to it...
//it is possible to correct a previous commit (only the last one)... if u forget somethig that is supposed to be in the
//last commit or by the contrary, should not be there, then u just put it in the stage [git add/rm <the file>]
//then u make 		u can do changes in the message with similar procedure
git commit --amend -m "the same message" 	//or a different message ... if empty is going to assume the same message
//in git u can use the SHA number to revert to an old state.
git checkout 538694702ccb -- forth_file.txt 	//in this example we are bringing back the file forth_file.txt to the state it was in 538694702ccb correspondig.
												//after performing this operation, of course, there will be differences between the version in the working directory and the repository
												//that's why git puts in stage ready to commit, this roll-back, to make it permanent as it could make sense.
//for a quicker procedure (nothing pop to the stage area for confirmation.. etc), we use:
git revert 538694702ccb   //we pass the log SHA that we weant to completely revert. Its going to do a mirror on that commit.


//N-- git reset ->chnges the repository to the point u ask git to and:
  // --soft
        //does not change staging index or working directory
  // --mixed
        //changes stage index to match repository
        //does not change working repository
  // --hard
        //changes staging and working directory index to match repository
git reset --soft ac1d2c4abd0f267cb82e0c78bd9ac4dd14167351     //it puts the head in this point..
//this kind of things is a good idea for example.. if u want to go back maybe three commits. doing f. instance, a reset --mixed 93432etc
//give u the chance to have the files untouched in the working directory and in the point u want in the past in the repository
//this would allow u to re-commit this in the desired way...
git reset --mixed ac1d2c4abd0f267cb82e0c78bd9ac4dd14167351


WD: working directory
SI: stage index
R:  repository

git log -> A, B, (C)  //C pointed by HEAD
//assuming u git reset to B

            WD              SI              R
--soft      C               C               B

--mixed     C               B               B

--hard      B               B               B

//resuming u can pass from --mixed to --soft adding the differences to stage...
//u can do a reset to a future version too...

//all of these resets, gives u the chance to go back to the "abandoned", to the "erase" data. If u have the SHA of the dumped commits then you
//can go to this stage doing the same
git reset --hard [the_last_commit_again]  //and u will have it again in u r git repositories...
//But if u write some new commit after the reset, then these old commits are going to be completely LOST...

//removing untracked files... (not in the repository and not in the staging index)
git clean -f

//using .gitignore to stop tracking files.. inside the .gitignore file u can write several rules, causing to ignore those who match these
*.php
!index.php
resources/    //and some other rules u would search if u need them..
//---> this two addresses are interesting...
https://help.github.com/articles/ignoring-files
https://github.com/github/gitignore
//to add a general gitignore file...
git config --global core.excludesfile /Users/Richard/.gitignore_global
//to stop tracking a file, already in the repo...
git rm --cached <file_name>   //u have to additionally put it {the file} in the .gitignore file....
//git is designed to trck files... so when a directory is empty, by default is not going to be tracked...
//in order to fix this, the comunity usually creates an empty file inside the directory {by convention .gitkeep}, so that u could add it to repository...

//referencing commits
  //u can do it by the SHA, the parent, the HEAD
  acf54cj12ds^, HEAD^ //referencing the parent
  HEAD~1 //the same... the # is how many ancesters going up to search
  HEAD^^, HEAD~2 //the grandparent
//-->
git ls-tree HEAD                                                //prints out the content of the commit in this point..
git ls-tree master                                              //the same thing since this is the branch we are working in
git ls-tree master first_directory/                             //accessing to the tree inside a directory
git ls-tree 6e2334099352b476048f08061ad5664680b33f34            //this SHA corresponds to first_directory one, so it going to give the same response

//it prints a list of the logs resumed to one line each...
git log --oneline
git log --oneline -3  //only the latest 3

git log --since="two weeks ago" --until="two days ago"
git log --since=four.days --until=two.days
git log 53188c8..e7c3245 --oneline                              //from oldest to newest.. thats the order...
git log 694e113.. secondary_file.txt                            //show me the changes since 694e113 till now in <secondary_file.txt>
git log -p                                  //detailed          //*showing what happened in every log.. (details of changes on files -- all)
git log -p  694e113.. secondary_file.txt                        //*changes details in this period... for this file...
git log --stat --summary --oneline                              //very useful data resume (the number of "+" and "-" correspond to the amount of data added or deleted, respectively)
git log --format=oneline                                        //same as --oneline, but this returns the whole SHA
git log --graph                                                 //a more visual look
git log --format=full [fuller, short, etc]
git log --oneline --decorate --graph --all                      //compact and clear log output
git log --follow -p <file>                                      //This will show the entire history of the file (including history beyond renames and with diffs for each change).
                                                                //In other words, if the file named bar was once named foo, then git log -p bar (without the --follow option) will only show the file's history up to the point where it was renamed -- it won't show the file's history when it was known as foo. Using git log --follow -p bar will show the file's entire history, including any changes to the file when it was known as foo.

gitk <file_name>                                                //*showing graphic data from file_name, when present, and the changes related.
git show e7c3245                                                //*show diff for this commit [usually the SHA comes from a git log --oneline command]
//so, a quite handy tool is to print the ls-tree with 'git ls-tree HEAD [HEAD~3]' and then to see the content of the file or directoy use
// 'git show [the SHA for that file or directory]'
//it doesn't work with the filename since it doesn't know the iterations in the past this file is...


git reset --hard                                                //To reset every file in your working directory to its committed state
git am

---left in some place in the G:\09. Navigating the Commit Tree

	//when working on a wrong branch-- to apply these changes to the interested branch...
	git stash
	git checkout branch123
	git stash apply

	//assuring that the file is updated in git index.. and therefore, can be included in the .gitignore...
	git update-index --assume-unchanged path/to/file

	//git diff can show you the difference between two commits:
	git diff mybranch master -- myfile.cs

	//browsing the branches in origin... and greping inside...
	git ls-remote \| grep hotfi

	//bad git pull on the wrong branch...
	git pull ---> whoops?

	git reset HEAD@{1}

	Git course notes
	//powerful blame GUI
	git gui blame filename

	//storing git credentials to avoid re-entering them in every push, pull, fetch...
	$ git config credential.helper store
	$ git push http://example.com/repo.git
	Username: <type your username>
	Password: <type your password>

	[several days later]
	$ git push http://example.com/repo.git
	[your credentials are used automatically]

	//changes on a file.. author and dates.. SHA
	git gui blame includes\core_excel_gen.inc.php


	apparently with u do 'add' you are adding to the stagig area, and commiting u are puting to the final area. Then what does the 'commit -ma' does? The '-m' option stands for nameing the name of the change made. But the '-a' means the direct path to staging and automaticly to the final step. É?

	**** some site where u can find some interesting cheatsheets...
	https://github.com/github/teach.github.com/blob/gh-pages/cheatsheets/_posts/2001-01-01-git-cheatsheets.md


	//a diagram about git command {i found this in a page explaining why the blogger hates GIT}
	http://steveko.files.wordpress.com/2012/02/git-arrows31.png

	/Lynda GIT course/
	/*git is based in the distributed version control. That means that there is no master repos, but just a list of changes on
	every station. So u have a set of deltas, that's it.. of course, by convention u can define a master repo, where everyone
	submits their changes..
	so in some point u want to apply some of the changes from developper Z, u can do it. This gives as result a faster VCS
	wit no central server, no need of dedicated network access
	-encourages participation and forking
	*/
	/* git can be used in no matter what resource although it works better with text*/
	//helping address in github
	https://help.github.com/articles/set-up-git

	//getting the directory where git lies
	which git
	//the version
	git --version
	//there are 3 diff kinds of configuration level.. System (Program Files\git\etc\gitconfig) , User , Project (my_prject/.git/config)
	//commonly, the user config are in $home/.gitconfig
	//my actual content in .gitconfig: --user
	[gui]
	recentrepo = C:/Projects/GIT/test-repo
	recentrepo = C:/Projects/GIT/prueba
	[user]
	email = rrubiorr81@gmail.com
	name = Richard Rubio
	[color]
	diff = auto
	status = auto
	branch = auto

	//in the command line
	git config --system //system
	git config --global //user
	git config //project

	git config --global user.name "Richard Rubio"
	git config --global user.email "rrubiorr81@gmail.com"

	//establishing the editor for git in config.. in this case sublime.. with the wait flag
	git config --global core.editor "'c:/program files/sublime text 2/sublime_text.exe' -w"
	//giving color responses
	git config --global color.ui=true
	//prompt from the git help...
	$ git help
	usage: git [--version] [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
	[-p\|--paginate\|--no-pager] [--no-replace-objects] [--bare]
	[--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
	[-c name=value] [--help]
	<command> [<args>]

	The most commonly used git commands are:
	add //Add file contents to the index
	bisect //Find by binary search the change that introduced a bug
	branch //List, create, or delete branches
	checkout //Checkout a branch or paths to the working tree
	clone //Clone a repository into a new directory
	commit //Record changes to the repository
	diff //Show changes between commits, commit and working tree, etc
	fetch //Download objects and refs from another repository
	grep //Print lines matching a pattern
	init //Create an empty git repository or reinitialize an existing one
	log //Show commit logs
	merge //Join two or more development histories together
	mv //Move or rename a file, a directory, or a symlink
	pull //Fetch from and merge with another repository or a local branch
	push //Update remote refs along with associated objects
	rebase //Forward-port local commits to the updated upstream head
	reset //Reset current HEAD to the specified state
	rm //Remove files from the working tree and from the index
	show //Show various types of objects
	status //Show the working tree status
	tag //Create, list, delete or verify a tag object signed with GPG
	//in windows when u do
	git help log //for an specific command manual, the app launches the browser for displaying the help page..
	//initializing
	git init //tells git to start tracking changes in current folder...
	git add . //tells git to add all in the folder...
	git commit -m "a message" //comminting with a message
	--usual process
	*--make the changes
	*--add the changes
	*--commit the changes to the repository with a message

	git log //getting logs
	git log -n 1 //getting logs, only 1
	git log --since=2013-11-10
	git log --until=2013-11-10
	git log --author="Rubio" //just a part of the name
	git log --grep="nit" //searches for coincidences in all parts of the log...

	//differently than SVN, git uses three trees. 1- working copy 2- the staging area and 3- the repository.
	//this means that if for example we have made 10 changes, we can decide to add 5 to the staging area and
	//then in a single commit, to tags all 5 of them, keeping in the working area some unsaved changes...

	**---https://docs.google.com/file/d/0B6OcYM1tY4goNmNaM1ZWUzhrZGM/edit?usp=sharing

	//on every change, commited to the staging area and then to the working directory, we are dealing with deltas on several files
	//they are snapshots of the stage of the whole changes files in that commint wheter in 2 or 3.

	***---https://drive.google.com/file/d/0B6OcYM1tY4goU2JPOVhnYjB6b1U/edit?usp=sharing

	//git stores a pointer to the HEAD. (and its called like that), to the most recent commint in the repository, in the current branch.
	//its the place we are going to start recording the next time. If u enter in the .git directory, u will find
	//a file called HEAD. This file points to a folder (refs/head/master {master if this is the branch we are working on})
	//and in this referenced file we find a SHA (694e1135bec15d3e4973c2e8191ab3b71e781725). This is the code for the next parent in the repository tree.

	***---https://drive.google.com/file/d/0B6OcYM1tY4goNENMT2VEelY2SW8/edit?usp=sharing

	git status //its going to gives us the differences between the three trees. (1, 2 and 3)
	//example-
	//# On branch master
	//nothing to commit, working directory clean --this means, nothing new in 1, 2... the staging directory is clean and the working directory exactly matches the repository directory.

	git reset HEAD second_file.txt //to pull out something from the staging directory. reseting its correspondig head in reference pointer.

	//after a modification, the process to add to git is the same as if it was a new file...

	//to see the differences among what is present in the working directory and the repository just type...
	git diff [the_file_to_inspect] //info on all the diff files, only the changed lines...
	//to see differences among the staging area and the repository
	git diff --staged [the_file_to_inspect]
	//to delete a file from the repository (and from the working directory), u pass throught the staging area like other times, with the command
	git rm delete1.txt //and then u can commit this change... in this case the deletion of this file....

	//to rename a file
	git mv second_file.txt secondary_file.txt //this would rename the file and add it to the staging area, in one step
	//moving and renaming here is the same
	git mv third_file.php first_directory/third_file_.php //moving and renaming at the same time..

	//before the first commit, there is nothing in the log, of course...

	//N-- in the editor, when typing
	git diff one_file.txt
	//u can type -S [enter] to be able to see the whole line in the screen, in those cases where the lines are too long...
	//to toggle back... just do the same...
	git diff --color-words contact.html //this one, instead of giving u the diff in two lines, points incolors the differences.. great!
	//* giving differences from this commit to the present...
	git diff ac1d2c4

	//commiting directly from the working directory... its only good if u want to put everything present in the working directory in git
	//and if u are adding modifications only... it doesnt work well with new files or adding deleted files...
	git commit -am "change the phone 24 hours number to 4314"
	//
	git add tours/ //its going to add everything inside this directory...
	//N-- its desirable to make connected commits, and not mix them... in every commit a problem solved or a bug or a fix or an addd.. but all of them related stuff

	git checkout -- index.html // git checkout index.html would work, but this double dash is to specify that we are not talking about a branch...
	//it could work git checkout index.html, but its a good practice to use the '--'
	//'--' => we are talking about a file in the current branch
	git checkout HEAD~3 //bringing the commit tree three iterations in the past
	git checkout master //to return to the prior state, the most recent commits on top...
	//to unstage some file
	git reset HEAD <file> //reset the this file to the head last commited related to it...
	//it is possible to correct a previous commit (only the last one)... if u forget somethig that is supposed to be in the
	//last commit or by the contrary, should not be there, then u just put it in the stage [git add/rm <the file>]
	//then u make u can do changes in the message with similar procedure
	git commit --amend -m "the same message" //or a different message ... if empty is going to assume the same message
	//in git u can use the SHA number to revert to an old state.
	git checkout 538694702ccb -- forth_file.txt //in this example we are bringing back the file forth_file.txt to the state it was in 538694702ccb correspondig.
	//after performing this operation, of course, there will be differences between the version in the working directory and the repository
	//that's why git puts in stage ready to commit, this roll-back, to make it permanent as it could make sense.
	//for a quicker procedure (nothing pop to the stage area for confirmation.. etc), we use:
	git revert 538694702ccb //we pass the log SHA that we weant to completely revert. Its going to do a mirror on that commit.


	//N-- git reset ->chnges the repository to the point u ask git to and:
	// --soft
	//does not change staging index or working directory
	// --mixed
	//changes stage index to match repository
	//does not change working repository
	// --hard
	//changes staging and working directory index to match repository
	git reset --soft ac1d2c4abd0f267cb82e0c78bd9ac4dd14167351 //it puts the head in this point..
	//this kind of things is a good idea for example.. if u want to go back maybe three commits. doing f. instance, a reset --mixed 93432etc
	//give u the chance to have the files untouched in the working directory and in the point u want in the past in the repository
	//this would allow u to re-commit this in the desired way...
	git reset --mixed ac1d2c4abd0f267cb82e0c78bd9ac4dd14167351


	WD: working directory
	SI: stage index
	R: repository

	git log -> A, B, (C) //C pointed by HEAD
	//assuming u git reset to B

	WD SI R
	--soft C C B

	--mixed C B B

	--hard B B B

	//resuming u can pass from --mixed to --soft adding the differences to stage...
	//u can do a reset to a future version too...

	//all of these resets, gives u the chance to go back to the "abandoned", to the "erase" data. If u have the SHA of the dumped commits then you
	//can go to this stage doing the same
	git reset --hard [the_last_commit_again] //and u will have it again in u r git repositories...
	//But if u write some new commit after the reset, then these old commits are going to be completely LOST...

	//removing untracked files... (not in the repository and not in the staging index)
	git clean -f

	//using .gitignore to stop tracking files.. inside the .gitignore file u can write several rules, causing to ignore those who match these
	*.php
	!index.php
	resources/ //and some other rules u would search if u need them..
	//---> this two addresses are interesting...
	https://help.github.com/articles/ignoring-files
	https://github.com/github/gitignore
	//to add a general gitignore file...
	git config --global core.excludesfile /Users/Richard/.gitignore_global
	//to stop tracking a file, already in the repo...
	git rm --cached <file_name> //u have to additionally put it {the file} in the .gitignore file....
	//git is designed to trck files... so when a directory is empty, by default is not going to be tracked...
	//in order to fix this, the comunity usually creates an empty file inside the directory {by convention .gitkeep}, so that u could add it to repository...

	//referencing commits
	//u can do it by the SHA, the parent, the HEAD
	acf54cj12ds^, HEAD^ //referencing the parent
	HEAD~1 //the same... the # is how many ancesters going up to search
	HEAD^^, HEAD~2 //the grandparent
	//-->
	git ls-tree HEAD //prints out the content of the commit in this point..
	git ls-tree master //the same thing since this is the branch we are working in
	git ls-tree master first_directory/ //accessing to the tree inside a directory
	git ls-tree 6e2334099352b476048f08061ad5664680b33f34 //this SHA corresponds to first_directory one, so it going to give the same response

	//it prints a list of the logs resumed to one line each...
	git log --oneline
	git log --oneline -3 //only the latest 3

	git log --since="two weeks ago" --until="two days ago"
	git log --since=four.days --until=two.days
	git log 53188c8..e7c3245 --oneline //from oldest to newest.. thats the order...
	git log 694e113.. secondary_file.txt //show me the changes since 694e113 till now in <secondary_file.txt>
	git log -p //detailed //*showing what happened in every log.. (details of changes on files -- all)
	git log -p 694e113.. secondary_file.txt //*changes details in this period... for this file...
	git log --stat --summary --oneline //very useful data resume (the number of "+" and "-" correspond to the amount of data added or deleted, respectively)
	git log --format=oneline //same as --oneline, but this returns the whole SHA
	git log --graph //a more visual look
	git log --format=full [fuller, short, etc]
	git log --oneline --decorate --graph --all //compact and clear log output
	git log --follow -p <file> //This will show the entire history of the file (including history beyond renames and with diffs for each change).
	//In other words, if the file named bar was once named foo, then git log -p bar (without the --follow option) will only show the file's history up to the point where it was renamed -- it won't show the file's history when it was known as foo. Using git log --follow -p bar will show the file's entire history, including any changes to the file when it was known as foo.

	gitk <file_name> //*showing graphic data from file_name, when present, and the changes related.
	git show e7c3245 //*show diff for this commit [usually the SHA comes from a git log --oneline command]
	//so, a quite handy tool is to print the ls-tree with 'git ls-tree HEAD [HEAD~3]' and then to see the content of the file or directoy use
	// 'git show [the SHA for that file or directory]'
	//it doesn't work with the filename since it doesn't know the iterations in the past this file is...


	git reset --hard //To reset every file in your working directory to its committed state
	git am

	---left in some place in the G:\09. Navigating the Commit Tree