![]() ![]() If your change is targeting any upcoming release and doesn't meet the criteria for a hotfix, it should be in one of these branches. Note that the section of the page linked to in the question about feature branches even says that feature branches are "sometimes called topic branches". In general, critical hotfixes should be an exceptional case. Using these should be the exception rather than the norm for a development team. The purpose of a hotfix branch is to let someone get critical changes into production very quickly without interfering with ongoing development. with gitkraken there doesnt seem to be any mentions on this in the manual. When you use the git-flow scripts this happens for you automatically. If your fix isn't critical, then a hotfix branch doesn't seem to fit either. Using gitkraken with a gitflow-enabled repository and trying to figure out how to finish a feature branch in such a way so as to also delete from remote that feature branch if it exists. If you're active in cleaning up your branches (which I think that everyone should be), then this isn't even an option. Once a release is merged into master and tagged there, the release branch for that particular release has outlived its purpose and doesn't necessarily need to exist anymore. The software has already been released and is in master. In your particular case, a release- branch isn't an appropriate place. I would be opposed to any commits directly into one of these branches, although it appears that Gitflow by itself doesn't have any problems with committing pre-release bug fixes or changes directly into the release branch and then pulling them into development and then feature branches. This ensures that every change is code reviewed, along with ensuring appropriate test coverage and passing tests in a CI environment before changes go in. The feature- branches are for development of individual features for some future release.Ĭoming from environments where PRs are used and aside from an individual developer committing to a feature branch, nothing should be committed directly into master, develop, or a release branch. The hotfix- branches are specifically for critical, out-of-cycle releases into production. The release- branches are made to draw a line for a particular release and then support bug fixes between the identification of the next version and the release. The master and develop branches are long-running branches and you do not commit directly into them. Gitflow has five branch types: master, develop, hotfix branches (prefixed with hotfix-), release branches (prefixed with release-, and feature branches. How you name feature branches or these branches for bug fixes is up to you and your team's standards, but they should be treated identically if you are following Gitflow.īart van Ingen Schenau's comment brings up a good point. The short answer: Yes, branches for bug fixes that are going into a planned upcoming release should be in feature branches.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |