Git, Gitflow and the develop branch. Let's continue to understand the basics of programming

beeline cloud I share my personal experience of development. I told you earlier, how to inject into static fields, How to Make Your Life Easier When Writing Testshighlighted the features pagination. And today I will continue to introduce you to Git, Gitflow and the develop branch. If you missed the first article in the series, I recommend reading it here.

full rest application on spring boot

Let's use our imagination – let's imagine that we have a requirement to implement a certain functionality. Let's say we need to implement a full rest application on spring boot. As we understood from the text above, the master branch cannot be used for development. There are others for this.

But the main development branch in Gitflow is usually called develop. It contains code that is in development and not ready for release.

And if you are a developer working on new features or fixing bugs in a project, it will be your main branch. This branch allows you to create new changes, test them, and integrate them into the project gradually.

Gitflow recommends using the develop branch for the following purposes:

• Development of new functions

• Error correction

• Testing and debugging code

When changes in the develop branch are ready to be released, they can be merged into the master branch to ensure the stability and reliability of the project.

How to create a develop branch

Everything is simple here – you need to execute the following command:

$ git checkout -b develop

You can also create a branch in one of the services described above.

To do this, open the branches and click “+” opposite the branch from which we want to create the develop branch.

Enter the branch name and click the create button:

Now we have two branches, the main master for the stable product and develop for development:

Screenshots taken on the site https://gitverse.ru/ but the process of creation through the service is identical on other similar services, for example on https://bitbucket.org/ .

If you have previously created a branch in the service, you should switch to the develop branch locally in the project folder. To do this, run the command:

$ git fetch && git checkout develop

However, for the development of a simple service, if it is handled by one developer Ivan, these two branches will be enough.

We make changes to the project

Let's imagine that we have a new requirement: we need to implement a GET /api/hello endpoint that will return a response in JSON:

 ```json
{
“answer”: “Hello, world”
}
```

Having implemented the current functionality, we must commit all changes and upload them to the remote repository. To do this, execute the following commands sequentially:

We index the changes that have been made

$ git add

Commit

$ git commit -m “add /api/hello endpoint”

Let's upload it to the remote repository

$ git push

After uploading the code to the repository, we will get the following image in the IDEA IDE:

These changes can be seen in a web browser when using one of the remote repositories (on the screen https://gitverse.ru/):

Next, we will transfer all the changes to master. This can be done by creating a merge request. It is also called a merge request or pull request:

And this merge request can be confirmed, ultimately obtaining the following result:

Now all changes are in the master branch.

There are many developers, and many changes. What to do?

When there are several developers in a team, and each of them makes a change, applying them all in one branch becomes inconvenient. For example, changes from the develop branch should go to the testing server, and this branch should not contain changes that are not yet completed or are in development. For this purpose, Gitflow has adopted a standard for branches called feature.

A feature branch is a temporary branch in Gitflow used for the following purposes:

• Development of new function

• Error correction

• Testing and debugging code

In other words, the feature branch is used to develop a specific feature or bug fix. It allows you to work on a feature independently of other changes in the project. And it contains only those changes that are related to a specific feature or bug fix.

Then, when you finish developing a feature or fixing a bug, those changes go into the develop branch so they're included in the main development flow and available to other team members.

How to use the feature branch

Gitflow recommends using the feature branch as follows:

• Create a temporary branch to develop a new feature or fix a bug.

• Developing and testing changes in this branch.

• Merge changes into the develop branch so that they are included in the main development flow.

Hello, Masha, or how to work on different features

Now let's imagine that developer Masha has joined our team. Together with Ivan, they must work on two different features at the same time. Each of them has created a branch for themselves:

 $ git checkout -b feature/ivan_feature develop

Masha doesn't have a local repository yet, so she clones it for herself. This can be done with the command specified in the Git service itself:

And then creates a new branch:

$ git checkout -b feature/masha_feature develop

This command allows you to create a branch from develop and switch to it immediately.

You can do something similar through the web interface of the Git service you are using, as described above when we created the develop branch from master.

But then it turns out that Ivan needs to modify the service so that the /api/hello endpoint he created returns the user name, which is passed in the URL parameter “name”.

In this case, Masha needs to create a second version of the /api/v2/hello endpoint, which should return a greeting and question in JSON.

```json
{
“answer”: “Hello my name is bot”
“question”: “How can I help you?”
}
```

When the code is ready, developers upload it to the git repository and create a merge request in the develop branch, similar to the merge request we made above when we created a merge request from develop to master. After the merge, the code gets into the main development flow – it is available to other project participants.

When both developers finish their tasks and their code gets into the develop branch, it will be available to each of the developers. But if Ivan's code gets into the develop branch earlier, testers can start testing this code without waiting for the improvements that Masha releases. Masha's improvements are in a separate branch and will not affect the stability of the code that is in the develop branch.

That's all I have for now. In this part, we dived into team development. In the next article, we'll learn how to output code consisting of modifications from all our developers, we'll understand releases, and we'll also understand what to do if developers have made modifications to the same file and encountered a conflict when merging.