Create dev branch that can be pushed to from Graphite

[GoodM4ven]

I'm not able to set up Graphite to work with a dev branch for some reason...

[ghost]

Didn't we literally just do it in Crafty#18 ? I just had to checkout main, do some changes, create into "[v?.?.?] Somehting", and the gt rename "dev", and then submit!

You noticed that it also didn't ask us to remove the branch after the merge, right! So basically, I could keep working on it; checking it out then doing my creates and then back and sync and so on...

Someone else's problem would be to figure out how we eventually ALL sync with main though! XD

[GoodM4ven]

That's because of the protection rules that are set on the repo's dev branch with a "naming pattern" in advance... Let's see though if you're right about it.

[GoodM4ven]

Yeah, we can use gt track dev in case it was removed locally... I'm not sure what to come though!

[GoodM4ven]

Okay, it seems like the only thing left was to do git push origin dev after rejecting the removal of the dev branch during gt sync.

[ghost]

You had the IDE circle or whatever icon in version control gone? @GoodM4ven

[GoodM4ven]

Yes. @Haaabeeel But I'm not sure what's next.

Maybe you could commit and see how it goes.

[ghost]

Hmm.. It seem that it keeps insisting on deleting the dev branch (locally) and rebasing off of main (making it the parent) BEFORE allowing us to gt submit. It's ridiculous but it leads me to think that they wanted us to have anything other than a main branch!

Any idea if this is the correct behavior? @dovudwkt Or is the standard to always have a dev branch?

[GoodM4ven]

I'm going to remove the restriction rules for dev branches, just in case they'd cause you guys trouble till you find out how to do it.

[dovudwkt]

Hmm.. It seem that it keeps insisting on deleting the dev branch (locally) and rebasing off of main (making it the parent) BEFORE allowing us to gt submit. It's ridiculous but it leads me to think that they wanted us to have anything other than a main branch!

Any idea if this is the correct behavior? @dovudwkt Or is the standard to always have a dev branch?

I'd say it is indeed a defacto standard to have a develop branch which by default is reserved as 'dev' on GitHub, based on your observation.

For non open source production projects the flow is dev -> stage -> main. The branch names may vary... For every new feature we checkout from develop and merge into develop once changes approved. When we are ready to create a release, we merge develop into stage and then main. Most likely in this case we don't need a staging environment, however, we could benefit from this flow and I suspect it would resolve the issues with Graphite, yet to be tested...

I know it's obvious and nothing new for you, but I'd like to better understand the flow you guys follow in this repository and whether my suggestion even makes sense for this project?

[ghost]

Yeah, we'd like to implement such a feature->dev->main flow. But what I mean is that technically Graphite doesn't allow you to rely on a branch which has its content already merged into its parent and it calls it "empty" and prompts to delete it before creating anything on top of it and it throws a 400 error or something.

When you're ready, try to create to create a new organization public repo for testing, integrate it with Graphite, and try to experiment around with the same flow and you'll catch what we mean. @dovudwkt

[dovudwkt]

Aha, I see what you mean. Thanks for clarification! I'll play around with Graphite and see what can be done to resolve the issue.

[GoodM4ven]

Hey, guys. Just received this email. Figured it'd be useful?

[ghost]

A tip over here too: Graphite has gt aliases concept, where it can hold ordinary git commands (a set, I guess) into a new gt command.

So we need to find out if we're not going to be able to do Graphite for branching continuously on anything other main, then we can do that, or do the counterpart of that in git, then turn those "steps" into a new gt command, and share it with the team.

[dovudwkt]

Graphite follows a trunk based approach that encourages the developers to merge into a single main branch, unlike the git flow approach where we have long lived branches such as develop and release. See Trunk based development.

Solution In order to have a dev branch to which we can push the stack of PRs, we need to update the trunk branch to dev. Then we should not have any issues syncing as well. It will not prompt to delete the dev (which is trunk) branch either. See Developing on multiple trunks.

[dovudwkt]

Now the question arises: what is a suitable flow for this repository? In my personal opinion the trunk based approach with a single main branch and multiple short lived branches for PR stacks would work just fine. The GitFLow with develop and release branches are useful for deployable code that can be deployed for each of those environments and tested, which is not the case here.

What do you think @GoodM4ven @Haaabeeel ?

[ghost]

We've set up a webhook to push to packagist (which is where each of our composer packages is hosted) on every "release" (which is supposed to be very stable; main). However, we might need to modify it so that it would also have dev versions for testing or something... Right, @GoodM4ven ?

[GoodM4ven]

Yep, yep, yep! Thank you kindly, @dovudwkt for the valuable INTEL. I'll start trying it out.

Just like what @Haaabeeel has mentioned, we need to figure out how to composer require a specific dev version for testing the package when it's in dev and before pushing it through the UI here on Github to main once it's stable.