Git Essential Training: The Basics by LinkedIn Learning

GitEssential_TheBasics.txt

# Git Essential: The Basics


* History:

1. SCSS - Source Code Control System
1972: closed source, free with Unix
Stored original version and sets of changes

2. RCS - Revision Control System
1982: open source
Stored  latest version and set of changes

SCSS and RCS only allowed to work with an individual file one at a time
3. CVS - Concurrent Versions System
1986-1990: open source
Multiple files, entire project
Multiple-user repositories

4. SVN - Apache Subversion
2000: opensource
Track text and images
Track file changes collectively

5. BitKeeper SCM
2000: closed source, proprietary
Distributed version control
Community version was free.
Used for source of the Linux kernel from 2002 o 2005.
Controversial to use proprietary SCM for an open-source project
April 2005: community version stopped being free.

6. Git
April 2005, created by Linus Torvalds
Replacement for BitKeeper to manage Linux kernel source code.
Distributed Version Control
Opensource and free software.
Cross platform
Faster than other SCMs
Better safeguards against data corruption.

------------------------------------------------------------------------------

* Distributed Version Control

Different users maintain their own repositories.
No central repository
Changes are stored as change sets
Track changes, not versions
Different from CVS and SVN, which track versions
Changed sets can be exchanged between repositories
"Merge in change sets" or "Apply patches"
No need to communicate with a central server
Faster
No network access required
No single point of failure
Encourages participation and forking of projects
Developers can work independently
Submit change sets for inclusion or rejection

------------------------------------------------------------------------------
* Git Configuration

System
/etc/gitconfig
Program Files\Git\etc\gitconfig

User 
~/.gitconfig
$HOME\.gitconfig

Project
myproject/git/gitconfig


* Commands:
System:
> git config --system

User 
> git config --global

Project
> git config
> git config --global user.name "Sonu"
> git config --global user.email "someone@example.com"
> git config --list
> git config user.name
> git config user.email

* to look gitconfig
cd ~
find .gitconfig file and check it's details

* To set editor
> git config --global core.editor "VSCode --wait"

* to set color
> git config --global color.ui true

* to unset
> git config --global color.ui false

------------------------------------------------------------------------------
* Git auto-completion
These instructions are for mac and linux only

1. github.com/git/git
2. contrib directory
3. completion directory
4. find the autocomplete script (git-completion.bash)
5. Copy the file and save it in your pc
6. Make a copy of the file as: mv git-autocompletion.bash .git-completion.bash

Modify the bash profile or bashrc, and paste the following code, save the file.
```
#Edit ~/.bashrc or ~/.bash_profile

if [-f ~/.git-completion.bash ]; then
source ~/.git-completion.bash
fir
```
7. Close the terminal and open a new one. The script runs now.


* Git help
> git help

> git help log or man git-help


------------------------------------------------------------------------------

> git init

* Where git files are stored: Inside .git folder

> git add .
> git commit -m "Message"

* Commit message best practices
1. Short single-line summary (less than 50 chars)
2. Optionally followed by a blank line and more complete description.
3. Keep each line to less than 72 characters.
4. Write commit messages in present tense, not past tense.
"Fix for a bug" and not "Fixed a bug"
5. Bullet points are usually asterisks or hypens
6. Can add tracking numbers from bugs or support requests
7. Can develop shorthand for your organization [xss] bug fix, [js]
8. Be clear and descriptive.
Example: ghi2394 - Fixes bug in admin logout

When an admin logged out of the admin area, they
could not log in to ... something like this.


* View the commit log

Every commit is given a unique commit id.
If we run git log before making any commits, it results to fatal saying your current branch master doesnt have any commit.

> git log
This gives the list of the logs


> git log -n 5
The above gives 5 recent commits

> git log --since=2019-01-01
The above gives all commit after Jan 01, 2019

> git log --until=2020-01-01
Gives all the commit until Jan 01, 2020


> git log --author="Sonu"
Gives all the commit made by the author

> git log --grep="Bug"
The above command gives all the commits with the commit message which contains the word Bug

------------------------------------------------------------------------------
* The three trees
_______________
| repository   |
----------------
_______________
| staging index|
----------------
_______________
| working	|
---------------


* Git workflow
Working -> Staging Index -> Repository

* Hash Values (SHA-1)
-> Git generates a checksum for each change set
-> Checksum algorithms convert data into a simple number
-> Same data always equals same checksum
-> Data integrity is fundamental
-> Changing data would change checksum
-> Git uses SHA-1 hash algorithm to create checksums
-> 40 character hexadecimal string (0-9 a-f)
-> it uses the metadata [parent, author, message]

* The HEAD pointer
Pointer to tip of the current branch in repository
Last state of repository, what was last checked out
Points to parent of next commit where writing commit takes place.


Commit A -> Commit B -> Commit C
Here HEAD points to Commit C
And Master is at A

------------------------------------------------------------------------------

* Making changes to file
> git add .
> git add filename.txt
> git commit -m "Initial commit"

* View changes with diff
> git diff
By default, git diff compares the working directory against the staging tree.

* View only staged Changes
> git diff --staged
The above command will show the changes between staged and the committed version 
> git diff --cached
The above one shows the same result as --staged

> git diff --color-words
Colors only the changed words instead of the sentences

* Delete files
> First approach would be delete the file and then type
> git rm filename.txt
followed by committing the changes.

Else, we can combine two steps by simply 
> git rm filename.txt
we don't need to manually delete the file, git does that for us.


* Renaming files

We manually change our file name from file1 to file2, and if we check git status it shows the following:
file1 is deleted 
file2 is untracked

Now, if we add the file2 and rm file1 using: git add file2; git rm file1
Now, check the status, it would say the following:
renamed: file1 -> file2

Instead we can use the following commands to rename:
> git mv file1 file2

Here, git understands that file1 is renamed to file2

* To unstage a file
> git reset HEAD file.txt

* Stage and commit shortcut
> git commit -a
> git commit -all
Stages and commits all changes to tracked files
Does not include untracked files
> git commit -am "Message"

* View a commit
> git show [sha-hash]

* Compare two commits
> git diff [sha_hash of commit x]..[sha_hash of commit y]
> git diff [sha_hash of commit x]..HEAD

* Multiline commit messages
> git commit -a
a editor opens: Type the message and save it.

> git log --oneline
This gives one line commit lines.


* Atomic commit
-> Small commits
-> Only affect a single aspect
-> Easier to understand, to work with, and to find bugs
-> Improves collaboration
First add the files which are related, once it is moved to staging area, commit those.
Followed by the other/remaining files.

------------------------------------------------------------------------------
* Undo working directory changes
> git checkout -- filename
The -- tells git to not change the branch and look in the master branch itself.(or maybe the current one, not sure)
or
> git restore filename

* Unstage files
> git reset HEAD filename.txt
THe above command unstage the file filename from staging area to working area
or use the below command
> git restore --staged filename.txt

* Amend Commits
> git commit --amend -m "The commit message"
The above command takes whatever is in the latest commit, bring it down, add whatever is in the staging area, and commit it back

* Retrieve Old Versions
-> Git only allows amending the most recent commit
-> Edits which undo changes would be new commits
-> Maybe helpful to retrieve an old version of a file

Do git log and find to which point of commit you want to go and note the commit id.
> git checkout [commitID] -- filename.txt

The changes that were present in the filename.txt at that commit, that changes will be applied in the filename.txt and it will be staged.

If you want to keep that changes, commit it. 
If you want to reset it to the latest commit of what it was before moving to that commit id, do the following
> git reset HEAD filename.txt


* Revert a commit
git revert [hash_CommitID]

* Remove untracked files
> git clean -n
The above command does a dry run and tells what would be deleted.
git clean only flushes from the working directory and doesn't delete from the staging area.

If you're sure to remove those files. Do the following
> git clean -f
It force deletes the untracked files.


------------------------------------------------------------------------------

* Ignore files

*.gitignore
Create a file .gitignore and add the filenames, or patterns of file which you want to ignore.


* Ideas on what to ignore
1. Compiled source code
2. Packages and compressed files
3. Logs and databases
4. OS generated files
5. User-uploaded assets (images/PDFs/videos)
https://github.com/github/gitignore
Go to above link and see what are the files you want to ignore

* Globally ignore files
Ignore files in all repositories.
Settings are not tracked in repositories.
User specific instead of repository specific.

We would always want to ignore some specific set of files for all projects, we can globally ignore files in that case.
> git config --global core.excludesfile ~/.gitignore_global
Good practice is store this file in your User repository


* Ignore tracked files
.gitignore is only applied to untracked files.

To achieve, we do the following
Assume filename.txt is already commited.
> git rm --cached filename.txt
> git commit -m "Stop tracking"
Add the filename to .gitignore, now it should stop tracking filename.txt
git rm --cached doesn't delete from the physical directory, instead removes from the cache.


* Track empty directories.
1. Git is designed to be a file tracking system.
2. Track files.
3. Tracks the directories it takes to get to files.
4. Ignore directories with no files.
To achieve this add a .empty file in that empty directory