Why we write another guide?

We write another because we need to help ourselves to really understand how Git works and what it can do for us, we need a slightly deeper understanding.

Let me put it in this way my dear readers I and my friend we decide to draw a picture together on a paper for school homework. We meet in the library and makes two photocopies of what we have started and we both take a copy home this is pulling. We both add more things to the drawing and when we come back to school tomorrow, we cut and pastes the bits we changed and then photocopies that change this is merging. If we both erased the same area, someone has to choose which portion to use this is resolving a conflict. And since there are photocopies every time something is changed, I can throw away all the new ones if I don’t like what I have done this is resetting. And if we don’t like what we have done so we can burn all the new photocopies and this is reverting.

Let’s move to the Git perspective. With a system like Git, I would first create the file on the Git server, and add changes. Then, I commit those changes to the repository. Then, my friend starts pulling the latest changes. He adds some stuff, then commits to the repo. The repo says this file exists and is different from the previous version, so we will save it as version 2. So on and so forth. The Git repo allows us to make edits and keep the changes sort of sequential, so if I deleted something at some point, I can say, Git, check out the point before and I can get back to fixing my stuff.

If you want to make free money and have a blog like this one using our platform then sign up with this referral link of digital ocean platform if you don’t like money forget it, my friend.

Each commit has an owner, so we know who did what. And I can compare Version Beta to Version Alfa, and see what has changed, making it easier to spot what new changes have been made.

Git also allows me to create branches. So we are on version 17 of the doc, but I want to try something new. My friend wants to continue, so I create a branch called MiTesoro and start working on that. This is now a separate path of the code, while my friend continues on the original, which is usually considered the master. So Git basically lets multiple people access a central piece of what is usually code, and make alterations to it without stepping on someone’s toes.

What is Git?

Git is a mature, actively maintained open source project originally developed in 2005 by Linus Torvalds, the famous creator of the Linux operating system kernel. An astonishing number of software projects rely on Git for version control, including commercial projects as well as open source. Developers who have worked with Git are well represented in the pool of available software development talent and it works well on a wide range of operating systems and IDEs (Integrated Development Environments). After this technical introduction, let’s jump to explain several words about the vocabulary of Git.

What is Branching in Git?

In Git there are three branches of interest, local branch, remote branch and tracking branch they might all be pointing to different commits:

  1. The branch named master in the local repo. This is where we do our work and make our commits. This is the local branch. It is at the lower left in the diagram below.
  2. The branch named master in the remote repo. This is the remote branch, at the top of the diagram below. We cannot normally see this at all because it is typically on another computer and requires a network operation to interact with it.
  3. The branch named origin/master in the local repo. This is the tracking branch, at the lower right in the diagram. We never modify the tracking branch ourselves. It is automatically maintained for us by Git. Whenever Git communicates with the remote repo and learns something about the disposition of the remote master branch, it updates the local branch or origin/master to reflect what it has learned.

Understanding branching in Git.

What are the states of Git?

Read this carefully my dear friend. This is the main thing to remember about Git if you want to accomplish good learning results in Git. Git has three main states that your files can reside in: committed, modified, and staged. Committed means that the data is safely stored in your local repository this the end result of git commit. Modified means that you have changed the file but have not committed it to your database yet. Staged means that you have marked a modified file in its current version to go into your next commit snapshot this is the end result of git add.

Different states of Git.

What are the areas of Git?

The Git directory which is your local repository 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.

The working directory is a single checkout of one version of the project. These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify.

The staging area is a simple file, generally contained in your Git directory, that stores information about what will go into your next commit. It’s sometimes referred to as the index, but it’s becoming standard to refer to it as the staging area.

What is the basic workflow?

The basic Git workflow goes something like this:

  1. You modify files in your working directory.
  2. You stage the files, adding snapshots of them to your staging area.
  3. You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory.

Types of areas inside Git.

So I hope you enjoy our article because in the next stories we will talk about the basic operations of Git, and differences between revert and reset, pull and fetch, merge and rebase, the different workflows of Git, and how to solve a merge conflict.

Thanks for reading. If you loved this article, feel free to hit that subscribe button so we can stay in touch.