- This topic has 0 replies, 1 voice, and was last updated 1 month, 3 weeks ago by Oghenemarho.
February 7, 2020 at 2:54 pm #85371Participant@oghenemarho
Version Control is a very important part of software development these days and for good reason. To put it simply version control is all about managing changes to your software application in such a way that each alteration to the files of source code is labelled and timestamped. This will provide you with an accurate version history of the software throughout the course of its development. The major advantage of version control is that it provides a reliable way for developers to keep track of the constant changes made to their code, whether working as individuals or as part of a development team.
Git, which was created by Linus Torvalds in 2005, is one of the more popular version control systems out available to developers. It was originally created as a distributed version control system to help with the development of the Linux kernel. By distributed, it means that rather than relying on a client to server architecture, each system contains a clone of the entire code repository. This means that every user has a full backup of the code base of whatever software is being developed. What Git essentially does is take a snapshot of all your related files whenever you save the state of your project or commit a change, and stores a reference to that snapshot.
Git also makes use of checksums to ensure file integrity. By employing a SHA-1 hash function, it is impossible to make any changes to the files or the contents of a directory without Git noticing it.
When using Git for version control, there are three main states that your files can exist in:
- Modified which means that you have made changes to the file but haven’t committed those changes to the Git database yet;
- Staged which means that you have marked a modified file in its current version to go into your next commit snapshot; and
- Committed means that the data related to the modified file is safely stored in your local Git database.
GitHub takes Git’s version control system to another level. You can think of GitHub as an online Git repository hosting service with a lot of added features. Some of these added features include the ability to make your repository publicly available to anyone with a browser and an internet connection, collaborations on projects with remote team members, and support for various tools and plugins that link GitHub directly to your development environment or simplify the process of committing changes.
In addition to the Git file states of Modified, Staged and Committed, GitHub has three additional features:
- Forking which essentially means creating a copy of a user’s repository to your own account. This allows you to begin making changes to your fork of the project without modifying the user’s original code
- Pull Request are usually done when you’re ready to share the changes you made to your fork of the project, with the intention of them being incorporated into the main project. This is of course after you’ve already committed your changes so that the project manager can review them
- Merge which is done after the changes to the fork of the repository have been accepted. This essentially merges the changes with the main branch of the project repository.
GitHub is far from the only online code repository with these features. There’s BitBucket, GitLab, GitKraken, just to name a few. It is however, the most popular one, which is why we will be using it to demonstrate how to get started with version control. The first step is to create a GitHub account, which is a pretty straightforward affair.
Once you have signed up and validated your account, the next thing to do is create a GitHub repository. The repository will serve as the place where GitHub will keep track of all your code and all the changes you will be making to it. To do this, make sure you are on the GitHub homepage for your account, then click on the “+” button at the top right of the page. From the drop down menu that appears, selecting ‘New Repository’ will take you to the page where you can input basic information about the new repository you are creating. You can give the repository a name, brief description and specify whether it should be publicly available to anyone or private. Provide the necessary information and click the ‘Create Repository’ button.
With this, you have created an online only repository. However, since most of our software development activities takes place on our local computers, we need to find a way to link the file systems on our computers to the online repository. The easiest way to achieve this is by installing GitHub Desktop on your computer. The latest version of GitHub Desktop which is available for both Windows and Mac operating systems can be gotten from here.
Once installation is completed, you will be asked to sign-in to your GitHub account, and then configure Git with name and email address on your local system. Once that’s done, you will be greeted with a homepage giving you some options for what you can do with GitHub Desktop. You also see a list of any repositories you’ve created in your online GitHub account.
What you now need to do is create a clone of your online repository. This essentially creates a local copy of the repository that you can work on without needing to be connected to the online version. Select the repository you want to clone in the GitHub Desktop interface and click on the clone button at the bottom of the window. This will popup a window showing you the URL for the online version of the repository, and the file path where the local version will be created. You can edit the file path or leave it as is but once you’ve made your decision, you can go ahead and click the ‘Clone’ button.
Having successfully cloned your repository locally, you now have everything you need to begin version control on your local system. Let’s say for instance, I go to the folder that was created as my local repository and add some files and folders to it. All these additions are tracked by the GitHub Desktop application. Any changes to the content of these files is also monitored, whether it’s just a punctuation you added or several lines of code.
Once you are ready to commit the changes you have made to your repository, return to the GitHub Desktop application. In the text boxes on the bottom left labelled Summary and Description enter the necessary details that explain the changes you’ve made to the repository and when you are done, Click on Commit to master. This essentially means that you’ve marked a stage in the history of your repository that can be referred back to and that any new changes will be part of the next commit. However, your commit is still local.
You need to publish the changes in this clone branch of your repository to the online version and that can be done by simply clicking on the blue Publish branch button to the right. Once that operation has run its course, you can return to your online repository to verify that the changes and commits you made locally are all reflected online.
There is certainly a lot more information to mine regarding using GitHub to ease the flow of your software development activities but what we’ve covered here should be enough to get your feet wet with version control systems.
You must be logged in to reply to this topic.