Why not GitFlow?

[smolinari]

Hi,

I'm not a go programmer, but I have some experience with development work and was wondering if you've considered using Gitflow? Why I am asking is, 1. I noticed the master branch is the lead branch here, which is unusual. And 2. I got a "WTF", when I opened the branch picklist. Sorry, but that looks quite messy. 😃

Have a look at these explanations of Gitflow (if you don't already know what it is).

https://datasift.github.io/gitflow/IntroducingGitFlow.html https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

It allows for a much cleaner and safer developer experience, both for the core team and contributors. Basically, it would go like this (ha, pun not intended):

1. The main source code branch would be put under a dev or develop branch .
2. Developers would fork out their version of Dgraph as their own repo.
3. They'd git clone their newly created repo locally to work on it.
4. And they'd checkout the dev branch (which is normally already checked out, so this step usually isn't necessary).
5. At this point, they can either work in the dev branch or create a new feature/ bug branch from dev. The latter is preferred, especially if they work on a lot of different features or bugs at the same time.
6. Once work is done, it's pushed up to their repo.
7. Then in Github, they create a Pull Request(PR), which is reviewed by the core dev team (and any CI work can happen) and if all is well, those new changes can be merged into the core repo's 'dev' branch.
8. For releases, a release branch is created and continually merged into dev or the dev branch is merged into master directly. Either way, master gets the new release changes at that point.
9. To keep their repos up to date, any dev would create a new origin connecting their repo to the core repo. To update, they would simply "pull" in any changes from the core repo's dev branch. This updating should happen regularly too! This is quite important and is also actually an advantage. It makes sure that changes from other devs can easily be "pulled" into a dev's local development system. Once the changes are "pulled", they are pushed up to the dev's own repo on Github. This keeps the repos in sync.

This flow also allows for hotfixing (which your current workflow doesn't allow), and it makes sure the core repo doesn't get messed up inadvertently or messed up with merging conflicts (most of the time).

It sounds more complex, but it's a simpler and cleaner workflow in the end. 😄

Practically every project I work on that uses Github uses this methodology, because of its advantages.

Scott

[manishrjain]

We had tried it early on in this project. But, didn't see any particular benefits over what we're doing right now. Releases are the official way to consume Dgraph.

[smolinari]

But, didn't see any particular benefits over what we're doing right now.

Sad to hear that. You don't think a clean set of branches is a benefit? That people looking at that mess of branches might think the development of Dgraph is less than professional? Or that mistakes made are much harder to revert? Or that you can't do hotfixes to releases? Or, you can't properly work on features in parallel?

We are also not talking about "consuming" Dgraph. We are talking about development workflow.

At any rate. I'll leave it be. Good luck!

Scott

[manishrjain]

Without going into arguments over this, all of that can be had with master branch. What you're referring to as "dirty branches" are just branches which our devs are working on. Some of them surely get left behind from time to time for various reasons and get cleaned up later.

The only benefit to use Gitflow is if you need to convert master branch to the official release branch. We instead use tags and release/v* branches for that, which works well for us.

[srfrog]

FWIW I use gitflow. It's my personal choice and what works for me. The rest of the team don't need to adopt it to reap the benefits. It really comes down to what makes you more productive.

If you look at this PR, you'll see it comes from my develop feature branch - https://github.com/dgraph-io/dgraph/pull/2685

[smolinari]

@sfrog - sorry. But, because you are all working off of the master branch and even in the same repo, it isn't gitflow.

And, tagging for releases is certainly not the same as evolving a dev or develop branch over time next to a master branch.

Out of curiosity, do you do merges into master and they aren't releases? And, have you had a seriously bad bug found, which you needed to patch quickly? If you do merge features without releases and have had show stopper bugs, you should then understand the importance of not messing with the master branch for anything other than patches and releases.

Or how about QA releases? Do you test straight from master? Or do you have to test each branch singularly, before they are merged? How then, do you QA merged features/ bug fixes from different developers at the same time, without messing with master (because you need a clean master for hotfixes, right)? Do you merge feature branches together between devs? I highly doubt it. So, that means you don't have a QA. Or, you can't do hotfixes. You can't have both with your current system.

If you are happy with what you are doing and it works ,more power to you. I say though, you haven't ran into problems yet, which Gitflow helps avoid. It's simply a more professional workflow with Git. My 2 cents and all I'll argue about it, trying to sell it to you. Thanks for the discussion. 👍

Scott

[srfrog]

I think you might be overcomplicating things a bit. One of the main tenet of gitflow is to guarantee that the master branch is always deployable. With all the experimentation happening in feature branches. Important bugfixes always trump features and are handled in order of urgency. In Dgraph, no feature or bugfix is merged until a complete code review (via PR) is done with at least one person with the knowledge to verify changes. New and breaking changes require unit and system tests to maintain a consistent level of quality. Once we have reached a consistent point, we make a tagged release considering the minor or major changes. Then that package is sealed and delivered, and we move forward because that's the only direction.

TBH all the QA stuff you mention is agile stuff slopped on top. Every release we make is a production release, because we are always striving to make Dgraph better. We listen to our users, take notes, prioritize and evalutate what needs to be worked on next. Building software is hard but we always need to delivery the best we can. We don't "mess with master", because master represents the best of our work so far.

[smolinari]

It's absolutely not complex. Gitflow is simple to understand and do. And, it lowers the level of "carefulness" you must have with your master branch, which yes, means more agility in your development. Your "agile stuff" comment tells me agility in your programming isn't a concern. That's fine, until one day it bites you. I'm just suggesting, you can avoid certain problems with Gitflow, which you obviously haven't ran into yet.

Until then, happy programming! 😄

Scott