And a video:
And a video:
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
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.
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.
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.
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
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.
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: https://www.git-tower.com/learn/git/ebook/en/command-line/advanced-topics/git-flow
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
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.