Table of Contents
Part-0 Introduction
BackStory
During my first year of undergrad I came across this distributed version control system(DVCS) called Git and the developer platform GitHub. At that time I was looking into it as I heard about "Hacktoberfest" taking place in my university. Since Java was one of the many accepted languages and given my basic understanding of it since my schooling. I went ahead and looked into the event. Back in 2020 Hacktoberfest was giving free T-shirts to participants that complete the challenge I was intrigued by it.
To complete the challenge one was required to contribute to any public repository with the topic Hacktoberfest. To be specific one had to make around 4-5 successful pull requests i.e their changes had to be merged to the main repository post their registration on their website (don't worry if you don't understand what I said here).
Given that there was only a week left for October to end. I learnt the basics of git such as how to pull and how to submit pull requests on Github. My knowledge on Git had stayed this way until my third year of undergrad where I was able to do majority of my work with this basic knowledge. However, recently I have developed a keen interest to learn git thoroughly. Why you the sudden interest, you wonder? Simply put, I aim to leverage Git more effectively for my future projects. In this blog series, I document my journey of unraveling the complexities of Git. The blog series is an amalgamation of my understandings from the git documentation, the book "Ry's Git Tutorial" and my own learnings along way during my undergrad. Another reason for me to write these series of blogs was to have these blogs as a place I can come back to from time to time to revise things as and when required.
Part-1 The Basics
Think of the history of Git is something similar to a Linked List is my guess, where they link the new commit to the previous commit. Let's see if this is true or not in part 3. Another beautiful use case of git is the ability to collaborate and work on projects in parallel. The whole world of open source is built on the foundations of git. To understand this further let's take a simple example, suppose you and your friends went to hackathon and you want to develop a website where two of you work on the backend while the other works on frontend. If you had a single code base where both of sides are developing things can get messy real quick. Using Git one can make two separate branches in the repo named backend and frontend. This way one can use the same file structure and work in parallel at their respective branches. Once you have tested the functionality of each side, you can merge both of these branches onto the main branch. This example show us how Git helps in increasing the productive of a developer. Another great reason to create branches is that a branch provides you with opportunity to have an independent line of work. This way you don't have to replicate all the files and pre-existing codebase if you want to experiment on it. If the experiment works out, you can always merge it to the main branch else just delete the entire branch and forget about it. An additional benefit of this is that all your experiments will be in a single directory as multiple branches that don't affect the working stable version.
1. Topic Branch: is used to work on a specific topic or task. It is typically created off the main branch (such as main) and is used to isolate changes related to that topic. Once the work on the topic is completed, the changes in the topic branch can be merged back into the main branch.
2. Feature Branch: is similar to a topic branch but it is specifically used to develop a new feature for the project. It is created off the main branch and is used to work on the new feature in isolation from the main codebase. Once the feature is complete, the changes can be merged back into the main branch. This branch generally is maintained for longer duration than Topic branches.
3. HotFix Branch: is used to quickly address a critical issue in the codebase, such as a bug or security vulnerability. It is created off the main branch or sometimes a release branch and is used to make the necessary changes. Once the fix is complete, the hotfix branch is merged back into the main branch (and possibly other active branches) to apply the fix to the codebase.
A merge conflict takes places when we try to merge branches that have edited the same content. Git doesn't know how to combine the two changes, so it stops to ask us what to do.