Our github flow

[Eslam3bed]

@NoureldeanSaed @fares98

currently, our flow is feature => staging and them to master(production) so I have two suggestions: First One: keep the branches and just change the feature branch to development to be more relative and convenient.

means that changes or fixes or new features added have to flow the flow path, started with checking out of the development branch and PR goes to the development branch as a base when things go well we take it to the staging(we make a PR from the development to staging), and this would enable few users including @MohamedTahboub to test it there.

Second One: remove the feature branch and stick with the staging branch

that same except that we will check out from the staging and make our PR to it, and every PR gets merged will be instantly deployed and we can black-box test the changes there.

I'm opened for your suggestions since this is our way of doing things

[Eslam3bed]

So @NoureldeanSaed @fares98 what do you think?

[fares98]

The first one may cause confusion and more complex between the branches. if we chose the second one we can deal with one branch only for checking out and PR, this is will be more focused and the flow will be easier.

this is my suggestion :)

[NouraldinS]

@Eslam3bed I think the safest flow would be this development (currently feature) => master (staging) => production (new branch) This means that we get to test features on development, not affecting anything Mohammed is testing on staging, nor affecting anything the users are getting on production. The way I see it, 3 branches is the sweet spot that balances between having many layers of testing between you as a developer and the client on production, and not having too many layers that it's not relevant or redundant. What do you think?

[Eslam3bed]

actual they only thing we needed the development branch that we had to make breaking changes, we also wanted to test those changes with a semi-production environment, however, this raised the complexity and error margin. so since we have finished with the development of breaking changes (the main reason for its existence), we can make the flow more robust and simple at the same time.

and about the concerns one testing it on staging which may break sometimes, I would say it was created for this ^_*, so we can simply make sure just to merge the ready and tested PR(the PR owner responsibility) to staging and if happen and we missed an edge case we can make PR with the fix.

so the flow became simple and powerful as it was setup:

any PR goes to the staging branch base, and when thins looks and works we take it to production.

PS : we will have test suites also to accumulate as we go

[Eslam3bed]

So since we have reached a common ground we will do the following:

we will delete the feature branch, any opened PR must be taken care of (either merge them or put hold/close them), and for the current tasks that you already have you can sync them with the staging.

@NoureldeanSaed @fares98 , Deal ya Bros?

[NouraldinS]

@Eslam3bed Sounds good.