Understanding Git: Open Source for Novice.

Perhaps you hear the term "Open Source" often. You are impressed by people contributing to large complex Open Source Software. But you don't know where to start, even good first issues seem to be very hard to approach.

I recently made a CLI Tool called tell-about and open-sourced it. So as an open-source maintainer of my tool with little fame I got some experience so I have decided that I am going to help you understand how to contribute easily.

So, what's the best way to start?

I recently saw a tweet by Ben Awad -

Ben Awad

@benawad

if you're a beginner and having a hard contributing to open source, I recommend starting your own project first then coming back to it

18:39 PM - 04 May 2020

I have to agree with it. I have decided to create a series of write-ups that help people understand the system of open-source software. The series is going to cover everything from introducing git to creating a fully automated repository on GitHub.

Understanding Git

When I was a beginner, I always wondered what a pull request, a branch, and all those things were exactly. With all the complexity of git, it was hard for me to wrap my head around how everything in a complex project like React worked.

Understanding how Git works is the first step to understanding how you can start to contribute to open-source software.

Need of Git

For those who don't know, git is a VCS or Version Control System. Now, take a moment to think about the version. There are so many people trying to contribute to one single project.

At a given time there are many people working on a single project but different features.

If they all were to make changes directly to the project then there would be a huge mess,

Let's try to understand with an example - 'A' changes lines 1 through 10 to incorporate a feature A and 'B' changes lines 5 through 15 to incorporate a feature B.

'A' updates the code first. 'B' updates the code second.

In this situation, the code of B works while the code of A is broken because B has now overwritten lines 5 through 10. Now take this example and magnify the situation with 25 people.

Sure, they won't always be making changes on the same lines. But a lot of times they will be.

This is where our VCS comes in to play. The VCS is used to maintain a main stable version. A stable version is a version where all features work properly. This main stable version is generally called Master. Let's learn about Branches to solve this issue.

Branches

Let's now see how VCS solve this problem of merging two features.

With git we can create a duplicate of the current Master version, this duplicate is called a branch. So, this time 'A' starts working on feature A on branch A. 'B' does the same.

'A' makes the changes on branch A and merges their branch to the master version.

Well and good. Now, 'B' also tries to merge their branch but... we run into the same problem again except we have git to back it up. Git tells B that there is a merge conflict, B quickly identifies that A has made some changes and now he has a couple of options to resolve this merge conflict -

1. He pulls (gets) the changes of A from the master branch to their branch, keeping the code of A, B adds their code after the code of A and keeps the code of both.
2. While merging to the master branch B manually modifies the code to keep both feature A and feature B.

Generally, there will be a third person, a maintainer (or a senior) of the repository to regulate. The maintainer will review the code and ensure that B's code is good by reviewing it.

More often than not, while contributing to big open source projects you will find that they also have tests. Tests checks if the output of code is as expected. And if any tests are failing it is fairly common to have a bot like Travis CI to tell if the code is broken. Which further mitigates the risk of breaking the code.

So, in the scenario that A has some features and B breaks the feature the Travis CI bot will tell that tests of feature A is failed.

Forks

If you've used any amount of GitHub you must have noticed a fork button on GitHub repositories.

Branches are internal, even the master version I talked about is a branch, giving access to everyone to modify branches could be a big danger. That's where forks come in to play.

When you create a fork of a repository you create a copy of that repository that belongs to you.

The difference between Forks and branch is that when you create another branch it is the copy o f a branch. But when you create a fork it is a personal copy of the whole repository, you can modify it in any way you want and it won't effect the main codebase of the project.

After you make changes to your fork you can request the maintainers of the project to merge your changes with the main project. That brings us to the next topic.

Pull Requests

Pull request might seem a bit complicated after you see it on GitHub. It may seem so complicated that you might neglect the simplicity of its name.

A Pull Request is a request to the maintainers of a repository to pull (merge) your changes. Pull simply means pulling changes from your fork or branch to another branch which is the master branch most of the time. A request is a request.

A Pull Request compares 2 branches, the 2 branches maybe master branch and a branch from your fork or master branch with any other branch.

Ending Note

Hopefully, this blog post gives you a really good way to start comprehending the working of git in open source projects. In my upcoming posts, I will be covering how you can contribute and even set up your own fully automated open source project on GitHub.

Thanks for reading till the end :)

Make sure to follow me on dev.to so that you're updated about my upcoming posts.

I am active on Twitter and I am known by the username @yashguptaz. Be sure to hit me up on Twitter if you want any help. A follow-on Twitter is really appreciated :)