GIT correct workflow for my Branch structure

Question

I started to implement a GIT repository following a specific Workflow. The workflow is the following:

                                v0.1               v0.2 
                                 /                  / 
 releases-------------------------------------------------
/                               |                   |
main--------------------------[0.1]---------------[0.2]                   
\                            /    \               /
 development---             /      \             /
               \           /        \           /
                feature-ABC          feature-XYZ

1. main contains the latest stable code where any developer can just git checkout -> build -> deploy
2. main contains tags used to identify a release
3. Every release version is branched into release branch
4. development is the starting branch for a developer. After a commit the Build Server will Build/Deploy the solution into a development environment
5. If a Dev needs to work on a story/feature they branch from development and push back into development when done using a branch naming of feature/name or hotfix/bugname
6. When development gets stable, it is merged back into main and the release is tagged and get deployed in staging
7. a Release version is created into release

Questions

Now, in order to adopt this workflow, I created a sequence of GIT commands that a developer should execute. Can you verify the correctness?

Also, how can I ensure that main and development are always properly in sync?

First Time (assuming there is no development branch yet)

$ git checkout master
$ git branch -b development
$ git push -u origin development

Development starts

$ git checkout development
$ git branch -b feature/my_feature

... iteration ...
 $ git add ...
 $ git commit -m "My Comment"
 $ git push origin feature/my_feature
... iteration ...

Developer is done with Feature/Bug

$ git checkout development
$ git merge feature/my_feature
... resolve conflicts ...
$ git commit -m "Merge from feature/my_feature"
$ git push -u origin development

Tester approve latest Development release

$ git checkout master
$ git merge development
... resolve conflicts ...
$ git tag -a v0.1 -m "my version 0.1"
$ git commit -m "Merge from development"
$ git push -u origin master --tags

$ git checkout master
$ git branch v0.1
$ git commit -m "my version 0.1"
$ git push -u origin v0.1

Answer 1

I don't know that we can say, with 100% certainty, that these commands are "correct" for all situations, recognizing that the events in your diagram are nice and linear but development reality may not be.

Still, at a nuts-and-bolts level the only problem that jumps out at me is here:

$ git checkout master
$ git branch v0.1
$ git commit -m "my version 0.1"
$ git push -u origin v0.1

The commit will fail because it contains no changes. Although I'd question the need for the commit statement (an annotated tag probably makes more sense for what you're trying to do), if you must have a commit then you'll have to pass the --allow-emtpy argument to convince git to create one.

Answer 2

The commands can meet the work flow you plan to use. But there has some tiny things for you to refer (it's also ok to keep it as original):

1.git push with -u only need for first time push (set upstream).

2.The release versions are always exist in release branch. So you can merge main branch into release branch instead of creating branch v0.1, v0.2 etc.

To check if main and development are sync, you can use git log main..development. If it has output, that means the development branch has commit(s) need to merge into main branch.