Question on using "Git flow"

Hello,
at my work we use the actual "Git flow".
Basically you have a "develop" branch beside the master branch.
You work on a feature branch, which is based on the develop branch and pull requests goes to the develop branch.
Then at release time develop is validated, and merged to master (and master is validated too).
(I simplify, develop is validate all the time).

I suppose it is too late to change this, but I find that easier rather than having everybody forking the whole repo + managing its maintenance.

 

It's never too late and I was considering it.

However, if we create a

develop

branch on the official repository, you would still have to fork it. Or did I misinterpret it?

The other thing is that whoever already forked, on their PR, would automatically push to

master

for now, at least on their first PR. Which means we'd have to say a few times "Push to

develop

please". Might be ok.

 

After a bit of consultation, we decided to stay the course and keep

master

as our main branch, and merge PRs there. At the end of the day if you think about it, all of the

master

s on the various forks are basically development branches and we have the PR mechanism to protect the main branch.

Later on we might spin off a `release` branch on which we put milestone builds? That was always the plan.

 

Juste to be sure we are on the same page, I'm talking about the git flow process as described here: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

Some tools like Sourcetree integrates this process in their UI.

"However, if we create a develop branch on the official repository, you would still have to fork it. Or did I misinterpret it?"
I wonder if you do not confuse "fork" and "clone".
With this process everybody will have to clone the repo, but not fork it.
The idea behind my proposal is precisely to avoid forking the repo.

But after writing my post I realised that with many people working on the same repo it may quickly become a mess with so many feature branches, etc ...

Yet I'm afraid that merging to master (even with a PR and code review, especially at the beginning with no unit tests), you may break the master, which should be stable at all times.
While with an intermediary develop branch (tested & validated before going to master) , you may break the develop branch, but not the master branch which stays safe.

 

I think we'd work on feature branches on our forks anyway. Then we'd be creating PRs from our feature branch to the upstream project's `master` or the `develop` branch. If we commit directly into fork's master, our master branches would get deviate from the origin's master, which is a problem.

 

We really can't avoid having people fork the repo. Avoiding that means giving everyone writing rights to the repo, which would result in a big mess

I know, but:

And then it would be the same as potentially breaking master, but not breaking the release branch.