# Git in a week
## Syllabus
* Version Control System & It's Types
* Git vs Github
* Git Installation and Initial Steps
* Git workflow
* project -setup
* Github account creation and Repository creation
* Git Internals
* How to link local repositories with Remote repositories
* Git operations Implementations (push, pull, clone)
* what are branches and why we use them
* Different Branching strategies
* Merge conflicts and how to fix them
* Forking vs cloning : when to use each
* what are PRs ?
* Using issues to track bugs/features
* Undoing changes (reset, revert, checkout )
* Rewrite history (ammend, rebase)
* Git Workflows (feature, develop, release, hotfix branches)
* Git Hooks
* Advanced commands (stash, cherrypick , bisect)
* Recover a deleted branch
* Synching forked repo with upstream
* Handling large files with GIt LFS
* Interview Preparation
## day 0
Version Control System :
* Version control is a system which records changes over time for a particular file/folder/codebase to recall specific versions later.
* Version Control Systems are divided into 3 types based on their place of data storage
1\. Local Version Control System
2\. Centralised Version Control System
3\. Distributed Version Control System
1. Local version Control System : programmers long ago developed local VCSs that had a simple database that kept all the changes to files under revision control.
* RCS (Revision Control System) works by keeping patch sets (that is, the differences between files) in a special format on disk; it can then re-create what any file looked like at any point in time by adding up all the patches.
2. Centralised Version Control System : To collaborate with developers on other systems, Centralised Version Control System (CVCs) are developed.
* Systems (such as CVs, Subversion, and Perforce) have a single server that contains all the versioned files, and a no.of clients that check out files from that central place
1. Distributed Version Control System : In DVCs(like Git, Mercurial or Darcs), clients don’t just check out the latest snapshot of the files; rather, they fully mirror the repository, including its full history. Every clone is really a full backup of all the data.
* Goals of Git creation was : Speed, simple design, strong support for non-linear development (thousands of parallel branches), fully distributed, able to handle large projects like the linux kernel efficiently (speed and data size)
Git Vs Github
### How Git differs from other VCs ?
* The main difference between git and other vcs lies in it’s thinking about data.
Conceptually, most other systems store information as a list of file-based changes. These other systems (CVs, subversion and so on) think of 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 small file system. With Git, every time you commit, or save the state of your project, git basically takes picture of what all your files look like at the 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 it’s data more like a stream of snapshots\
Left Side (other VCs) Right Side (Git as a VC)
* Git stores everything in its database not by filename but by the hash value of its contents
* The Mechanism that git uses for this checksumming is called SHA-1. This is 40-character string composed of hexadecimal characters (0-9 and a-f) and calculated based on the contents of a file or directctory structure in Git.
* You can’t lose information in transit (on the way to destination) or get file corruption without git being able to detect it
* Everything in git checksummed before it is stored and is then referred to by that checksum. This means it’s impossible to change the contents of any file or directory without git knowing about it.
#### Git has Integrity :
* Everything in git checksummed before it is stored and is then referred to by that checksum. This means it’s impossible to change the contents of any file or directory without git knowing about it.
* You can’t lose information in transit (on the way to destination) or get file corruption without git being able to detect it
* The Mechanism that git uses for this checksumming is called SHA-1. This is 40-character string composed of hexadecimal characters (0-9 and a-f) and calculated based on the contents of a file or directctory structure in Git.
* Git stores everything in its database not by filename but by the hash value of its contents
#### Git Workflow :
Git has three main states that your files can reside in: modified, staged, and committed:
* Modified means that you have changed the file but have not committed it to your database yet.
* Staged (index) means that you have marked a modified file in its current version to go into your next commit snapshot.
* Committed means that the data is safely stored in your local database
The Git directory is where Git stores the metadata and object database for your project. This is the most important part of Git, and it is what is copied when you clone a repository from another computer
Git Installation →
## **Day 1**
* Git comes with a tool called git config that lets you get and set configuration variables that control all aspects of how Git looks and operates. These variables can be stored in three different places:
* * \[path]/etc/gitconfig
* \~/.gitconfig or \~/.config/git/config
* .git/config
\- Each level overrides values in the previous level .
\- git config - - list –show-origin → To view all of our settings and where they are coming
\- To set user name and email address, \`git conig - -global user.name “\”\` and \`git config - -global user.email \\`
\- To check settings \`git config - -list\`
\- By default, git will create a new branch named master when we create a new repository with git init from git version 2.28 onwards.
To set main as default branch \`git config –global init.defaultBranch main\`
* Typically, we will obtain a git repository in one of two ways :
1. You can take local directory that is currently not under version control, and turn it into a git repository or
2. You can clone an existing git repository from your local machine, ready for work
* To have a version control to our local folder is : first, we need to go to the directory which we wanted to make it under version control and then type git init then it will create a .git folder
* To clone a repository, we have to use git clone \
* \`git status\` → To check the current status of a file
* \`.gitignore\` → To ignore set of files/folders under git tracking
To see what you’ve changed but not yet staged, type \`git diff\` with no other arguments
* Git rm, git mv, git status, git log, git - - patch, git log –stat
* Git log –pretty-online
* Git reset HEAD \ → To unstage a file
## Day 2
## Day 3
## Day 4
## Day 5
## Day 6
## Day 7
## Interview Preparation
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://charan-techjourney.gitbook.io/charan-techjournal/50-days-of-devops-ecommerce-microservices/weekly-devops/git-in-a-week.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
