The basics which each developer or someone working on a team would want is to collaborate with ease. Often I’ve seen college students passing pen drives or using Google Drive to share their work on some projects or during competitions. They think learning Git is difficult and very time-consuming so they resort to convenient ways but it’s not so. This article will help you learn and start using Git easily.
By definition— ‘Git is a distributed version control system for tracking changes in source code during software development’. If you don’t understand what that means, don’t worry we will go through it. If you are working on a project and collaborating with multiple people, each of them will be working on the codebase and making changes. It is important that everyone in the team knows what the other person has changed in the codebase. By using Git, we can easily do that by tracking changes using ‘commits’ and history. One important thing is to make sure you use a proper commit message when making a commit so that other people can easily understand the changes available in the commit.
I’ve covered Git in 3 parts —
- Basic Git Concepts (You are here).
- Working With Basic Commands.
- Working With Advanced Git Commands.
Repository
A repository is a directory where the project resides. Consider it as a folder in your computer where all the project files are present. Thus this is where all our code and project files would be in. Start by creating a repository by using this link. Enter the name of the repository and a description. You can choose between having a public/private repository.
Public — the repository will be publicly visible on your profile.
Private — the repository will be accessible to only the people you specifically give access to.
Check the ‘Initialize this repository with a README’ option. The README shows up as a description and details on the homepage of the repository.
Basics About A Git Repository
On the homepage of the repository, we can see the name of the repository, public/private status, description, and the files present in the repository. If you had added a README, the content of the README file would show below the files.
Branch
By default, Git gives us a branch called — ‘Master’. What is a Branch in Git? “Branch is a lightweight movable pointer to one of the commits”. We can create any number of branches we want and commit our changes to them which remain separated from the other branch. It is always advisable to create new branches for each change we are working on and not make any commits directly to the master branch. As and when we add commits, the branch pointer moves and points to the latest commit (each commit has a unique Commit ID associated with it).
Having a single branch and committing changes will make it difficult to track the changes later when required. We will keep making changes rapidly to the codebase and it will not be easy to revert back in case of a critical issue in the latest code. The best way to tackle this is to have multiple branches.
We can have a ‘Master Branch‘ as our main branch which has the latest release commit or the most stable code after it has been tested. ‘Development Branch’ will follow the Main Branch where the next set of ‘Feature Branch’ and ‘Bugfix Branch’ will be merged during the development cycle and then finally be merged with the Master Branch. The Feature and Bugfix branches are created from the development branch and merged into it.
Git Flow And Branch Naming Convention
So if we take an example scenario — We have a Social Network app and Version 1.1 is available for our users. So now, the stable code for V1.1 will be available in the Master branch. We will create a new branch called development from the master for adding changes for the next release — V1.2. Let’s say a team of developers is working on the next update and we have 3 tasks to be done — Adding a like feature on posts, Adding a comments feature, Fixing an issue of followers count not getting updated properly. So for these cases, from the development branch, we will create a feature branch for likes, another for commits, and a bugfix branch for the followers issue.
Now you will get an idea of how we can create and name the branches —
- Master Branch — The stable, live, and tested code.
- Development Branch — Next set of code to be tested and merged with the Master branch.
- Feature Branch — Taken from the Development branch by the developers to work on their features.
- Bugfix Branch — Any bugs which are present in the Master/Development branch and are being fixed.
- Hotfix Branch — Any critical bug present in the Master branch which is to be fixed immediately and is directly merged with the Master branch.
To understand Git Flow in detail, check out the article written by Bharat Dwarkani — here.
Commits
A commit is a snapshot of the project with newly added changes. Those can be considered as a saved snapshot version of the project which will not change over time (unless done using reset commands).
A commit is usually associated with a unique ID called the Commit ID or Commit SHA. Each commit also includes a commit message either specified by the person making the commit or added by default. It is generally a good practice to specify a proper commit message because later when the project has 100s of commits or when many collaborators are working together, it becomes easy to understand seeing the message what the commit is about.
Release
When developing a product, we usually have milestones like alpha version, beta version, and further release versions. GitHub allows us to mark them as release checkpoints. When we mark as a release, it appears in the release section of our repository.
Marking a release point will create a reference to the commit of the target branch we select and thus we will have direct access to the point in case we want to compare the code changes or rollback in case of any issues to the last release point.
Contributor
For any repository, we can add the team members as contributors such that they will have access to the code as well as push changes to the repository. For a private repository, only the contributors would have access to the repository and can push changes while in a public repository, anyone can view the repository content but only a contributor will be allowed to push changes.
Now you would want to give access to your friends to the repository so they can start contributing to the repository. For that, navigate to Settings from the menu and then to Manage Access. There, you can invite a collaborator using either their username, full name, or email.
Clone Or Download
To work on a Git repository, we would need to have a copy of it on our local machine. To do, we have an option called ‘Clone or Download’. We can clone a repository by a simple Git command and once done, it will be available in our local machine. Now once we have a copy of the repository in our local machine, we can make changes. When the changes are pushed, it becomes available to other contributors too in the remote repository (i.e. the Git Repository). Another option is to directly download the repository as a zip file but if we do that, we would have to set up Git in the local directory manually.
Issues
The issues section in Git can be utilized for various purposes. In an open-source project, people report bugs and issues under the Issues tab which are categorized as Open and Closed. In private projects, the contributors and team members file bugs and issues to make it visible for the team and to keep track of the complaints. These can be marked as closed when they are resolved.
Fork
Forking is used to create a copy of the main repository under your own name. It is generally used in scenarios when you want to take someone else’s project as the starting point of your idea or when you want to make some changes to their project.
Pull / Merge Requests
Pull Requests or Merge Requests are created to either merge a branch into another or when you have forked a repository to merge your changes into the main repository. The PR/MR works well if you are working in a team and want your peers to review the changes and then merge them into the development/master branch.
Basic Terminology
You would generally hear people saying two words — local and remote.
Local version means the repository which is available in your machine. This is not visible to anyone and the changes done here stays in your machine only. You use this version to work on the project and make changes.
Remote version means the repository which is available on the server/internet. It is accessible by people authorized to do so (contributors in a private repository and everyone in a public repository). The changes done on local are generally pushed to the remote repository such that it becomes available to others collaborating on the same project.
Some other common terminologies are —
HEAD — The HEAD is a pointer which points to the latest commit in the currently checked out branch.
Untracked Files — The files which have not been tracked previously by Git.
Tracked Files — The files which were present in the last commit and can be modified or left unmodified.
Working Area — It refers to the files that have been modified but not committed yet.
Staging Area — The files which are marked or added to be present in the next commit.
Git Ignore
.gitignore tells the Git which files should be ignored from tracking and committing. It is generally used to ignore IDE or system generated files and other transient files that aren’t supposed to be present in the Git. For configuring .gitignore, Atlassian has a nice article written — here.
.git Directory
Now that we know that Git stores so much information regarding our repository, it might be a doubt as to where Git stores all this information. You can see it by — navigating to the root directory in the console, and executing the command — ‘cd .git/’. Here if you try listing the content of the directory, you will see many files that you can open in a text editor.
Final Words
Now that we know some basic terminologies of Git, let us start working on them. We will move onto the Part-II in the series and execute the basic commands to see how it works.