[ 2] mrjn : yeah?
[ 3] pawan : Atleast my develop is ahead of Master.
[ 4] mrjn : hehe
[ 5] pawan : With regards to squashing.
[ 6] pawan : If you pass `-S` to squash commits, then it doesn't create a merge commit and has just one commit which is squashed commit representing all commits.
[ 7] mrjn : doesn't create merge commit in master?
[ 8] pawan : Anytime you pass `-S` it creates one squashed commit.
[ 9] mrjn : got it.
[10] mrjn : So, what's the flow here?
[11] mrjn : you write this feature. Then do feature finish or something.
[12] mrjn : and it's supposed to integrate it with develop.
[13] mrjn : But, it would squash it?
[14] mrjn : What happens when the same branch gets merged into two branches (master and develop)?
[15] pawan : When you do `git flow -S feature finish improvement`
[16] pawan : It squashes all commits in feature branch and has one commit in develop.
[17] mrjn : and for hotfix?
[18] pawan : I think we shouldn't squash hotfixes and release branches.
[19] mrjn : ok
[20] pawan : I will create a discourse topic around this, better that we discuss this there.
Recently we observed that on Dgraph repo, develop was behind master after doing a hotfix. I realised that the way the original git flow tool works, this would always happen.
Came across Git flow AVH which is being actively developed and improves upon the original tool. Trying it out for Gru. It explicitly back merges the tag to develop to avoid master getting ahead of develop during a hotfix or release.
Since we like to squash commits from feature branches before merging to master, we could use
git flow feature finish -S graphql.
While creating a release we could do. We shouldn’t squash while we finish a release or hotfix, as we don’t get the merge commit when we squash.
-s will make sure our tag is signed too.
git flow release finish -s 0.1.0
3 Likes
@pawan It seems good, and would solve the issue that we were discussing the other day (develop behind master).
I would however raise two points to discuss here.
-
Do you need an additional tool? As @mrjn and yourself have (rightly) pointed out it hampers learning.
-
More importantly, do you even need gitflow for Dgraph – it seems unnecessarily complex for a not-always-on-unlike-webservices software has a single supported trunk and no need for hotfixes pre-release.
I would highly encourage you to create the mental model of the release process you want for Dgraph – which would change in the future as the complexity of the software increases and then pick the tool to assist you in that, if needed and the tools works well for YOUR model rather the other way around.
I would say for pre-release Dgraph this hierarchy of git branches along with release tags should work well.
---- Master
|
V
|
V
|
---------------------------------- Develop---------------------------------
............|.................|...........................|
............V.................V...........................V
............|.................|........................Bugfix1
............V.................V
............|.............. Feature2
............V
........Feature1
Where
master is the branch pointing to the lastest stable release.
develop is the feature integration branch.
FeatureXXX/BugfixYYY is the bug fix(es) and the features being worked on in parallel for the upcoming release.
All the push go from bottom to top and all the pulls go from top to bottom. It gives you the following abilities
- Multiple features/bugfixes being worked on in parallel.
- Along with release tagging the ability to map releases with commit version.
Limitations
- Feature/bugfix specific release cannot be done. Which means no urgent hotfixes mid release cycle, which I would argue is not needed pre-release anyways.
- Development has to be frozen during release. This shortcoming however can be bypassed by taking a release branch off
develop.
Again, I’d suggest figure out the model first. Tools (or no tool) is the easier part of engineering.
Interesting point @mohitranka.
Regarding if we need the tool or not, I would say once you know what happens under the hood, using the tool makes your life easier.
From what I understand, the model mentioned by you doesn’t have release or hotfix branches. I get your point about not doing hotfixes and agree that develop should be tested thoroughly before pushing doing a release. Though sometimes after a release has been made a hotfix might be necessary . That would mean a bug specific release has to be made.
Gitflow doesn’t have the limitations you mentioned. We obviously don’t have to use hotfixes, but they may come in handy once in a while. Also, there is no reason to freeze development during release.
Bugfix releases are not hotfixes. A hotfix preempts the scheduled release cycle to do changes directly to master – typically to handle urgent bug fixes, typically only happen for security/P0 issues for for binary packages and “business priorities” fixes for webservices.
Any major feature release contains bugs. That is bug fix releases are planned, for example python 2.7.0 was released on July 2010 and since then 12 planned bugfix releases have been made latest being python 2.7.12 on 25th June 2016.
Limitations in the solution are not bad necessarily, as features come at the cost of increased complexity. Do you need the features for your requirements to justify the avoidable complexity?
Again, I’d repeat model your problem, find a solution that solves that problem and then find a tool that implements that solution well, rather than try to retrofit the tool to the problem
My $0.02
@pawan – You’re the decision maker here. Below is my advice.
So, if I understand this right:
- We use 2 branches: develop and master.
- When we cut a release, we go from develop to master straight away.
- Any hotfixes go to master.
- I suppose the idea here is that between two releases, we won’t be doing any bug fixes based on master head. Which seems like a reasonable assumption at this point. So, we can probably get rid of the hotfix branches.
- That leaves us with release branch. Again, given we’re pre-v1.0, we can just move from develop to master straight away and do our testing there. It’s not really clean, but it should be alright – given we expect our users to download binaries, not compile from master.
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.
Tried to understand what flow other Open Source projects follow. CockroachDB and CoreOS guys don’t have a master, develop split. Infact they don’t really follow Git flow as such.
CockroachDB
- Feature/bugfixes/hotfixes branch from master and merge into master.
- Releases are tags on a commit on master.
- Some PR’s are merged after squashing from Github UI(not strict about verifying commits), some without squashing.
Cons - As far as I understand, PR regarding new features can’t be merged when a release is being done. Also one must ensure that everything that’s merged into master is well tested. Since they release binaries for every platform, users usually won’t clone the repo. Hence, not a big problem even if master is broken for a while.
Core OS
- They also don’t follow any Git flow as such. From what I understand, they follow something similar to http://endoflineblog.com/follow-up-to-gitflow-considered-harmful where they have a master and a release branch. The release branch is mainly just a pointer to released tags.
I am sure that its possible to get rid of develop. Infact, yet to find open source projects which follow Git flow. It also masks all the development that’s going on. Since most users can try out the binaries, it shouldn’t be a problem even if master is broken for a while.
1 Like
CockroachDB guys don’t sign their commits, either. I’m not a big fan of their flow – but you do have a good point that we might not really need git flow, given we’re doing releases. Also, anyone can download the code up to a released version via the zip files.
Given we’re trying to do a release every 2 weeks now, this should make our workflow a lot easier. We can just create a release branch, do any required changes there, and merge them back to the master. This way, master won’t have any freezes.
Is that what you’re thinking as well?
Yes, and the final commit corresponding to a release can be tagged on the release branch before merging to master. This way the tag would be a pointer to a release.
Similar can be done for a hotfix. Tag the final hotfix commit before merging to master.
Do we even need to do tagging? Isn’t that unnecessary if we’re doing the release branches. We can keep the last few branches around, and then delete them in a couple of months.
Also, if we’re going to get rid of develop, then maybe we should do it sooner than later.
Hmm, tags here just play the role of a reference point to releases(which is just a commit). They remain even after you delete the branch(hotfix/release). I feel tags are an easier way to checkout code at any point compared to branches.
Maybe we can get rid of develop when we do the release on Thursday after bringing master in sync with develop?
The problem that I see with tags is this:
- Release branch is cut.
- Testing on release commences.
- New features are added to master.
- Release branch if finalized and tagged.
- Release branch is merged back to master.
When the final merging happens, and in case we delete the release branch, I doubt if the tag would still be valid. For the tag to be valid, it would have to come from master itself.
Makes sense!
Nope, the tag remains and has the state at that point. Learnt that from the endoflineblog link that I shared above. So both hotfixes and releases can be tagged on the corresponding branch. Also verified it myself.
1 Like
Dave Cheney also recently requested Gophers to tag their releases http://dave.cheney.net/2016/06/24/gophers-please-tag-your-releases
1 Like
I’m in favour of emulating the core Go repo style of development. master should be best-effort stable, at least until Dgraph is 1.0. Long-term, risky, incomplete or changes being considered are the kinds of things done in branches at dev discretion. The model of branching for releases is excellent.
This is what I’ve adopted for all my personal projects. It has the least friction with new users, one-time contributors, and I believe captures the most important elements of DVCS without hassle.
Someone mentioned switching to a model like this at the next minor release, I think that’s ideal.
2 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.