Git Pro book

 Important points chapter wise:

Chapter 1:

• The major difference between Git and any other VCS (Subversion and friends included) is the way Git thinks about its data. Conceptually, most other systems store information as a list of file-based changes. These other systems (CVS, Subversion, Perforce, Bazaar, and so on) think of the information they store as a set of files and the changes made to each file over time (this is commonly described as delta-based version control).
• Git doesn’t think of or store its data this way. Instead, Git thinks of its data more like a series of snapshots of a miniature filesystem. With Git, every time you commit, or save the state of your project, Git basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot. To be efficient, if files have not changed, Git doesn’t store the file again, just a link to the previous identical file it has already stored. Git thinks about its data more like a stream of snapshots.
• Install latest version of git on centos and Redhat: here
• 3 levels of git config:

• [path]/etc/gitconfig file: Contains values applied to every user on the system and all their repositories. If you pass the option --system to git config, it reads and writes from this file specifically. Because this is a system configuration file, you would need administrative or superuser privilege to make changes to it.

• ~/.gitconfig or ~/.config/git/config file: Values specific personally to you, the user. You can make Git read and write to this file specifically by passing the --global option, and this affects all of the repositories you work with on your system.

• config file in the Git directory (that is, .git/config) of whatever repository you’re currently using: Specific to that single repository. You can force Git to read from and write to this file with the --local option, but that is in fact the default. Unsurprisingly, you need to be located somewhere in a Git repository for this option to work properly.

• Git help:

$ git help <verb>

$ git <verb> --help

$ man git-<verb>

Chapter 2:

• To see what you’ve changed but not yet staged, type git diff with no other arguments

• If you want to see what you’ve staged that will go into your next commit, you can use git diff --staged. This command compares your staged changes to your last commit
• More details on chapter 2.2
• git commit -a -m 'Add new benchmarks', to skip staging area
• Git remove blog, Only difference between git rm and rm is, we can reduce 1 step of adding deleted file o staging area if we use git rm <file_name>

      Moving Files

• Unlike many other VCSs, Git doesn’t explicitly track file movement. If you rename a file in Git, no metadata is stored in Git that tells it you renamed the file. However, Git is pretty smart about figuring that out after the fact — we’ll deal with detecting file movement a bit later.

  Thus it’s a bit confusing that Git has a mv command. If you want to rename a file in Git, you can run something like:

  $ git mv file_from file_to

  and it works fine. In fact, if you run something like this and look at the status, you’ll see that Git considers it a renamed file:

  $ git mv README.md README
  $ git status
  On branch master
  Your branch is up-to-date with 'origin/master'.
  Changes to be committed:
    (use "git reset HEAD <file>..." to unstage)
  
      renamed:    README.md -> README

  However, this is equivalent to running something like this:

  $ mv README.md README
  $ git rm README.md
  $ git add README

  Git figures out that it’s a rename implicitly, so it doesn’t matter if you rename a file that way or with the mv command. The only real difference is that git mv is one command instead of three — it’s a convenience function. More importantly, you can use any tool you like to rename a file, and address the add/rm later, before you commit.


Undo changes summary:
local repo(commit) -- If u accedentally missed some files to commit and wanted to add few file to the last commit msg instead of creating another commit, use this:

git commit --amend

stage --> working dir

git restore --staged <filename>

git reset HEAD <filename>

working dir --> discard changes

git restore <filename>

git checkout -- <filename>


Very very important:

If you only ever rebase commits that have never left your own computer, you’ll be just fine. If you rebase commits that have been pushed, but that no one else has based commits from, you’ll also be fine. If you rebase commits that have already been pushed publicly, and people may have based work on those commits, then you may be in for some frustrating trouble, and the scorn of your teammates.

Git workflow: Integration mannager workflow