Introduction

Git is a powerful and widely used tool for managing source code and tracking changes over time. Whether you're a software developer or just someone interested in learning more about version control, understanding Git is an essential skill.

In this blog, we'll take a deep dive into Git, exploring its features, commands, and best practices for managing code. We'll cover everything from the basics of Git's architecture to more advanced topics like branching and merging.

To illustrate the importance of Git

let's start with a story about an organization that began building a product. Initially, the development team worked on their respective parts of the project and stored changes on their local machines. However, as the project grew in size and complexity, it became increasingly difficult to manage changes, track versions, and collaborate effectively.

Here are a few probs we had with our code:

1. It was hard to keep track of who was working on what version of the code.

2. We couldn't see what changes other team members were making, which made things tricky.

3. We ran into conflicts when multiple people tried making changes to the same file.

4. If we had to fix something, it was tough to go back to an earlier version.

These problems highlight the need for a version control system like Git, which enables developers to collaborate on projects more effectively. In the upcoming sections, we'll explain version control systems, branching, merging, and other Git concepts in detail.

Git

Git is a widely adopted distributed version control system used by many organizations to manage their codebase effectively. With Git, developers can collaborate seamlessly and track the history of their code changes, enabling them to revert to earlier versions if needed. Its powerful versioning capabilities allow for efficient management of large codebases, making it a go-to tool for developers worldwide.

You Might Wonder What is Distributed Version Control System.

Let’s See what is that

Version Control System

In a VCS, each version of a file is stored as a snapshot, along with metadata such as the author, date, and message describing the changes made. This allows developers to see what changes were made when they were made, and by whom.

Type of Version Control System

Centralized VCS :

Centralized VCS, as the name suggests, stores all the code in a central repository. Developers can check out code from the repository, make changes, and check it back in when they're done. Examples of centralized VCS include Subversion (SVN) and CVS.

Distributed VCS :

Distributed VCS, on the other hand, allows developers to create their own local repository, which they can use to work on code independently. They can then push their changes to a shared repository, where other developers can review and merge those changes. Git is an example of a distributed VCS.

Git and GitHub are Not the Same

Let's consider the analogy of email services, which allow us to exchange messages through platforms such as Gmail, Outlook, Yahoo Mail, and others. Similarly, Git is a powerful version control system that enables developers to track and version their code. Git can be hosted on popular platforms such as GitHub, GitLab, BitBucket and many more. In simple terms, Github is a web host platform for Version Control Systems like Git.

Git Hub

GitHub is an online platform where developers can store and manage their code repositories. It provides version control, issue tracking, and collaboration tools to help developers work together effectively. With GitHub, developers can create and contribute to open-source projects, track code changes, and collaborate with others to build software. It also offers features like wikis, code review tools, and project management tools to help teams build better software

Git Architecture

Working Directory

A working directory is also known as a Working tree. The working directory is the directory where the actual work is being done. It is the place where files are edited, created, and deleted. When you clone a repository or checkout a branch, Git creates a working directory that contains a copy of the current state of the project. Git tracks any changes made to the files in the working directory. When a file is added to the working directory, it is considered untracked by Git until it is staged

Staging Area

The staging area acts as a buffer between the working directory and the repository. When we stage our changes, Git takes a snapshot of the changes and stores them in the staging area. it allows us to control what changes we include in each commit. This is particularly useful when working on larger projects where multiple changes may be made in the working directory, and we want to commit only a specific set of changes.

Repository

Once you have staged your changes, you can commit them to the repository. The repository is where all changes are stored, along with the history of those changes. Each commit creates a snapshot of the state of the files in the repository at that point in time. In the short term, a Repository is just a folder, that stores all the information about the code base.

Now You Understand Git and It’s Workflow. To work on the process, You might know the Git Commands, Let deep dive into it.

Basic Git Commands

git init

git init command is used to create a new Git repository in your local machine. It creates a .git file in the sub-directory in the root directory of your project and it contains all the necessary files to maintain your repository.

git init

git clone

git clone command is used to download the existing remote repository to your local machine. This will be helpful when you want to contribute to open source projects or work in any organization.

For Example,

If you want to work on Twitter, you go to GitHub and just copy the URL link and clone the exact copy and work on your machine

git clone [url]

git add

git add command is used to add changes made to files in the working directory to the staging area. This command is used to track new files, modified files, and file deletions.

For Example,

A .txt file in the working directory, it is an untracked file by git. you want to add the untracked file to the directory using git add command.

To add specific untracked file

git add [file]

To add all the untracked files

git add .

git status

git status command used to display the current status of the working directory and staged area of the repository.

For Example,

You add untracked files and want to know if it is added or not in the working directory. By using git status listed the untracked and staged files in the directory.

git status

git branch

git branch command is used to create a separate branch within a repository. This feature is crucial for collaboration among multiple developers who may work on different parts of the same project simultaneously

For Example,

if two developers are working on the same project, one may be tasked with fixing a bug while the other may be developing a new feature. Creating separate branches for each developer enables them to work independently without affecting the main branch of the repository.

To create a new branch in the repository

git branch [branch-name]

To delete a branch in the repository

git branch -D [branch-name]

To rename a branch in the repository

git branch -m <old-branch-name> <new-branch-name>

git checkout

git check out is used to switch between different branches in a repository. It allows you to switch to a branch where you can make changes and commit them. You can also use git checkout to switch to a previous commit to view the repository's state at that time.

For Example,

Let's say you are working on a project and need to switch to a different branch to work on a new feature or fix a bug. You can use git checkout to switch to that branch. For example, if you have a branch called new-feature, you can use the following command to switch to that branch: git checkout new-feature.

To switch branch from one to another.

git checkout [branch-name]

To checking out a previous commit. For Example, what your project looked like two commits ago

git checkout HEAD~2

To Discard the changes in Current directory

git checkout — [branch-filename]

git stash

Git stash is a powerful command that allows you to temporarily save your changes and remove them from the working directory without committing them. This is useful when you need to switch branches or work on a high-priority bug fix without losing your current changes.

For example, let's say you are working on a new feature branch, but your team reports a high-priority bug that needs to be fixed immediately. Instead of committing your changes, you can use git stash to save your current changes and then switch to the main branch to work on the bug fix.

Once you have fixed the bug, you can switch back to your feature branch and use git stash apply to retrieve the changes you saved earlier. This allows you to resume work on your feature branch without losing any progress.

To save temporarily changes in working directory.

git stash

To retrieve the stashed changes and restore them to your working directory.

git stash apply

To apply and remove the most recently stashed changes from the stash list.

git stash pop

git commit

git commit command is core part of git feature. To use this command you can take the snapshot of codebase's current state and track changes made over time. It have a SHA-1 hash to identify the specific commit.

For example,

Suppose you're working on a project with a team of developers. You've made some changes to a file, and now you want to commit those changes to the repository and other developers can pull them down and incorporate them into their own work.

To Create a new commit with change you have staged

git commit

To Create a new commit with a specified commit message, Use flag -m for it.

git commit -m "commit message"

To modify the last commit that you made. Use flag —amend for it.

git commit --amend

To Creates an empty commit with no changes, it is very useful to trigger a build or deploy process, without actually making any changes to the files.

git commit --allow-empty

git log

git log command use to display a list of commits in a repository and including the author, date, and commit message for each commit.

git log

git revert

Git revert is a command used to undo a commit by creating a new commit that undoes all the changes made in the previous commit. It is used when you want to undo a commit and make it seem like it never happened and track the history of the changes.

For example,

let's say you have a repository with three commits: A, B, and C. You want to undo the changes made in commit B. Here's how you can use git revert to do that:

1. First, run git log to get the hash value of commit B.

2. Then, run git revert <commit-B-hash> to create a new commit that undoes the changes made in commit B.

3. run git log to see the new commit history with revert the commit.

git squash

git squash command used to combine multiple commits into a single, more concise commit. This is particularly useful when working on feature branches, as it helps to keep the commit history clean and easy to understand.

For example,

let's say you are working on a feature branch and have made several small commits as you work through the feature. Once the feature is complete, you can use the git squash command to combine those commits into a single commit with a clear commit message. This single commit can then be merged into the main branch, making it easier to track changes and understand the history of the code.

How to squash commit ?

Here's the process:

1. First, you need to make sure you are on the branch you want to squash the commits for. For example, if you want to squash commits on the feature-branch branch, run:

git checkout feature branch

1. Next, run the following command to start the interactive rebase process: git rebase -i HEAD~n

git rebase -i HEAD~n

1. Replace n with the number of commits you want to squash. For example, if you want to squash the last 3 commits, run:

git rebase -i HEAD~3

1. This will open up an editor with a list of the commits you are about to rebase. Each commit will be listed with its commit message and hash.

2. To squash a commit, replace the word pick with squash or s next to the commit you want to squash. The commit you want to squash should be listed below the commit you want to combine it with. For example:

pick abc1234 Commit message 1
squash def5678 Commit message 2
squash ghi9012 Commit message 3

This will combine commits 2 and 3 into commit 1.

💡 Note that git rebase -i rewrites the Git history, so be careful when using it.

Hope You Understand !.

git push

git push command used, When you make changes to your local repository, such as creating or modifying files or committing changes, you can use the git push command to upload those changes to a shared remote repository. This allows other team members to access and review your changes, and collaborate on the same codebase.

To pushes the committed changes to a remote repository.

git push <remote> <branch>

<remote> refers to the name of the remote repository.

<branch> refers to the name of the branch to be pushed.

git fetch

git fetch command used to download new commit data from remote repository to local repository. It is not affected our local changes.

For Example,

Let's say you and your team are working on a project hosted on a remote repository. You want to get the latest changes made by your team members, but you don't want to merge those changes with your local codebase just yet.

In this case, you can use the git fetch command to fetch the latest changes made to the remote repository without merging them with your local codebase.

To fetch new commit from remote repository

git fetch <remote-repository>

To fetch new commit from specific branch

git fetch <remote-repository><branch-name>

git pull

The git pull command is used to bring the changes made in the remote repository to the local repository. While git fetch command only downloads the changes but does not integrate them into the local working directory, git pull does both, fetching and merging the changes. However, it's important to note that git pull can potentially overwrite local changes that have not been committed or staged, so it's best to ensure that any local changes are saved before running the command.

For Example,

let's say you have made changes to a file called app.js in your local repository. At the same time, your team member pushed some changes to the same file to the remote repository. If you use git pull command without committing or stashing your local changes, you may lose your changes or encounter merge conflicts. it's always a good practice to commit or stash your local changes before using the git pull command to avoid any potential data loss.

To pull the changes from remote repository

git pull <remote-repository>

git merge

git merge command used to combine two branches into single branch. it is very helpful to developer work on independently and make changes on own and contribute to project.

For Example,

If you working on the feature with separate branch name called feature1 , where you have made all the changes and ready to add it with your project main branch. For this use simply git merge, this will create a new commit on the main branch that includes all of the changes from the feature branch.

To merge a target branch with main branch

git merge <target-branch>

💡 Note : This may lead to merge conflict sometime, you need to resolved it.

How to Resolve Merge Conflict ?

A merge conflict occurs when two or more branches have made changes to the same lines in a file, and Git is unable to automatically resolve the differences between them. This can happen when team members are working on the same project and make conflicting changes.

For example, if dev1 and dev2 both make changes to line 4 of the index.js file, there will be a conflict when trying to merge their changes.

To resolve Conflict follow these steps :

1. If there are any conflicts, Git will notify you of the files that have conflicts. Open the files in your code editor and look for the conflict markers <<<<<<<, =======, and >>>>>>>.

2. Resolve the conflicts by editing the files to choose which changes to keep. Make sure to remove the conflict markers once you have made your changes.

3. Stage the changes by running git add on the files you have resolved.

4. Commit the changes by running git commit.

5. Push the changes to the remote repository by running git push.

git rebase

Git rebase command used to apply changes made in one branch onto another branch. It is typically used to maintain a clean and linear history without having numerous messy merge commits.

For example,

Let's say you have two branches, feature and master. You've been working on feature, and have made several commits. Meanwhile, other changes have been made to master that you want to include in your feature branch. You can use git rebase to apply the changes from master onto your feature branch.

To rebase the current branch

git rebase <target-branch>

Difference between git merge and git rebase

git cherry-pick

git cherry-pick is a command used to apply a specific commit from one branch to another branch. It's useful when you need to bring in a particular change from one branch to another without merging the entire branch.

For example,

if a bug was fixed in a feature branch and you need that fix in your main branch, you can use git cherry-pick to bring in that specific commit instead of merging the entire feature branch.

To pick a specific commit from existing branch

git cherry-pick <commit-hash>

To pick a specify range of commits using the ..

git cherry-pick <start-commit-hash>..<end-commit-hash>

git blame

Git blame is a powerful command that allows you to see the author and commit information for each line of a file, so you can track down the origin of changes and understand the history of the code. It's a useful tool for debugging, identifying code ownership, and understanding how changes were made over time.

For Example,

Let's say you are working on a project with multiple contributors and you notice a line of code that doesn't seem to be working as expected. You want to see who wrote that line of code and when, so you can understand the context of the change and potentially identify any issues that may have arisen.

To do this, you can use the git blame command. Simply navigate to the file in question and run git blame <filename>. This will display each line of the file along with the commit hash, author, and timestamp of the last change made to that line.

You can then use the commit hash to look up the relevant commit and view the changes made to that line in more detail. This can help you identify the source of the issue and take the appropriate steps to resolve it.

To view the history of changes in file.

git blame <filename>

Conclusion

In this blog, we covered several important Git commands and concepts, including branching, merging, rebasing, cherry-picking, and squashing. By mastering these tools, you can work more efficiently and effectively, and avoid common pitfalls and errors in their development process. Git is a valuable skill for any developer to learn, and with practice and experience.

💡 Note : It's important to keep in mind that while this blog provides a basic understanding of Git, it's essential to have hands-on experience to truly become comfortable with it. With these tips in mind, you're well on your way to becoming a Git pro.