What You Should Know to Start Working with Git

When people encounter Git for the first time, they often struggle to understand how Git works. It seems so abstract, and most tutorials on the internet only suggest that you run some Git commands to achieve a specific result. However, most Git tutorials use a plethora of new words without actually explaining what those words mean. Even the official Git documentation isn’t the best place to start learning Git.
Here, we’ll describe the following Git concepts – those new words you will want to know to get started with Git:

• Git commands
• Git local and remote repositories
• Git staging area
• Git commits
• Git branches
• Forking, cloning, pushing, and pulling

Once you understand the basic Git concepts listed above, you’ll be able to move further and further learning Git on your own.

What’s Git?

Long story short, Git is a version control system.

When you start developing and changing a project, you often rework different parts of it and switch back and forth between project states. In short, you’ll create and manage project versions.

If you try to handle project versions on your own by copying project files to different folders and restoring files from them, you’ll quickly face the challenge of managing multiple folders and not knowing which one holds the project version you want. Besides, web development team members often work on the same files. Therefore, you’ll merge two or three of the same file with different code. Reading code lines one by one isn’t the most convenient approach to merging two or more files created by you and your friends.

Git as a version control system helps us much more easily manage different project versions, track who made changes and when, and restore project files.

Let’s now move on to the basic Git concepts.

What are Git commands?

Since Git is software, you’ll need an interface to use it. Once you install Git, you’ll be able to run Git commands from the terminal.

The Git commands are a means of communicating with Git. You can also consider Git commands as buttons by which you can ask Git to do something in your project. All Git commands start with the “git” keyword and include the following parts: secondary keywords, options, and text messages. For example, if you run “git commit -m ‘Add first commit’”, you use the “git” keyword, “commit” as a secondary keyword, “-m” as an option (message) and “Add first commit” as a text message. There are many Git commands you’ll have to master, but it’s best to start with the most basic commands.

What are Git repositories?

If you have ever used an operating system on your smartphone (bar iPhone), PC, Mac, smart TV, or tablet, you’ve see files in the filesystem. Various files are grouped by directories (folders).

The Git repositories are also directories where Git stores snapshots of your project files. A repository is a hidden directory located in a project’s root folder. When you run “git init” to create a local repository for your project, you actually create a hidden directory for Git. And remember: each project must have an individual local repository.

A repository is called local when it’s stored on your computer. But how do you share code with other people in the team? You’ll use a remote storage, such as GitHub, where a Git directory with snapshots of your project will be located. A repository that’s stored on a remote computer is called, expectedly, a remote repository. The most famous remote repositories, besides GitHub, are GitLab and Bitbucket.

I’ve heard about the Git index and staging area. What are they?

Git works in this way: it creates a lightweight representation of project files from the root directory and all subdirectories and stores it in the repository.
But does Git copy an entire project to the repository each time you move files to a repository (commit to a repository)? Actually, Git doesn’t do that. There’s no point in copying all project files when only several files were changed.
Git lets you be very specific about committing to a repository. You can move only the files that were changed.

But how does Git know which files those are? It uses the staging area! If you imagine a repository and the project root directory as two bowls, the staging area would be a third bowl located between the repository and root folder.
Say, you’ve created several files in the root directory. Before you can move them to the repository, you should prepare the files. You take a file from the first bowl and copy it to the staging area. When you’re ready to store files in the repository, you move files from the staging area to the third bowl – a repository.

The staging area in Git allows you to prepare and organize files that you want to commit to the Git repository.

Now tell me about Git commits

Git commits are actions that mean “you move copies of project files to the Git repository.” Each commit allows you to register the fact that files were changed and actually transfer files to repository. Git commits must always be extended with a message that describes what a commit does. Git also adds your name, date, and a unique identifier to commits. Eventually, you’ll be able to follow the history of all commits. This is especially useful when you want to find out who broke the app.

What are Git branches?

If you want to know the true power of Git, you should understand what Git branches are. Branches are necessary to store various versions of the same project on the same repository. When you create a new project and initialize a Git repo in that project, Git automatically creates a branch and calls it “master.”

A master branch would be the chief river in which your main code flows. Branches are smaller water channels that initiate from the master branch to run in parallel. These smaller channels run the same water and generally connect with the chief channel.

The master branch can be used to store a live, working app version. Other branches, such as a development or testing branches, are used to store other app versions. Developers create other smaller branches from development and testing branches to make small changes in the project.

When you need to create a new feature, you should instantiate a new branch from the development branch and switch to the new branch. Once you’ve added the new feature, you switch back to the development branch and merge branches. Then you switch back to the master branch and again merge the new code from the development branch.
Branches are necessary to store different versions of a project and to develop new features without breaking the previous app version.

I also want to clone and fork with Git

If you want to have a remote repository on your computer, you can clone a remote repository. When you clone, you create a one-to-one version of the remote repository. The project will be absolutely identical, only located in two different places.

Git has a special command, “git clone”, to create Dollies of online projects and store them on a computer.

Forking repositories means you clone a project online. Say you have a GitHub profile. When you visit any project, you can clone a project to your computer using terminal and running a necessary Git command. But when you clone an online repository to your online GitHub profile, you actually fork a repository.
Pushing and pulling with Git is closely related to cloning. When you push code, you project your code to a remote repository you registered your project with. When you pull code, you update code on your local machine to view all changes made by other developers.

Now that you know the basic Git concepts, you can try running different Git commands to fully understand how Git works.