And a video:
1 Like
Yeah, used to follow this at my previous company. Letās follow this from now on for future features.
Whatās your opinion about it? Useful?
Actually not really sure about having develop and master both. Read this interesting article about some criticism of Git flow http://endoflineblog.com/gitflow-considered-harmful.
Naming branches with the feature, release, hotfix gives more context so I like that.
Funny he doesnāt like --no-ff, which to me was pretty convincing. It would avoid us having to squash our commits explicitly, from what I understand.
The --no-ff flag causes the merge to always create a new commit object,
even if the merge could be performed with a fast-forward.
I donāt think it will do that. All the commits made in the feature branch would be retained in the master branch on merge if we donāt squash our commits explicitly.
Btw merges on Github are -no-ff. Hence they always end up creating a merge commit even if fast forwarding is possible.
1 Like
I have been using this model for last couple of years. Only issue is handling codereviews as there is no explicit step for it, especially if you use a third party tool (eg. Github PRs) for doing them, so you end up tweaking it to incorporate the additional step.
1 Like
I think itās a norm to create PRās for pull requests to the develop branch from feature branches. Develop has stable code always, which can be merged to master by creating a release. Do you follow something else?
Not sure of the benefit of having the develop/master split.
1 Like
This is mostly correct. Typically this is how it goes with different kind of branches.
feature/hotfix - They contain a unit of work, either new functionality or refactoring or a bugfix. At the completion, the work is developer tested and code reviewed.
develop - This is the baseline of all development work (except hotfixes), not stable and used for integration of ALL development work. All feature branches are forked from this, and merged back to develop. QA testing happen here and automated nightly builds can be made from this branch.
release - This branch is optional based on the release philosophy and bandwidth of the team. To keep the release process not block the usual development process, a release fork is taken from the develop (which is being continuously altered with new features) and a final round of functional and performance testing done here.
master - This is the pristine, stable production branch, which is used by the clients/users. All work related to QA testing, automated builds etc. on develop and release branches are done to ensure that the quality of master stay high.
@pawan, I hope this clears a few bits about traditional release process.
2 Likes
This process looks like an interesting approach ā and seems very relevant to Dgraph. Just yesterday, nii236 sent me this PR:
Because our master has moved on to new binary name dgraph, while our release still uses the old binary name server. Using Git flow would avoid this particular problem - and also make releases easier.
Also came across this nice intro: Workflows with git-flow | Learn Git Ebook (CLI Edition)
Yeah right , things would only be merged to master when a release is done. Develop would contain the latest code , so yeah git flow would have avoided the wastage in effort in this case.
It could also have avoided the issue other day where a bug was pushed to master after the net/trace PR.
1 Like
Iāve used the git-flow branching model before and I found it very useful, specially because it keeps things organized. Having master containing the release versions, develop is the source for new/current work. It adds an extra layer for checks where your CI could be running every time thereās a change in the current develop, before making it to master for a release.
2 Likes