Why should we git?
Yeah, yeah I know here we go again with the version control explanation for the millionth times on this website
but hey, hold up a sec. do you even know why every software development cycle uses some type of version control to maintain its development process?
isn't it common sense?
well yeah.. but why? well, I will try to explain and explore the topic of version control and its usage in this short article, and what version control system is the best to represent version control itself rather than Git.
what is GIT?
Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
well at least, that's what is stated on the official website…
basically what git does is track your local files and the changes you make on these files. So you have a record of what has been done, and also you could do a lot of things with it such as revert to the previous state if you ever need to.
Git also makes collaboration easier, allowing changes by multiple people that are working on the same project to work asynchronously and eventually be merged into one source.
so whether you are working as a team or not, this will be hella useful especially if the work you are doing consists of a lot of changes such as developing software.
is it really that amazing?
well, the short answer is.. yeah.
think about it like this, Real-life projects generally have two or more developers working in parallel. So a version control system like Git is needed to ensure there are no code conflicts between the developers.
Additionally, the requirements in such projects change often. So a version control system allows us as developers to revert and go back to an older version of the code.
Finally, sometimes several projects which are being run in parallel involve the same codebase. In such a case, the concept of branching in Git is very important.
wow okay then, what should I do?
How do we GIT?
there is too much information on how to get Git up and running, and all the explanation you will ever need on how to operate with it on the internet, so ill just stick to the DRY principle and won't reinvent any wheel 😜.
but yeah, I will explain the basic of commands that I use every single day, and based on my experience, using only these commands will make you 98% “fluent” in Git.
let's just jump right into it shall we?
there are 6 commands that you need to know to get started in Git.
git init
git clone
git status
git add
git commit
git push
that's it. that's all you need.
well, I'm still going to explain how to use those commands in a project 🙌 .
Firstly, you should verify whether or not Git is installed on your system by running the command.
git --versionif it spits out a version then you are good to go.
Git init
we use this command to initialize a local git repository
git initafter running it you should see something like this.
the .git folder tracks all the version snapshots on your current system
Git clone
if you already had an existing project in a remote repository, you could use this command instead to clone the project to our local machine, run it by doing git clone followed by the repository link.
git clone https://github.com/mhuda1/cobagit.gitit will create a folder on your local machine named after your repository.
Git status
we use this command to find out information regarding what files are modified and what files are there in our current working directory — it shows other information as well, though we won't cover all of it now
git statusto see how it works, let's create a text file on our git directory and check its status.
the red file name indicates that git has not yet track that file, we could “add” that file to git by using the next command.
Git add
by using this command we could add the stuff we want to track into the staging area. The staging area is there to keep track of all the files which are to be committed.
git add test.txtyou could replace test.txt with anything that you want to add, after it's been added, running status once more will yield these results.
the files in the staging area will now be colored green.
Git commit
Committing is the process in which the code is added to the local repository. Before committing the code, it has to be in the staging area.
Any file which is not added to the staging area will not be committed. This gives the developer control over which files need to be committed.
we can use the following command to commit the file
git commit -m "commit message"anything you put beside the -m flag indicates the commit message.
after doing the commit, you usually should see your staging area emptied, and your local repository updated.
Git Push
you use the push command to “push” all the code from the local repository into the remote repository.
first, check if your local is linked to the remote repository by running
git remote -vif it's empty you could add a remote repository by running the command
git remote add origin https://github.com/mhuda1/cobagit.gitcheck it again by running remote -v
by doing so you should be able to push to your local repository by running the command
git push -u origin masterThis pushes the code from the master branch in the local repository to the master branch in the remote repository.
if you follow all the steps since the beginning, your code should be pushed to the remote repository.
Git implementation in real projects
well now we know the basics of git, so how is it really implemented in real development projects with multiple developers working asynchronously? well in this explanation, ill use my project with PPL 2021 and the workflow it is using for git and version control.
Git Flow
in PPL 2021 we use this workflow to manage our branches and codebase.
I shall explain briefly what is the function of all these branches.
- Main (Master) Branch
this is the main branch that stores the source code of the program that is deployable and ready to be used by the user. it is also protected and could only be modified by the scrum master.
- Staging
the staging branch act as a temporary branch to merge all the PBI branches that are going to be reviewed at each and every sprint. we could merge our PBI branches to the staging branch by first getting reviewed and the approval of at least 2 other team members.
- PBI
we use this branch as an individual branch to implement the product backlog
- Hotfix
a branch from the main branch that acts as a proxy branch that could be used if a bug or error occurs in the main branch.
- Coldfix
we use this branch to implement a rollback. this could happen if, during a sprint review, the product owner rejects or disapprove a product backlog item or PBI that has already been implemented.
Commit Messages
in PPL 2021, you must also use specific commit messages in each and every one of your commits. these tags are used to identify and clarify each commit and also function as a method to upheld clarity in the development process.
the tags that are used are as followed,
- [RED] indicates a unit test commit, marked by a failed pipeline
- [GREEN] indicates a code implementation commit so that the test would pass. marked by a green pipeline
- [REFACTOR] is used to indicate implementation of code after the previous one before it. Used for fixing bugs, improving functionality and complexity of the code.
- [CHORES] is used to indicate an implementation that has nothing to do with the functionality of the code. e.g changing names, adding icons and images
that's it for now, as you can see, the usage of version control on the development of an application is applicable in so many different ways. While yes, it is possible to develop software without using any version control, doing so subjects the project to a huge risk that no professional team would be advised to accept.
So the question is not whether to use version control but which version control system to use. and in this case Git is a go to system that is both robust and simple to use.
so what are you waiting for folks, if you are not yet using Git for your software projects, I advise you to use it from now 😆
Cheers!
Sources :
