3 ms·

What are the pros and cons of branches+merge-commits vs tags? So instead of a "v4.11-rc7-87" tag you would have a "v4.11-rc7-87" branch and a merge commit that

by TekMol 4y ago

What are the pros and cons of branches+merge-commits vs tags? So instead of a "v4.11-rc7-87" tag you would have a "v4.11-rc7-87" branch and a merge commit that holds the meta info about that branch.

da-x 4y ago
These are not mutually exclusive. Tags relate to commits irrespective of the containing branch or the merge history.
Hackbraten 4y ago
Branches are mutable, tags aren’t. You can add a commit to `v4.11-rc7-87` anytime. Now your branch has grown past the merge commit. Confusion ensues. Compared to a tag, you’d have to deliberately go out of your way to move a tag (`git tag -f`). Generally, you should be able to trust your team members not to move a tag.
WorldMaker 4y ago
Annotated Tags hold meta info for the tag. (git tag -a) That's why a lot of advice is to always use annotated tags. They look like a commit with an author, a message, and can be signed, etc. Branches can change over time, whereas tags are largely immutable. A change to a tag always requires a force push and if you've got branch protection tools in your repository host's arsenal you can often entirely prevent tag changes. I'd also like to point out that often if you are using merge commits as your "version management tool" there's a lot of people that use "branch per environment" strategies and need to merge between environments. There's a lot more risk in that approach than a tag-based approach: if a tag doesn't change after it is applied, then you don't need to rebuild binaries to deploy it again. If you don't rebuild binaries between environments you have to make sure the same binaries work in all environments, which is good practice. I've seen too many times "branch-per-environment" strategies wind up with per-environment code that is difficult to untangle and makes testing and debugging difficult and merge conflicts more likely and more complicated and increases the risk of per-environment bugs.
ww520 4y ago
They are for different purposes. Branch is for working on the code. Once done, use tag to snapshot a release. The branch can move forward as needed.
da-x 4y ago
The tag in the repo is `v4.11-rc7` not `v4.11-rc7-87`. The `-87-g28cf22d0ba28` suffix is added by `git describe`.

by TekMol 4y ago

What are the pros and cons of branches+merge-commits vs tags? So instead of a "v4.11-rc7-87" tag you would have a "v4.11-rc7-87" branch and a merge commit that holds the meta info about that branch.

da-x 4y ago

These are not mutually exclusive. Tags relate to commits irrespective of the containing branch or the merge history.

Hackbraten 4y ago

Branches are mutable, tags aren’t. You can add a commit to `v4.11-rc7-87` anytime. Now your branch has grown past the merge commit. Confusion ensues. Compared to a tag, you’d have to deliberately go out of your way to move a tag (`git tag -f`). Generally, you should be able to trust your team members not to move a tag.

WorldMaker 4y ago

Annotated Tags hold meta info for the tag. (git tag -a) That's why a lot of advice is to always use annotated tags. They look like a commit with an author, a message, and can be signed, etc. Branches can change over time, whereas tags are largely immutable. A change to a tag always requires a force push and if you've got branch protection tools in your repository host's arsenal you can often entirely prevent tag changes. I'd also like to point out that often if you are using merge commits as your "version management tool" there's a lot of people that use "branch per environment" strategies and need to merge between environments. There's a lot more risk in that approach than a tag-based approach: if a tag doesn't change after it is applied, then you don't need to rebuild binaries to deploy it again. If you don't rebuild binaries between environments you have to make sure the same binaries work in all environments, which is good practice. I've seen too many times "branch-per-environment" strategies wind up with per-environment code that is difficult to untangle and makes testing and debugging difficult and merge conflicts more likely and more complicated and increases the risk of per-environment bugs.

ww520 4y ago

They are for different purposes. Branch is for working on the code. Once done, use tag to snapshot a release. The branch can move forward as needed.

da-x 4y ago

The tag in the repo is `v4.11-rc7` not `v4.11-rc7-87`. The `-87-g28cf22d0ba28` suffix is added by `git describe`.