git 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 = [email protected]
        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 "[email protected]"

//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