This later, we're going to take a look on how you can use much request and branches in order to improve
your overall kit workflow when using catalepsy.
Working with the branches is a good way of avoiding a master branch that cannot be deployed.
And we have seen previously that whenever a developer goes into a monster branch and makes a change,
a simple example was removing an import that the entire muther branch is no longer deployable.
And this is, of course, very unfortunate and it really can affect the entire work.
So the idea of working with branches is that each developer or each new feature can be deployed to a
specific branch, can be tested, and when it's ready for March, it can be merged into master back
and it can then be deployed on production.
And using this workflow really makes it much easier and guarantees that the master branch is always
deployable and this is actually part of continuous deployment.
You want to be able all the time to deploy your software.
And if the master branch isn't working because somebody has made a small mistake and everything stops
working, then this is not really going into the direction of continuous deployment and continuous delivery.
Now, there are different strategies, also known as branching models for dealing with the situation.
Gitlow is one example of them, but I will not go into details.
It's totally up to you how you want to do it and which workflow better suits your own organization.
But I would generally advise against only using the master for this.
Of course, you can make it much simpler.
Not every feature, not every bug needs to go to a specific branch.
It can be fairly easy.
Separate your workflows in a develop and in a master branch.
In develop is like the developing workflow you can break to develop and you can later fix it.
That would not be a problem and only when you're ready to make a release, you can merge all your changes
from the developer branched master.
But this is a bit a different workflow from what I wanted to show you.
I just wanted to show you a workflow where you can do as much request branches and sort of on each feature
goes into a branch.
Before we can use branches, there are a couple of things that we need to fix about our pipeline now
by default, what will happen is that if we create a new branch and push it, this pipeline will be
executed for that specific branch as well.
Now, generally, they are a couple of steps where it makes sense to execute a pipeline.
So, for example, we want to build an artifact.
We still want to build an artifact, and we still want to test if that artifact works.
And we still want to locally start the website to see if the website works.
But we definitely do not want to deploy to staging or to production from our branch or to run production
tests or something like that.
So this area here is definitely something that we do not want to do inside a branch.
And luckily, we can configure that.
We can specify that these three jobs will only be executed on M..
And this is quite easy.
I'll show you.
So by using only, we can set this policy to follow a specific rule.
So we're going to say only master.
And this will make this job only execute on Mr..
The thing we're going to do for deployed to production.
And for the production tests.
So let's now committee's changes, and after that, we're going to create the branch.
I am going back to get Lamp and I want to create a new branch.
Of course you can do it anywhere you want, but it will be much easier to demonstrate it from here.
I'll go to repository branches.
They're going to select new branch.
Let's say that we want to add a different title to our website and name it feature.
Your title.
And I'm going to create this branch for Mostro.
As soon as I've created this brunch, the pipeline will start.
And you will see that the pipeline itself is much shorter, so we don't only build a website and then
go to testing and if everything looks good, then we can say we are ready to march this branch back
into the master.