Welcome, valiant developers, to the thrilling realm of “Working with Code – Embrace the Darth Vader Way!” Over the years, I always wonder and also thrive to build software systems that can withstand the test of time but at the same time not frustrate the development process. I notice when you spend so much time optimizing the process, you can easily lose track of the main objective here and get lost in the galaxy.

Just as Darth Vader once sought to bring balance to the Force, we must strive to find the perfect harmony between code efficiency, cleanliness, and scalability.

Today, I intend to dive into some best practices that can elevate skills and fortify projects from potential invaders. Uncover the secrets of version control, skillfully managing branches to create a seamless collaborative experience. Our journey will lead us to wield the Force of code analysis, exposing hidden flaws and ensuring the utmost quality in every line we write within the GitLab ecosystem.

The Darth Vader Way is not merely about dark and light, but rather finding harmony in our coding journey. So, whether you’re a Jedi Master or an eager Padawan, let the Force of Code flow through you as we venture forth. Together, we shall forge resilient software architectures that can withstand any onslaught. Without further adieu, let’s get started on this spaceship trip

Embrace the Force of Code, developers. Unleash its power to craft software that stands the test of time. With each commit, shape the destiny of your project, and together, we shall rule the software galaxy!

– Darth Vader, Code Sith Lord

Embrace the Git Force

The first branch in this journey is mastering version control where Git is going to be our lightsaber moving forward. Version control allows us to manage our codebase with precision and confidence.

Within the GitLab ecosystem, we have access to a robust VCS that empowers us to collaborate effectively, safeguard our work, and venture into experimental branches without fear of disrupting the main project.

Embrace the Branching Strategy

Much like the branches of the Force, Git allows us to create branches to work on separate features or bug fixes without disrupting the main codebase. By adopting a well-defined branching strategy, we ensure a smooth and organized development process. One of the questions teams tend to ask is which strategy should we pick – I think the first thing here is to learn about the popular strategies here

Gitflow

Gitflow is a popular branching model designed to facilitate collaborative software development. It involves the following branches:

1. Master/Main branch: Represents the production-ready code. It always contains stable releases of the software.
2. Develop branch: Serves as the integration branch for ongoing development. Feature branches are created from “develop” to work on specific features or tasks.
3. Feature branches: Created from “develop,” feature branches allow developers to work on new features or improvements. Once completed, they are merged back into “develop.”
4. Release branches: Created from “develop” when preparing for a new release. The release branch allows for final testing and bug fixing before merging into both “master/main” and “develop.”
5. Hotfix branches: Created from “master/main” to address critical issues found in the production code. After fixing, they are merged back into both “master/main” and “develop.”

Github Flow

A more lightweight alternative to the Git flow – it encourages continuous integration and continuous deployment as teams don’t have to keep release branches.

1. Main/Master branch: Represents the production-ready code. It always contains stable releases of the software.
2. Feature branches: Developers create feature branches from the main branch to work on specific tasks or features. When the feature is done, developers merge the code to the master branch.

Gitlab Flow

Another simpler alternative is also the Gitlab Flow. This flow is very similar to the Github Flow with support for multiple environments. Here, there are additional branches for environment i.e. pre-production, production, and others.

Generally still a simpler version of the Git flow but slightly more complicated than the Github flow

Vader Flow

Here comes my personal favourite – The Vader Flow. From experience, I like the simplicity of GitHub flow (very quick), the idea of “develop” branches from the Git flow, and lastly the idea of multiple environments from the Gitlab flow but without having various branches for that.

So here comes the Vader flow –

1. Master/Main branch: Represents the production-ready code. It always contains stable releases of the software. Code merges are only allowed from the develop/staging branch.
2. Develop/Staging branch: Develop or staging branch – I use staging here because pre-production or staging environments are deployed from here. This allows us to test new changes that will be merged into the master branch have been properly tested and validated. The feature branches will also be created from this branch.
3. Feature branches: Created from “develop” feature branches allow developers to work on new features, bug fixes, and improvements. Once completed, they are merged back into “develop.”
4. Tags – Releases are created from tags which are checkout from the master branch.

The key highlights of the Vader Flow are:

1. Simplicity and Quick Iteration: Similar to GitHub Flow, the Vader Flow keeps things simple with only two main branches (master/main and develop/staging). This allows for quick iterations and reduces the complexity associated with multiple long-lived branches.
2. Staging Environment for Validation: Introducing a “staging” branch allows for thorough validation of changes before they are merged into the production-ready “master/main” branch. This ensures that new features and bug fixes undergo proper testing in a staging environment, promoting code quality and stability.
3. Feature Branches for Development: Creating feature branches from the “develop/staging” branch enables developers to work on specific tasks in isolation. This promotes collaboration and reduces conflicts while keeping the main branches clean and stable.
4. Tags for Releases: Utilizing tags to create releases from the “master/main” branch provides a clear and well-defined snapshot of the codebase at specific points in time, making it easier to manage production releases.

Branching Names – Navigating the Galaxy of Code

In the vast expanse of software development, the choice of branch names may seem inconsequential, but it plays a vital role in ensuring a well-organized and coherent codebase. Just as Darth Vader needed a precise title to command respect, our branching names must be clear, descriptive, and meaningful.

There are many excellent naming conventions regarding git branches and commits – https://dev.to/couchcamote/git-branching-name-convention-cch

“Embrace the Power of Clarity in Branching Names – For in the coding galaxy, a well-named branch reveals the true purpose and brings order to the Force of Version Control.”

– Darth Vader, Code Sith Lord

Here is the Vader proposition –

Start with a category

A git branch should start with a category. Pick one of these: feature, bugfix, hotfix, or test.

• feature is for adding, refactoring or removing a feature
• bugfix is for fixing a bug
• hotfix is for changing code with a temporary solution and/or without following the usual process (usually because of an emergency)
• test is for experimenting outside of an issue/ticket

Use Issue tracker Id when available

When an issue tracker like Jira is associated with the branch being worked on, it’s a good idea to use that instead – I generally prefer this over the category. For example

JIRA-345-add-okta-sso

The name shows that the branch applies to the task of adding a Single Sign On from Okta to the application or project, the tracking Id of the issue is 345, and the work is in progress.

Another advantage of this convention is that platforms like Gitlab can easily create a notification to the Jira issue or make it clear that this issue is linked to Jira.

Add description

The branching name should include some description which sums up the purpose of this specific branch. This description should be short and “kebab-cased”.

Examples:

• You need to add, refactor or remove a feature: git branch feature/support-azure-storage-buckets
• You need to use an Issue tracker git branch JIRA-235-adds-e2e-tests-in-ci-pipeline
• You need to fix a bug: git branch bugfix/fix-mqtt-log-delivery-error
• You need to experiment outside of an issue/ticket: git branch test/security-vulnerability-integration

Semantic Commit Messages – The Power of Clear Intent

The Force flows through our commit messages. Descriptive commit messages make it easier for fellow developers to understand the changes and the reasoning behind them. Clear communication through commitment fosters collaboration and contributes to a cleaner codebase.

The Vader Flow encourages you to flow a structured format – Semantic Commit Messages is a potent force here.

The commit message should be structured as follows:

<type>[optional scope]: <description>

[optional body]

[optional footer]

Structure of Semantic Commit Messages

Semantic commit messages follow a specific template, consisting of a type and a description. Each type signifies the nature of the change, while the description offers a concise summary of what was accomplished. Common types include:

1. feat: Signifies the addition of a new feature or enhancement that expands the project’s capabilities

   feat: Implement user authentication with OAuth

2. fix: Represents the resolution of a bug or issue, correcting unintended behaviour.

   fix: Resolve null pointer exception in user service

3. docs: Focuses on updates to documentation, ensuring clarity and accuracy for future reference.

   docs: Update README with installation instructions

4. chore: Refers to housekeeping tasks, routine maintenance, or non-functional changes.

   chore: Remove unused dependencies

5. test: Highlights changes related to tests, ensuring code reliability and quality.

   test: Add unit tests for user registration

6. style: Involves cosmetic or stylistic changes, such as formatting or whitespace adjustments.

   style: Format code according to style guidelines

7. refactor: Marks improvements in the code structure without changing its external behaviour.

   refactor: Extract common validation logic into a utility function

Scope

The scope could be anything specifying the place of the commit change. For example $location, $browser, $compile, $rootScope, ngHref, ngClick, ngView, etc…

1. feat(login): Adding a new feature or enhancement related to log in:

   feat(login): Implement user authentication with OAuth

2. fix(user-service): Fixing a bug or error in the user-service:

   fix(user-service): Resolve null pointer exception in user registration

3. docs(readme): Updating README with installation instructions:

   docs(readme): Update installation steps and dependencies

4. chore(deps): Removing unused dependencies:

   chore(deps): Remove unnecessary third-party library

With semantic commit messages, we embrace clarity and purpose in every code change. Let us forge a path through the software galaxy, guided by these powerful messages, one commit at a time. May the Force of Clear Intent be with us on this coding journey! and when lost feel free to navigate to the conventional commits harbour for some guidance – Conventional Commits

This concludes the first part of this journey, stay tuned for the next part where we will venture into Merge Request, Code Reviews, and Code Analysis.

In the galaxy of software development, the Force of clear intent guides us. Embrace the Darth Vader Way, and together, we shall forge resilient code, withstand any challenge, and shape the destiny of our projects. May the Code be with you!

– Darth Vader, Code Sith Lord