Branching in GitLab: Mastering the art of concurrent development paths

In the dynamic world of software development, the ability to concurrently develop features, fix bugs, or experiment without affecting the main codebase is indispensable. Git, the underlying version control system of GitLab, provides an elegant solution to this challenge through its ‘branching’ mechanism. Branches in Git are essentially parallel lines of development, allowing teams to work on multiple aspects of a project simultaneously without stepping on each other’s toes. In this article, we delve into the foundational concepts of branching in Git and elucidate how one can effectively manage these development pathways using GitLab.

a. Introduction to Branches:

Branches can be visualized as offshoots from the main codebase. They represent isolated environments where developers can introduce changes without affecting the primary line of development, often referred to as the ‘master’ branch. Once the changes in a branch are tested and validated, they can be merged back into the master, ensuring a continuous integration of features and fixes without disrupting the core functionality.

b. Creating Branches with git branch:

Creating a new branch is a seamless process in Git. By using the git branch command followed by the desired branch name, a new branch is spawned, branching off from the current point in the codebase. For instance, git branch feature-x would create a new branch named ‘feature-x’. It’s essential to note that this command only creates the branch but doesn’t switch to it.

c. Switching Branches with git checkout or git switch:

Navigating between branches is achieved using the git checkout or the more recent git switch command. To switch to a branch named ‘feature-x’, one would use git checkout feature-x. However, the modern approach recommends using git switch feature-x, which is designed to make branch switching more intuitive. This allows developers to effortlessly hop between different development contexts, ensuring flexibility and efficiency in the development workflow.

Scenario:

Assume you are working on a project housed in a GitLab repository at https://git.freshers-exa.in/data_engineering/. You have the master branch, a release branch, and you are tasked to create and work on a new feature branch.

Step-by-Step Process with Examples:

1. Creating a New Feature Branch:

To create the feature-frehers-in-viewership-2024-9878 branch, you would open a terminal and navigate to your project directory, then run:

git checkout -b feature-freshers-in-viewership-2024-9878

This command will create and switch to the new feature branch. You can verify the branch creation in GitLab by navigating to https://git.freshers-exa.in/data_engineering/tree/feature-frehers-in-viewership-2024-9878.

2. Developing and Committing Changes:

While on the feature-frehers-in-viewership-2024-9878 branch, you would perform the necessary code modifications or additions. Once the development is done, you can stage and commit the changes using:

git add .
git commit -m "Implemented viewership feature"

3. Pushing Changes to GitLab:

To push your committed changes to the remote feature branch on GitLab, you would run:

Now, your changes are available for review at https://git.freshers-exa.in/data_engineering/tree/feature-frehers-in-viewership-2024-9878.

4. Merging to the Release Branch:

After your feature has been reviewed and approved, you might want to merge it into the release-frehers-in-sept-2023-v01 branch. For this, first, you would switch to the release branch:

git checkout release-freshers-in-sept-2023-v01

And then, you merge the feature branch:

git merge feature-freshers-in-viewership-2024-9878

Finally, push the changes to GitLab:

git push origin release-freshers-in-sept-2023-v01

The merged changes are now available at https://git.freshers-exa.in/data_engineering/tree/release-frehers-in-sept-2023-v01.

5. Final Merge to Master:

Once the release branch has been thoroughly tested and is deemed stable, the changes can be merged into the master branch using a similar approach, by switching to the master branch, merging the release branch, and pushing the changes:

git checkout master
git merge release-frehers-in-sept-2023-v01
git push origin master
Author: user

Leave a Reply