Ah, back after a veryyyy long time.Well, guess I could be more regular now.
Okay then back to the blog.

Table of Contents:

1.Staging
2.Making Commits
3.Reverting
4.Forking
5.Branching
6.Merging and Conflicts
7.Fetching/Pulling Changes
8.Pushing Changes
9.Rebasing

How Does Git Work?

Git is a flexible tool that allows developers to track code changes and manage their project using simple commands via the terminal.

The heart of Git is a repository used to contain a project. A repository can be stored locally or on a website, such as GitHub/Gitlab/Bitbucket. Git allows users to store several different repositories and track each one independently.

Throughout development, the project has several save points, called commits. The commit history contains all the commits, i.e., changes implemented in the project during development. A commit allows you to roll back or fast forward the code to any commit in the commit history.GitHub uses .patch and .diff

files to compare and apply changes.Git uses SHA-1 hashes to refer to the commits. Each unique hash points to a particular commit in the repository. Using hashes, Git creates a tree-like structure to store and retrieve data easily.

The files in each Git project go through several stages:
Working directory. Modified files, but untracked and not yet ready for commit.
Staging directory. Adding modified files to the staging environment means they are ready for commit.
Committed. Snapshots of files from the staging area saved in the commit history.
The following diagram shows the basic Git workflow:

1.Staging:

When you want Git to track changes you've made to a certain file, you must add it to the staging area. Git recognizes when you modify a file but doesn't track it unless you stage it. The staging area represents a layer of security, allowing you to review the changes before committing them.

Being in the staging area is a prerequisite for files to be later committed, i.e., implemented on the master branch. You can check which files Git tracks by running:

git status

To add a file to the staging area, use the following syntax:

git add [filename]

Replace the [filename] syntax with the actual name of the file.
If you change your mind, you can remove a file from the staging area. To unstage a file, use the following syntax:

git rm --cached [filename]

2.Making Commits:

A commit represents a save point for your work, a snapshot of your code at a particular point in time. Adding files to the staging area means that they are ready to be committed.

To check if you have any files ready to be committed, run:

git status

Here we see that three files are ready for commit. To commit them, use the following syntax:

git commit -m "Notes about the commit"

Each commit should have a small description specified after the -m flag, which will later help you know what the commit was about.

The output contains the commit and states what was changed.

You can check your commit history by running:

git log

3.Reverting:

If you have made mistakes during your project development or want to revert a commit for any reason, git revert allows you to do so.The git revert command reverts a particular commit, i.e., undoes the commit you made to remove the changes from the master branch.
The syntax is:
git revert [commit_ID]
The git reset command permanently takes you back to a certain point in development. All the files and changes added after that point in time are unstaged if you want to re-add them.

Warning: Use git reset only if you are entirely sure you want to undo/delete parts of your code, as this action is irreversible.

The syntax is:
git reset [commit_ID]
Specifying the --hard flag removes the unstaged files, making it impossible to bring them back.

4.Forking:

A fork is a complete copy of an existing repository that allows you to make changes and experiment without affecting the original project. Forking is a way for someone to propose changes to an existing project, or it can be a starting point for a project of your own if the code is open source.

If you want to propose a change or a bug fix for a project, you can fork a repository, make the fix, and make a pull request to the project owner.

The following diagram illustrates how forking works:

To fork a repository, follow the steps below:

1. Sign in to your GitHub/GitLab account.
2. Visit the repository page on GitHub and click the Fork option.
3. Wait for the forking process to complete. When it finishes, you will have a copy of the repository on your GitHub account.
4. The next step is to take the repository URL from the Code section and clone the repository to your local machine.
5. Clone the repository using the following syntax: git clone [repository URL] Enter the URL in place of the [repository URL] syntax.

5.Branching:

Branching is a feature in Git that allows developers to work on a copy of the original code to fix bugs or develop new features. By working on a branch, developers don't affect the master branch until they want to implement the changes.

The master branch generally represents the stable version of your code, which is released or published. That's why you should avoid adding new features and new code to the master branch if they are unstable.

Branching creates an isolated environment to try out the new features, and if you like them, you can merge them into the master branch. If something goes wrong, you can delete the branch, and the master branch remains untouched.

Branching facilitates collaborative programming and allows everyone to work on their part of the code simultaneously.

The following diagram is a visual representation of branching in Git:

The syntax to create a new branch in Git is:
git branch [branch-name]
Enter a name for your branch in place of the [branch-name] syntax.

6.Merging and Conflicts:

The git merge command allows developers working on a new feature or a bug fix on a separate branch to merge their changes with the main branch after they finish. Merging the changes means implementing them into the master branch.
The developers can input their changes using git merge without having to send their work to everyone working on the project.
To see your existing branches, run:
git branch -a
See your existing branches in Git.
For this tutorial, we have created a separate branch named feature-1. To merge the feature-1 branch with the master branch, follow the steps below:

1. Switch to the master branch. The git merge command requires you to be on the merge-receiving branch. Run the following command to switch to the master branch: git checkout master
2. After switching to the master branch, use the following syntax to merge your changes: git merge [branch-name]

Enter the name of your branch in place of the [branch-name] syntax.
Merging a branch into the master branch.
Git automatically inputs your changes to the master branch, visible to anyone working on the project.
However, sometimes you may come across merge conflicts.
For example, a conflict occurs if someone decides to make edits on the master branch while you’re working on another branch. This type of conflict happens because you want to merge your changes with the master branch, which is now different from your code copy.

7.Fetching/Pulling Changes:

The git fetch and git pull commands are both used to retrieve changes from the remote repository.
The difference is that git fetch only retrieves the metadata from the remote repository but doesn't transfer anything to your local repository. It only lets you know if there are any changes available since your last pull.
In the following example, git fetch informs us that there are some changes in the remote repository, but nothing has changed in the local repository

Running git fetch to see if there are available changes remotely.
On the other hand, git pull also checks for any new changes in the remote repository and brings those changes to your local repository.
So, git pull does two things with one command - a git fetch, and a git merge. The command downloads the changes made to your current branch and updates the code in your local repository.

8.Pushing Changes:

The git push command does the opposite of git pull, allowing you to share your changes and publish them in the remote repository.

When you make changes locally and want to push them to a remote repository, run:

git push

If you have created a new branch locally, which doesn't exist remotely, the command returns an error when trying to push the changes:

Error when pushing a branch that doesn't exist remotely.
Git offers the solution in the output. Run the command specified in the output to push your branch upstream:

Pushing a branch upstream in Git.

9.Rebasing:

When you create a branch, Git creates a copy of the existing code for you to further develop. Sometimes you may need to incorporate new changes from the master branch to keep up with general development.
Rebasing involves implementing new changes from the master branch into your feature branch. That means that Git replays the new changes from the master branch, creating commits on top of the tip of your feature branch.

Follow these steps to rebase your feature branch:

1. Move to the feature branch using git checkout. The syntax is: git checkout [branch-name]
2. Run the following command to rebase your branch: git rebase master