Your assumption was correct I think, that this is just a language issue. Let me try to help. Keep in mind there can be many different ways to use branches. I will give just one illustration. But you can do things differently.
Assume we have 2 branches:
MAIN
DEV
Assume we have 3 environments:
Test
PreProduction
Production
Assume we have a workflow like this:
Developers work in 2-week sprints. During the sprint, developers check in changes that are being developed into the DEV branch. There is a build for the DEV branch that is triggered on every check-in. It compiles the code and runs unit tests. We name it "Product X DEV CI" to make it obvious to everyone that this build is associated with code in the DEV branch. The "CI" indicates "Continuous Integration" to indicated it is triggered on every check-in. We have a second build on the DEV branch, named "Product X DEV Nightly." Every night at midnight, ththise Build on the DEV branch builds the software on the DEV branch, and releases the results to a Test environment.
Once the Sprint is over, QA staff and customers review the resulting software. If it passes QA and User Acceptance testing, developers merge the code into the MAIN branch, and check it into the MAIN Branch. There is a build for the MAIN branch that triggers automatically. We name it "Product X MAIN Nightly" to clearly indicate this build is for code in the MAIN branch. Every night, a release is automatically generated for whatever is in the MAIN branch, deploying to PreProduction. There, further, more stable testing can occur.
Finally, when all is OK, you can manually trigger a release on the MAIN branch to production. You need a release definition for that, but not necessarily a special build.
Notice in this story that we name the builds on the Dev branch for the branch of code they are building. Example: "Product X DEV CI" or "Product X DEV Nightly." We are naming the build for the branch, just as described in the words you copied from the manual.
You could flip the words around and say you have "one branch for each build." But thatimplies that the build is chosen first, then we make a branch to match it. In contrast,, I would recommend you first design your development workflow, and design branches to support it, and finally, design builds to support CI and your release strategy. Also, as illustrated, we may often have more than one build on a particular branch. But it would be unusual to have more than one branch in a build.
To say "we name branches for builds" is sort of like saying "we name children for their birth certificates." Actually, we name the children first, then we name the birth certificates to match the children. Similarly, we first decide on our branch strategy. Then we name our builds for our branches.
Assume we have 2 branches:
MAIN
DEV
Assume we have 3 environments:
Test
PreProduction
Production
Assume we have a workflow like this:
Developers work in 2-week sprints. During the sprint, developers check in changes that are being developed into the DEV branch. There is a build for the DEV branch that is triggered on every check-in. It compiles the code and runs unit tests. We name it "Product X DEV CI" to make it obvious to everyone that this build is associated with code in the DEV branch. The "CI" indicates "Continuous Integration" to indicated it is triggered on every check-in. We have a second build on the DEV branch, named "Product X DEV Nightly." Every night at midnight, ththise Build on the DEV branch builds the software on the DEV branch, and releases the results to a Test environment.
Once the Sprint is over, QA staff and customers review the resulting software. If it passes QA and User Acceptance testing, developers merge the code into the MAIN branch, and check it into the MAIN Branch. There is a build for the MAIN branch that triggers automatically. We name it "Product X MAIN Nightly" to clearly indicate this build is for code in the MAIN branch. Every night, a release is automatically generated for whatever is in the MAIN branch, deploying to PreProduction. There, further, more stable testing can occur.
Finally, when all is OK, you can manually trigger a release on the MAIN branch to production. You need a release definition for that, but not necessarily a special build.
Notice in this story that we name the builds on the Dev branch for the branch of code they are building. Example: "Product X DEV CI" or "Product X DEV Nightly." We are naming the build for the branch, just as described in the words you copied from the manual.
You could flip the words around and say you have "one branch for each build." But thatimplies that the build is chosen first, then we make a branch to match it. In contrast,, I would recommend you first design your development workflow, and design branches to support it, and finally, design builds to support CI and your release strategy. Also, as illustrated, we may often have more than one build on a particular branch. But it would be unusual to have more than one branch in a build.
To say "we name branches for builds" is sort of like saying "we name children for their birth certificates." Actually, we name the children first, then we name the birth certificates to match the children. Similarly, we first decide on our branch strategy. Then we name our builds for our branches.
