• Table Of Content

Version Control System

Basics

• A version-control-system records the changes made to our code over time in a special database called a repository. We can see who authored the changes, when and why, and if someone screws something up, we can always revert back to how things were. Git is the most popular VCS in the world
• It makes easier for people to collaborate, without having to send copies of their code through email and shit, which is very slow and not scalable.
• Git can be used via plugins in code editors, the terminal or using GUI tools

Configuring Git

• We can configure Git at three levels: system (settings apply to all the users), global (setting applies to all the repositories of the current user) and local (setting applies to the current repository)
• The configuration files get saved as ~/.gitconfig.

# Setting configuration globally
git config --global user.name "Rohit Dhill"
git config --global user.email "[email protected]"
git config --global core.editor "nvim"

# On Windows, end of lines are marked as \\r\\n and on Linux/ macOS \\n and this can become problematic when we have multiple collaborators using different different platforms
# On Windows, we want Git to change all end of lines to be converted into CRLF when pulling the code, and convert it back to LF when pushing the code
# On Linux, we don't want it to do anything, but change CRLF to LF if it occurs by mistake
# 
git config --global core.autocrlf true  # Window
git config --global core.autocrlf input # Linux/ macOS

Categories of Version Control Systems

<aside> 👉 Centralized

</aside>

• All the developers connect to a central server to get the latest copy of the code and to share changes with others.
• The centralized acts as a single point of failure, which on the case of failure, we can’t collaborate or save snapshots or our code.
• Example: Subversion, Team Foundation Server

<aside> 👉 Distributed

</aside>

• If the VCS is distributed in nature, every collaborator has a copy of the project with the entire history, and there’s no need for a centralized server and one can save snapshots easily.
• For the synchronization of work, a central repository is there (self-hosted or BitBucket/ GitHub/ Gitlab/ SourceHut etc).
• Example: Git, Mercurial etc.

Initializing a repository

• git init would result in a hidden sub-directory inside our directory.
• Initialization need to be performed only once or when we need to re-initialize the repository.
• Upon corruption/ removal of .git/ the entire project history will get corrupted.

**learngit@s4dr0t1:~/git/snapshots$** git init
Initialized empty Git repository in /home/learngit/git/snapshots/.git/L

Staging area

What is it?

• A special area that exists only in Git, that contains what we’re proposing to be part of the next snapshot (commit).
• The purpose of the staging area is to let us review our code before taking the snapshot
• After committing our changes, the contents of the staging area don’t get purged.

Add files to the staging area

# Add specific files to the staging area
git add file1 file2 file3

# Add all the files recursively
git add .

Show all files present in the staging area

git ls-files

Check the repository status

Untracked files means the files which are not in the staging area yet, and as a result are not yet being tracked by Git.

**learngit@blackhawk**:~/git/snapshots$   git status [--short / -s]
**XY**  .gitignore
**XY**  bin/app.bin
||
| \\->Represents the working directory
-> Represents the staging area

**learngit@blackhawk**:~/git/snapshots$ git status
On branch master
No commits yet

Untracked files:  
  (use "git add <file>..." to include in what will be committed)
        file1.txt
        file2.txt

nothing added to commit but untracked files present (use "git add" to track)

gitignore

• Git will not add the files/ folders to the staging area based on the regular expression supplied in the .gitignore file.
• .gitignore must also be added to the staging area before Git can start following the .gitignore rules.
• Git will track all the files present in the staging area even if we later add it to .gitignore. We must unstage the file first for Git to ignore it successfully git rm --cached <file>.

github/gitignore

Remove files from the staging area

# Remove the file from the disk and then update this information to the staging area
rm file && git add file

# Directly remove the files from the disk and update this information to the staging area
git rm file2 [-rf]

# Removing files only from the staging area
git rm --cached file2 [-rf] 

# Remove all the untracked files from the directory
git clean

Restore files from the staging area

# git takes restores the copy from the next environment
# If want to restore the file in the staging area, the copy will be taken from the last commit
# If want to restore the file in the working directory, the copy will be taken from the staging area
git restore <file>            # Restore from the staging area into the working directory
git restore --staging <file>  # Restore from the last snapshot into the staging area

# Restoring a file from a particular commit
git restore --source=HEAD~offset fullPath/file
git restore --source=commitIdentifier fullPath/file

# By the method of checking out
git log --oneline -- file        # Find the commit from which we want to restore from
git checkout <goodCommit> file   # Check out to the said commit
git commit -m "Restore the file" # Self explanatory

Move/ rename the files

# Rename the file and update the staging area for the deleted and new file
mv oldName newName
git add oldName
git add newName

# Doing the aforementioned thing all at once
git mv oldName newName

Diffing

# Check the difference b/w the file in our directory and the stagged file
git diff[tool]

# Show different b/w what's in our staging area and the last snapshot
git diff[tool] --staged

# Showing differences of a file b/w two commits 
git diff commitID commitID

Committing to a repository

Basics

• Committing code means creating a snapshot of all the contents that present in our staging area.
• Apart of the contents of the files, a commit also contains metadata such as the commit author, date and time of the commit, and a unique commit ID which is used to track every commit.

# Bsasic workflow
git commit -m "Meaningful message for our commit"

# Skip the staging area and commit all the changes directly
git commit -am "Fix xyz bug"

# Spawn up $EDITOR to write a larger commit message
git commit

# List all the commit authors and their commits
git shortlog

Directly commit the changes without adding anything to the staging area

# Directly commit all the staged and unstaged changes at once
git commit -a -m "Fix the bug"

Blaming

We can find out who has written a bad piece of code and basically blame them for the same.

git blame file [additionalFlags]

Tagging commits

We can create tags for certain commits and we will be able to reference those commits using the tag

git tag <tag> <commitID>

# Apart from tagging commits, we can also associate a particular message with its corresponding tag (aka Annotation Tag)
git tag -a <tag> -m "message"

# Check all the tags 
git tag

# Check all the tags and their associated message/ object
git tag -n

Good committing practices

• We shouldn’t commit every single time we make slight modifications to a file or after coding for 5 days straight, it's about committing our code when we reach a state that we want to record.
• Commit messages should be in present tense and meaningful in nature so that other people can also understand our code.
• Don't commit too many things at once, rather making one commit per issue.

Browsing history