What are these texts?
I was studing and for me to have some real study done I need to write it down, this is a small collection of topics that I studied in the last few weeks.
Other links from the same study-pool:
What is branching strategies
Git is a common version control system used in many organizations, and branches are often used as a way for teams to develop features separately.
These branches are usually merged or rebased back to a master branch once the work is completed. This way, the features (and any bug fixes) are kept separate from each other allowing you to fix bugs more easily.
Branches protect the mainline of code, and any changes made to a branch don't affect other developers. A branching strategy is the way that software development teams use version control when writing, merging and deploying code.
Even though branches aren't strictly limited to Git, I'll primarily use Git for version control. Before we discuss different branching strategies, let's take a look at how Git actually works and why it is such a popular source control system.
Why you need a branching strategy
A branching strategy is essential to avoid conflicts when merging changes and to make it easier to integrate changes into the master branch.
A branching strategy aims to:
To maximize productivity, ensure that developers are working in a coordinated fashion.
- Allows parallel development
- Organize a series of planned, structured releases
- Created a path to follow on the process to create and merge
- Improves the ability to create a more coherent environment for releases
Here some common strategies
GitFlow
GitFlow is a powerful development workflow that enables parallel development where developers work on features on different branches from the master branch. This makes it easier to manage features and keep them consistent. Later, when the changes are complete, the developers merge those changes back into the master branch for release.
This branching strategy consists of the following branches:
- Master: The main code to be release. This code should be production ready.
- Develop: This is a intermediary branch for testing, QA or any other usage before release a new version of the software.
- Feature: to develop new features, you should branch off the develop branch. This is not a single branch. Every feature should have its own branch.
- Release: to prepare a new production release, you typically branch from the develop branch and merge back to both develop and master.
- Hotfix: is created when a bug is discovered and needs to be fixed. This allows developers to continue working on their own changes on the develop branch while the bug is being fixed. This branch is typically derived from the master.
The master branch is considered to be the most important branch, with an infinite lifetime. The other branches are meant to help developers work together more effectively, usually lasting only a short time.
Pros and Cons
This model allows for parallel development to protect the production code, so the main branch remains stable for release while developers work on separate branches. Adding more branches can lead to multiple versions of the code being maintained, which can become difficult to manage as developers merge their changes from the development branch to the main.
Developers will need to create a release branch first, then make sure any final work is also merged back into the development branch and then that release branch will need to be merged into the main branch.
GitHub Flow
This is a simpler version of GitFlow designed for smaller teams. It doesn't require managing multiple versions, making it ideal for smaller teams. This model doesn't use release branches.
Starting with the master branch, developers create branches, feature branches, which are isolated from the master and used for their own work. These branches are then merged back into the main branch. The feature branch is deleted. This model keeps the master code in a deployable state so that it can support continuous integration and continuous delivery processes.
Pros and Cons
It is heavily based on the Agile principles, which makes it a fast, streamlined branching strategy that uses short production cycles and frequent releases. This strategy allows for fast feedback loops so that teams can quickly identify and solve issues.
If a development strategy doesn't have multiple development branches, it's more susceptible to bugs and can lead to an unstable production code if bug fixes happen in the main branch. The master branch can become cluttered because it is used for both production and development.
The model is more suited for smaller teams, and as teams grow they may experience merge conflicts as everyone is merging to the same branch. This can be problematic as developers can't see what other developers are working on, leading to potential conflicts.
GitLab Flow
GitLab Flow is a simpler alternative to GitFlow that allows for feature-driven development and feature branching with issue tracking. GitFlow helps developers create a develop branch and use that as the default, while GitLab Flow works with the main branch right away.
Pros and Cons
If you want to keep multiple environments and want to have a staging environment separate from the production environment, this is a great solution. Whenever the development branch is ready for release, you can merge back into the production branch and release it.
This strategy allows developers to maintain separate versions of software in different environments, providing proper isolation. GitLab Flow assumes that you can deploy your code into production whenever you merge a feature branch into the master branch, but GitLab Flow also allows your code to pass through internal environments before it reaches production.
Trunk-based development
Trunk-based development is a branching strategy that, in fact, doesn't require any branches. Developers integrate their changes into a shared trunk at least once a day. The trunk shared between the all of the developers should be ready for release at any time.
The key to successful Git development is to make frequent, smaller changes. This helps limit the number of long-lasting branches and avoids merge conflicts, which ensures that all developers are working on the same branch.
In other words, developers commit directly to the trunk without using branches. Feature flags are a common strategy for controlling which features are enabled in a software application. Because the trunk is always ready for release, feature flags help separate deployment from release, so any changes that aren't ready can be wrapped in a feature flag and hidden while completed features and can be released to end users without delay.
Pros and Cons
Continuous integration is a powerful tool for managing changes to a project's source code. Trunk-based development makes it easy to keep the trunk up to date, which makes it easy to test changes and ensure that the project is running smoothly.
Developers can collaborate more easily by viewing changes other developers make directly in the trunk without the need for branches. This is different from other branching methods where each developer works independently in their own branch and any changes that occur in that branch can only be seen after merging into the main branch.
Trunk-based development eliminates the stress of long-lived branches because it doesn't require branches, and merge conflicts or so-called "merge hell" because developers push small changes frequently. This will help to avoid any conflicts that may arise.
This strategy is better suited for more experienced developers, as it offers a lot of autonomy. This might be intimidating for inexperienced developers, who are interacting directly with the shared trunk. If you are a less experienced team, you may want to use a Git branching strategy.
Top comments (0)