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.
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.