What is Version Control and GIT? How does it help Teamwork?
Written by Gopika Kanattil Shaji and Oluwamayowa Larmie
Introduction
Before going directly to version control, let’s consider a multinational corporation with offices and employees all over the world. There may be some issues or challenges that such a company faces.
The possible challenges are:
- Collaboration: As there are so many people in different locations, there may be a need to communicate for a specific reason or a group of people who are working on the same project but in different regions.
- Storing versions: The project is not finished in a single version; there may be n versions. In such cases, storing all versions and data in a single location is a huge challenge.
- Restoring previous versions: In some cases, it is necessary to revert to a previous version in order to determine the cause of a bug.
- Figure out what happened: It is sometimes critical to know what changes were made to the previous version of the source code or where the changes were made in the file.
- Backup: If the user’s system or disc fails and there is no backup, all of the hard work will be for naught.
Here we introduce Version Control.
Version Control
It’s a system that lets developers manage and track changes to source code over time. This allows multiple team members to work on the same project at the same time, making changes and edits without causing conflicts or losing data. It also helps to have backups in the remote repository*, as well as the ability to roll back to previous commits* and the most recent version of the source code.
Repository*- a data structure that stores metadata for a set of files or directory structure. Commit*- an operation that sends the latest changes of the source code to the repository
Types of Version Control Systems
- Local version control system
Many people prefer to use version control by copying files into another directory. It is also extremely prone to errors.
It’s easy to lose track of which directory you’re in and write to the wrong file or copy over files you don’t want to. To address this problem, programmers long ago created local VCSs with a simple database that tracked all changes to files under revision control.
A local version control system includes a version database and a working copy on the local computer where all updates and storage are performed. The working copy will contain a copy of the sent version, which will be updated in the version database as a new version after changes are made.
One of the most popular VCS tools was RCS, which is still included in many computers today. RCS works by storing patch sets (the differences between files) in a special format on a disc; it can then add up all the patches to recreate what any file looked like at any point in time.
2. Centralized version control system
The next significant issue that people face is the need to collaborate with developers on other systems. Centralized Version Control Systems (CVCSs) were created to address this issue. These systems (such as CVS, Subversion, and Perforce) have a central server that stores all of the source code files and manages all of the team members’ changes. When a team member makes a change to the code, they must first check out the file from the central server, then make the changes and check it back in. This system enables team members to work on the same codebase at the same time, but it can cause conflicts if multiple people attempt to modify the same file at the same time. This has been the standard for version control for many years.
Update*- An operation that downloads any revisions from the repository into your local copy.
One of the benefits of a centralized version control system is that everyone on the project is aware of what everyone else is doing. The other advantage is that administrators have fine-grained control over who can do what, and dealing with local databases on each client will be easier.
For example, if the server fails, the centralized system suffers. Only some can collaborate or save version changes to anything they are working on during that time. And if the hard disc becomes corrupted and no backups are kept, you will lose everything. When you save the entire project history in one place, you risk losing everything.
3. Distributed version control system
It is a distributed system in which every member of the team has a copy of the entire codebase. This means that each member can work independently and make code changes without relying on a central server. There will be both a server repository and a local repository on the local computer. Each member’s changes are saved in their local repository, and when they are ready to share them with the rest of the team, they can push the changes to the central server. This system is more adaptable than CVCS and facilitates collaboration even when team members work remotely.
Clients of a DVCS (such as Git, Mercurial, Bazaar, or Darcs) do not simply check out the most recent snapshot of the files; rather, they fully mirror the repository, including its entire history. As a result, if one of the servers fails and these systems are collaborating through it, any of the client repositories can be copied back up to the server to restore it. Every clone is a complete backup of all the data.
Push*: Pushing is how you transfer commits from your local repository to a remote repository.
Pull*: updates a remote repository with the commits made to the local repository.
Benefits of version control system
- Managing and protecting: Aids in the management of source code by keeping track of all changes made to the code. Source code is also protected from unattended human errors and their consequences.
- Keep a record of all modifications: It will be useful in the future for determining the root cause of any given problem.
- Comparing earlier versions of the code: Developers can compare versions of code to help fix errors.
- Support developer workflow: VSC has no set method of operation; it simply provides a smooth continuous flow of code changes.
What is GIT
Git is a popular version control software system which assists designers or developers to track changes in their code during a particular task. It enables members of a team to collaborate on a project i.e this can be in the form of sharing a task on a project to various units, irrespective of location a member can review a project and make adjustments if required, and enables users to switch between various versions of code within a project being done.
It works by creating a local repository on a developer’s machine and then synchronizing the changes to a remote repository. It is from the remote repository multiple developers have access to copy a particular codebase to their personal system (local repository), they work or make contributions and revert back with the changes to the remote repository.
How to install GIT
- The first step in using GIT is by having the software installed on our personal computer. The installation source can be gotten from the following link https://git-scm.com/
- Next we need to get registered to a GIT management system provider of choice like Bitbucket, Gitlab or Github.
After the two steps above have been done we are good to have GIT start tracking codes on our projects through our code editor on our personal computers or not. This is just to say that after its installation Git does not track our code unless we make that request.
How do we make GIT monitor changes or create versions on our project
1. GIT INIT
Git init is a command which initializes git within the project. It creates a local repo within the specified directory after being triggered it shows a letter “U” beside all the files on the project which means that the files are all untracked.
2. GIT ADD
Git add. command prepares all the files for staging. By staging this are the files that will be tracked and uploaded to the remote repository. When the command has been activated the letter “A” now appears beside all the files on our project and we can move our cursor to deselect any file we do not want tracked and its status remains as “U”.
3. GIT COMMIT
Git commit –m. It saves the code staged within the repository and can have it named if it is the initial commit and create subsequent names to mark specific changes we made and not override the previous or existing commit.
4. GIT PUSH
Git push – This command sends the project from the local repository to the remote repository. We can now view a copy of our code or project on the remote repository.
5. GIT CLONE
Git clone is a command that copies a code base from a remote repository to our local repository and system. After the git clone command has been inputted on the command it is followed by the url on the remote repository, this downloads the code from the remote repository.
Branches
Before proceeding, It is worthy to note that when we create a git repository and are working on a project. It is advisable to create what is called branches. The initial branch after git has been activated is referred to as the main or master branch. However it is not advisable to work on the main or master branch especially when we consider a situation where there are multiple members, that means any member goes on the main codebase and changes the existing code, and if everyone does that it means the work ends up being disorganized . Thus, team members or a group is required to create a branch which copies the code from the master to that branch. Whatever modification done is performed on the branch and is subject to review, after approval from the main team leader it can now be merged to the main branch.
As many branches as required can be created but on completion of the task, if the branch is not needed we can have it deleted.
Branch in a remote repository
Deleting a branch
6. Git log
Git log is a command used in the Git version control system to view the commit history of a repository. When you run the git log command, Git displays a list of commits showing the most recent commit first to the initial commit. But it shows the commit for the local repository only as there is a possibility it is not yet pushed to the remote and can still differ or a different user is still working and has no access to commit to any remote repository. To check the git log of a remote repository, we need to run the git fetch command first before we proceed in checking the log.
7. Git fetch
Git fetch is a command that makes you see the changes on a branch in a remote repository without altering that branch on your local repository. If satisfied with whatever modification you can now decide to merge to the branch on your local repository.
Conclusion
The purpose of version control and git is to make the process of any project done by designers or developers more efficient, organized, and collaborative. It makes tracking modifications or changes easier, retention or versions management and team collaboration. These systems assist designers and developers in working more effectively and improve the quality of the final product.