Here I understand with Git and such a question ... We have local branches and remote ones.

The remote one is called master by default and I created another local one and called it develop .

Now I need to develop a new feature and I create another local branch and call it a feature , I do everything I need in it, and when I realize that everything is ready, I merge it into a local develop branch and delete it.

And what happens is we have a local branch develop with a new feature and a remote master branch that does not know about the changes ...

But I’m not able to merge the develop branch into the master as I’m merging the release versions into the master, so I need to create another remoteDev branch remoteDev and merge all changes into it, and when everything is tested, then this remoteDev branch remoteDev merged into master and get a release ...

Do I understand correctly? I just didn’t use git before ...

  • four
    You absolutely no one bothers to keep develop remotely. And do not call it remoteDev. Moreover, keeping lots of branches is normal. Even more. We need a new feature - we made a branch, registered it, started the branch remotely. Continue to work in the branch and push into it. And death in this case will be possible from another machine. Even a different person. And if the branches are kept only locally, then they are easy to lose. - KoVadim
  • one
    There is a bit of literature listed in the git tag description . pay attention to the “successful branching model” manual. - aleksandr barakin
  • remembered an article on branching in git nvie.com/posts/a-successful-git-branching-model - while1pass

1 answer 1

If you understand the question correctly, you have doubts about the merging of branches and their interaction. But your thoughts go in the right direction. In the simplest case, it looks like this:

 локальные ветки - master (релиз), develop... удаленные ветки (на сервере) - master (релиз), develop...

But no one forbids you to do more branches, especially in a good tone for any fix (or new functionality, or release) to make a separate branch and check its performance in it.

All changes, new features, bugs should be carried out through the develop branch, since the master is considered stable in any commit. Only ready releases with tested functionality, well, or urgent bugs are sent to the master branch.

Merging branches on the server is a bad tone, as conflicts may arise. Conflicts should be resolved in local repositories.

Work in the simplest case looks like this. You make changes to the develop branch (for example, you have added new functionality that you are sure of), merge it with the main master branch (create a release) and send it to the test server (test version of the site) for verification. On the test server, you change the changes and check if the working capacity suits you, then you can send the master to the main server.