问题
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
maincontains the latest stable code where any developer can justgit checkout -> build -> deploymaincontains tags used to identify arelease- Every release version is branched into
releasebranch developmentis the starting branch for a developer. After acommitthe Build Server will Build/Deploy the solution into adevelopment environment- If a Dev needs to work on a story/feature they branch from
developmentand push back intodevelopmentwhen done using a branch naming offeature/nameorhotfix/bugname - When
developmentgets stable, it is merged back intomainand the release is tagged and get deployedin staging - 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
回答1:
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.
回答2:
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.
来源:https://stackoverflow.com/questions/43230272/git-correct-workflow-for-my-branch-structure