Version Control with Git

Version control system records the changes made to our code over time in a special database called the repository. We can see our project history and see who has made, what changes, when, and why. If something has messed up, we can revert our project to an earlier state. Without a version control system, we will have to constantly store copies of the entire project in various folders. This is very slow and doesn’t scale at all. Especially if multiple people have to work on the same project. Sometimes you would have to constantly receive the latest code via email or some other mechanisms and then manually merge the changes. In short, with a version control system, we can track our project history and work together. Let’ consider the types of version control systems.

Centralized — All team members connect to a central server to get the latest copy of the code and to share their changes with others. The main disadvantage of centralized architecture is the single point of failure like the server goes offline. We cannot collaborate or save snapshots of our project, so we have to wait until the server returns online. Ex:- Subversion, Microsoft team foundation server.

Distributed — In distributed systems we don’t have these problems because every team member has a copy of the project with its history on their machine. So we can save snapshots of our project locally on our machine. If the server is offline, we can synchronize our work directly with others. Ex:-Git, Mercurial.

Introduction to Git

Git is the most popular version control system in the world. More than 90% of projects in the world use Git. Operations like branching and merging are slow and painful in other version control systems. Let’s discuss other advantages of using Git.

• Free
• Open-source
• Superfast
• Scalable
• Cheap Branching/ Merging

There are two ways to use Git for your project.

• The command lines
• GUI tools

Most of the programmers use Git on the command line. Because these GUI tools have some limitations, and the command line is the fastest way to get the job done. GUI tools support the Git commands that people use most of the time. Even you use the GUI tool, sometimes you have to use GIT commands to do your job. Also, you might connect to a server remotely and you may not have permission to install the GUI tool. If you don’t know how to use the command line, then you are stuck. Therefore, this article is regarding the git command that you must know.

Installing Git

Git is open-source free software. You can download it on their official page. After installing it, we can verify it by checking the version. You can use your command prompt/terminal for these commands. Once you install it, you can use Git BASH (for windows users) to run the Git commands.

git --version

Download:- https://git-scm.com/download/

The first time we use Git, we have to specify a few configuration settings.

Set your name

git config –global user.name “Your Name”

Set your email address

git config –global user.email username@example.com

Set the default editor

git config --global core.editor "code --wait"

Set the Line Ending (input for mac/Linux, true for windows)

git config –global core.autocrlf true

Git help

Using Git documentation is the best way to find any command that you want.

Documentation:- https://git-scm.com/doc

Or else you can use the Git help command to find it out.

git --help

Initializing a Repository

First, you need to navigate to the corresponding directory by using the change directory command. Then you can initialize the repository using the init command.

git init

Then it will create a hidden file called “.git”. This is the place git uses to store the information about branches, versions, etc. If you delete this file, you will lose all information about project history.

Git Workflow

Every day we modify codes in our project. We commit those changes to our repository to record them. Creating a commit is like taking a snapshot of our project. Git has a special area like a special intermediate step that doesn’t exist in most other version control systems. It is called the staging area. When we are done making changes, we add the modified files to the staging area by the git add command. Next, we will make a commit. Then the proposed snapshot will permanently be stored in our repository. The staging area allows us to review our work before recording a snapshot.

Assume our repository is currently empty. We want to add two files to it and first, we need to add them into the stating area by using the following git commands.

git add file1.java file2.java   - this commnd for file1 and file2
git add *.java                  - this comand for all java files
git add .                       - this command for all files

This is the state that keeps proposing changes for the next commit. Then we use the commit command to permanently store this snapshot in the repository. As part of this, we supply a meaningful message to indicate what the snapshot represents. This is essential for having a meaningful history. Once we fix bugs, implement new features and refactor our code, we make a commit and each commit clearly explains the state of the project at that point in time.

git commit -m “initial commit”

Note: Once we commit, it doesn’t mean the staging area becomes empty. It keeps the same snapshot that we shared in the repository.

Git Status

Let’s change the code in one file(file1). When it was changed, the file is marked as modified. Because our code is different from the staging area. You can see it by using the git status command.

git status

Therefore, you need to add and commit once you complete the modification.

Once you add the file to the staging area, the modified files are shown in green color.

Let’s try to remove a file from the repository. If we delete file2, it still in the staging area. You need to add it to the staging area, then it will be removed from the staging area. Even though we are saying add to staging, git knows that the file2 is actually deleted. Once you committed it, it will be removed from the repository.

View files in the Staging area.

Then you can view the files in the staging area by using this command.

git ls-files

Git Log

you can see the previous commits that you have made by using the git log command

git log

Each commit consists few main components as follows.

• ID
• Message
• Date/time
• Author
• Complete snapshot

Git doesn’t store what was changed. It stores the full content. Therefore, it can quickly restore the project to an earlier snapshot without having to compute the changes.

Skipping the staging area

If you want to skip the staging area, you can directly store your modified files in the repository by using this command.

git commit -a -m "commit message"

a — all the files, m — message

GIt restore

There are times that we have some code in our working directory that we want to throw away. For example, If we made some changes and those changes made the bug more complicated, we have to restore it. We can discard the local changes using the restore command.

git restore file1.java

When we execute this command, git is going to take the version of this file in the next environment which is our staging environment.

Git clean

We can clean all untracked files from the working directory by using Git clean command.

git clean -f 

Git Branches

Let’s consider your project has few different features. One feature is not working correctly. Then you need to revert it and modify it separately. If you use the same branch for the whole project, this modification bothers all the team members. Therefore this branching system is very useful when you want to add a new feature or fix a bug. You can create a new branch by using this command.

git branch feature-login

After creating a new branch, you can change the current branch to the new one. By default, the project starts with the main(master) branch. To change your branch,

git checkout feature-login

When you complete the feature implementation, you can merge two branches. First, you need to go back to the master branch and then use this command to merge.

git merge feature-login

Ignoring files

In almost every project we should tell git to ignore certain files and directories. For example, when we are developing a Java application, we don’t want to include class files that get generated as a result of compiling our code. To prevent this, we have to create a special file called ‘.gitignore’. This file has no name. it only has an extension. It should be at the root of your project.

#all class files
*.class
#log directory 
logs/

It will only work if you haven’t already included a file or a directory in your repository. If you have already included it in the repository, you need to remove it from the staging area.

git rm –cached -r bin/

Also, you can use common ‘gitignore’ templates for different languages on GitHub official site.

Site:- https://github.com/github/gitignore

Pointing to the Remote Repository

Until now, we have work with our local repository. When you are working with a team, you should share our code to a centralized location. GitHub, GitLab, Bitbucket are famous remote repositories that most programmers use. For this article, I use GitHub as the Remote Repository. Let’s see how to point this local repository to the remote repository.

• First, you need to create an account on GitHub
• Create a Repository with a suitable name for your project
• Copy the URL of the repository you created.
• Perform the command on your local repository as below

git remote add origin <repository URL>

Git Push

After adding a remote repository, you can send your code to that repository. You can use this command to push it.

git push -u origin main

The first time you need to mention that send it to the main branch. If you are working with a team, there might be someone who changes the content of the same branch. If you push directly, the changes made by other people are removed from the branch. Therefore, first, you need to pull the code on the branch and then push it back.

Git Pull

Like our previous example, if someone is working in the same branch that you work, first you need to get the code on the remote repository. Therefore you can use the git pull command.

git pull orgin main

Git Clone

For example, you have to work on an existing project. Then you need to get the previous code from the remote repository. This command can be used to perform it.

git clone <repository URL>

Best practices for Git

Let’s see some best practices you should know when working with Git.

Each commit should be representing a logically separate changeset. Don’t mix things up. As an example, if you are currently implementing a new feature and you found a bug in the existing code. These should be completed as two commits. Because you cannot revert a single modification even if it necessary.

Don’t make a commit every time you update a file. Commit once you complete a specific task of your job like bug fixing, implementing new features, refactor our code, etc.

Commit at least once a day(end of the day) even though you didn’t complete the work. Because if you lost your machine, you can work on another machine without losing any code modification.

Create a separate branch for every new feature, bug fixing, etc. It should be merged to the main branch at the end of the work.

I hope you learn something new about Git. If I missed any points, let me know your suggestion in the comment section.

Reference

[1] Programming with Mosh — Git Tutorial https://programmingwithmosh.com/general/learn-git-in-1-hour/

[2] Git Documentation https://git-scm.com/book/en/v2