Proposed development commit cycle

[adkinsrs]

copy/pasting from Slack conversation with @jorvis

One idea we could implement, that adheres to some traditional developement cycles and could lead to more agile development. I thought I made a discussion on this before, but can’t seem to find it.

1. Lock down the “main” branch from pushes
2. Develop strictly on a “develop” branch, or branch off of that when needed.
3. Use “develop” on the devel server.
4. When feature is deemed good, we pull request into “main”.
5. This would allow use to pull “main” periodically on a set schedule with the latest features, rather than having to manually deploy (though there are arguments for manually deploying as well). If we were developing on “main” directly, we may be blocked from deploying quicker because some feature may be broken there.

I had written in #682 that one eventual goal I would love to see with the gEAR ecosystem (and flavors) is automatic deployments, such that there’s less manual setup and configuration of packages when something changes.

Regarding using "develop" branch for pulling feature branches instead of "main"

I think the extra layer of locking down main just ensures someone does not accidentally work on main. I know I’ve personally done work on main that should have been done on a branch, just because I didn’t think about it. Gotta establish the habit first.

Another reason for using a “develop” branch is that you can test your branch locally, then push to “develop” and keep the devel server on a “develop” branch, rather than having to constantly switch branches on the devel server. Granted you could just test "main" on devel but this is all mostly a process if main is deployed on a set schedule though

The flow I was describing was really one I’ve seen for larger teams, but I think there’s still some application in our case too.

Overall, it might be considered overkill for a team of two but it’s more structured + allows for potentially quicker production releases. Copilot now can auto-write your pull request documentation which could help with changelog information for “main” as well.

[jorvis]

Some greater detail:

https://nvie.com/posts/a-successful-git-branching-model/

[adkinsrs]

cheatsheet if the "git flow" extension is installed

https://danielkummer.github.io/git-flow-cheatsheet/

based on https://github.com/petervanderdoes/gitflow-avh

[adkinsrs]

Also worth noting that unlike the "git-flow" system, we aren't really making use of release branches. I think our approach is a hybrid of git-flow and GitLab Flow