What about using tags and a single trunk branch? You could use tags to denote production releases, and additional tags for marking when a development period/sprint begins. The trunk branch would be a bleeding-edge build containing the latest but but unreleased changes.
I could see it possibly making sense if you ever had changes in trunk that somehow weren't otherwise captured in long-lived branches (e.g. managing multiple minor releases like Python) and needed to backport, but that's rarely the case when you're building a product for end users, rather than a meta-product for other devs. I agree though, it's cumbersome to introduce the overhead of a release branch and PRs into it if you're never PRing it anywhere else.
In general, I don't see the point in signaling the start of something (sprint or whatever) with tags. Developers on Scrum or other approaches already know the beginning. Another moment, the beginning of the sprint can be determined by the appropriate branch. If I use a monthly approach, then no one said that it could not be extended. You can, in theory, add another line of sprints. Then sprints will be created from the monthly development branch, and task branches from the sprint branch. Further, the tasks are merged into the sprint branch, and the sprint is already into the development branch. This is also a very good approach in my opinion, but I don't like sprints themselves.
Yes, it's possible, but I have a policy of branching for later rollbacks. Also, with this approach, you can carry out several changes at the same time. For example, if you have only one messenger repository, and you decide to make 2 parallel versions (like the web version of Telegram), then branching will be a better solution.
Like most VCSs, Git has the ability to mark certain points in history as important. Typically, this functionality is used to mark the release of versions (v1.0, etc.).
One more thing, I don't really understand how a tag can be used to determine the beginning and end of a month... On the one hand, there are 2 tags, but on the other hand, why? It will not be easier to make a branch here and that's it. I prefer to use tags only as release notes.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
What about using tags and a single trunk branch? You could use tags to denote production releases, and additional tags for marking when a development period/sprint begins. The trunk branch would be a bleeding-edge build containing the latest but but unreleased changes.
+1
I still do not understand why one would want a branch only to denote releases when that's just a
git tag -naway.I could see it possibly making sense if you ever had changes in trunk that somehow weren't otherwise captured in long-lived branches (e.g. managing multiple minor releases like Python) and needed to backport, but that's rarely the case when you're building a product for end users, rather than a meta-product for other devs. I agree though, it's cumbersome to introduce the overhead of a release branch and PRs into it if you're never PRing it anywhere else.
It doesn't have to be taken at face value. Simply, my approach is to use tags in this way. Someone builds tags differently, I do.
In general, I don't see the point in signaling the start of something (sprint or whatever) with tags. Developers on Scrum or other approaches already know the beginning. Another moment, the beginning of the sprint can be determined by the appropriate branch. If I use a monthly approach, then no one said that it could not be extended. You can, in theory, add another line of sprints. Then sprints will be created from the monthly development branch, and task branches from the sprint branch. Further, the tasks are merged into the sprint branch, and the sprint is already into the development branch. This is also a very good approach in my opinion, but I don't like sprints themselves.
I should have been clearer - I meant using tags to replace the
development_MONTH_YEARbranching.Yes, it's possible, but I have a policy of branching for later rollbacks. Also, with this approach, you can carry out several changes at the same time. For example, if you have only one messenger repository, and you decide to make 2 parallel versions (like the web version of Telegram), then branching will be a better solution.
Like most VCSs, Git has the ability to mark certain points in history as important. Typically, this functionality is used to mark the release of versions (v1.0, etc.).
One more thing, I don't really understand how a tag can be used to determine the beginning and end of a month... On the one hand, there are 2 tags, but on the other hand, why? It will not be easier to make a branch here and that's it. I prefer to use tags only as release notes.