You can use regex to match all the release branches and not worry about protecting the newly created ones. In that case, release branches should be introduced and handled in the same manner as the main master branch. It is possible that, at some point, a development team will work on multiple releases at the same time. However, some projects have multiple releases planned ahead. Because of this, all changes can be merged into the master branch without the need to introduce multiple release branches. This means that all new changes should be included in the next upcoming release. Most projects have one active development stream at the moment. Also, provide a short description for the release. Git taggingīefore releasing the app on PlayStore, the release has to be tagged with the version number. That is why, for the simplicity, we only keep the master branch as the main branch and track releases via tags. Since we have tags on release commits, having a branch that only contains published code seems unnecessary. We noticed that when having both master and dev branches only one of them is used actively.
Each release is tagged with the version number as it is described in Git standardization document. All the development will be done on master branch. On most of the project we are going to use master as main branch and dev is not going to be used. There are some differences between our variant and the linked page, as it is described in Git standardization document.
We use a variant of the Git Flow workflow. Using GitĪs a part of git standardization we created this document which contains all the important information on how we are using git. Just remember to clone the repository using the SSH clone URL. That way, you can interact with private repositories without entering your username and password all the time. Before you can start using Git, you need to generate an SSH key and add the public part of the key to your GitHub and Bitbucket accounts.
0 kommentar(er)
