Navigating Git Flow: A Simplified Approach to Version Control

Embarking on a programming journey, I encountered the complexity of mastering git version control. Unraveling the web of commands proved challenging as a novice. Amidst a sea of information, navigating the documentation and deciphering new terminologies seemed like an endless odyssey.

In this article, I aim to distill the essential commands and concepts required to embark on a seamless git journey.

Let's Dive In!

In the words of Wikipedia, "Git is a software designed to track changes in sets of files, commonly used to coordinate collaborative source code development among programmers." In essence, Git empowers users to monitor changes across files, offering manual control over the process. Users decide which changes to incorporate, which to preserve, and even how to revert to prior states.

Deciphering Git Flow

At its core, Git Flow is a strategy, a workflow concept that evolves according to the project's needs. It involves decisions regarding deployment branches, primary development branches, and the approach to branching out for feature development.

Demystifying Git Flow Workflow

Envisioned below is a Git Flow workflow employed by most developers during continuous development:

• The main branch, deployed at the development cycle's culmination, houses stable elements meant for staging or production.
• The develop branch facilitates ongoing development, serving as an intermediary stage before merging into the main branch.
• feature branches are dedicated to individual feature development. These branches can further splinter into smaller units for seamless collaboration.

Harmonizing the process occurs through Pull/Merge Requests, subject to team review. This facilitates learning, quality assessment, feedback provision, and knowledge sharing.

Key Git Flow Commands

Entering a new project involves cloning the repository. A fundamental command is:

For instance:

Upon repository cloning and setup completion, development begins, and Git Flow comes into play.

1. Starting a New Feature:

• We will check out to the develop branch if we are not in it already because we will be making changes for the develop branch. 

• We will pull the latest changes from remote develop branch (origin develop), so we won’t start developing on something that is already changed.

•  git checkout -b <branch name> will create a new branch and will checkout into it. The name of the branch could be feature/HM-112-header
  

2. Development Phase:

• After we make some changes and want to stage them for commit, we add them to Staged Changes. We can, of course, Stage Changes only for one file with git add path/to/file or whole directory with git add path/to/directoryOnly but in this case we will add all the changes with the following command:

• git commit -m '<commit message>' is used once we made all the needed changes during the work phase and staged all those changes with git add . we will commit the changes to a feature branch adding a message in which we shortly summarise what we did, for example:
  

3. Completing the feature:

• git push origin <branch-name> - once all the changes are made and committed, we will push the whole branch into the remote branch (git provider server) whose name should be the same as a local branch, for example: 
  

• We then open the Pull/Merge Request using the git provider UI.

Should further revisions arise post-review - repeat steps 1 and 2 of the Development Phase.

Merge the branch into the develop branch, reaping the benefits of Git Flow's structured workflow.