![]() ![]() Furthermore, they allow for minor bug fixes and preparing meta-data for a release (version number, build dates, etc.). They allow for last-minute dotting of i’s and crossing t’s. Release branches support preparation of a new production release. This avoids losing information about the historical existence of a feature branch and groups together all commits that together added the feature. The -no-ff flag causes the merge to always create a new commit object, even if the merge could be performed with a fast-forward. The essence of a feature branch is that it exists as long as the feature is in development, but will eventually be merged back into develop (to definitely add the new feature to the upcoming release) or discarded (in case of a disappointing experiment).įeature branches typically exist in developer repos only, not in origin.įinished features may be merged into the develop branch to definitely add them to the upcoming release. When starting development of a feature, the target release in which this feature will be incorporated may well be unknown at that point. Feature BranchesĪnything except master, develop, release-*, or hotfix-*įeature branches (or sometimes called topic branches) are used to develop new features for the upcoming or a distant future release. They are of course plain old Git branches. The branch types are categorized by how we use them. ![]() We will walk through them in a minute.īy no means are these branches “special” from a technical perspective. The different types of branches we may use are:Įach of these branches have a specific purpose and are bound to strict rules as to which branches may be their originating branch and which branches must be their merge targets. How this is done in detail will be discussed further on. When the source code in the develop branch reaches a stable point and is ready to be released, all of the changes should be merged back into master somehow and then tagged with a release number. This is where any automatic nightly builds are built from. Some would call this the “ integration branch”. We consider origin/develop to be the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release. We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state. The central repo holds two main branches with an infinite lifetime: Does that image look complicated? Click on the image below if you’d like to watch a quick video using Gitflow inĪt the core, the development model is greatly inspired by existing models out there. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |