search

AnalogIO / coffeecard_app

Cross-platform coffee card app for Cafe Analog
https://www.cafeanalog.dk/app
MIT License
6 stars 1 forks source link

New strategy for branches, commits, and releasing #474

Closed marfavi closed 8 months ago

marfavi commented 1 year ago

This proposal outlines a revised branch naming strategy for our repository, aimed at addressing specific issues we've been facing with our current workflow. The proposal draws inspiration from the GitHub Flow workflow/strategy, Semantic Commits, and Conventional Commits.

The Problem

Our current workflow involves merging pull requests from the develop branch into the production branch, which over time has caused the production branch to be several commits ahead of develop.

Main Branch

Motivation & Solution: To rectify the issue of production being ahead of develop, I propose adopting the GitHub Flow strategy of maintaining a single main branch for releases. This shift simplifies our workflow, eliminating the need to manage multiple primary branches and the associated merge conflicts. We also propose adopting a squash-and-merge strategy for merging feature or bugfix branches into main, enhancing the readability of our commit history.

Feature and Bugfix Branches

Branch name: ~[feature|fix]/[author]/[descriptive-name]~ → [descriptive-name]

Name for the Pull Request and squashed commit: [semantic-tag]: [description]

Motivation & Solution: I propose adopting semantic tags (fix, feat, chore, docs, style, refactor, test, etc.) in our commit/PR names. This change will provide immediate context about the nature of changes in each PR and help in determining the version increment type for the next release (PATCH for fix, MINOR for feat, and MAJOR for breaking changes indicated by a ! suffix in the semantic tag).

Releasing

The proposed workflow involves thoroughly reviewing and testing feature or bugfix branches, followed by squash-and-merging them into the main branch. The semantic tags in the branch names since the last release will inform the version bump.

To maintain a continuous development build, we can always have a develop build off the HEAD of the main branch. This way, we can immediately test and review the latest changes that have been merged into main.

Once the main branch includes all updates for the next release, we will leverage GitHub's release functionality to create and tag a new release with the version number determined by the semantic tags. This process involves auto-generating release notes from the commit messages.

This proposed shift to GitHub's release feature, coupled with a simplified branch structure, will streamline our release process and enhance the transparency of our development progress. It will also ensure that our application's released versions align perfectly with the main branch, providing a reliable reference for developers and end-users alike.

jonasanker commented 1 year ago

@marfavi I like many of the thoughts you present. Fully agree that the current flow is suboptimal and I think your design proposal could provide a way to simplify things a bit. I'm definitely up for exploring that 🙌

I'm not at such fan of the Git flow pattern we currently have. It adds complexity and seems to be more a pattern of the past than the present.

If I should provide some history why we ended here; the main motivation was that the develop and production branch pattern allows to target two different environments with their own commit history. We needed this because of low confidence in testing so we had to test manually before release and also the fact that app releases can take several days to get out due to Apple's/Google's review process, hence we had to seperate the action releasing to prod. The benefit of the git glow pattern is that the environments have their unique git history such that partial features or minor fixes potentially can be merged directly or cherry picked to production without having to release other features from the develop branch. This can be useful but on the other hand it could also create a mentality anti-pattern for developers.

I read your suggested flow like this, just to verify:

main
|
| --> new child branch
| -- | new development commits 
| <- | merged into main branch
| Automatic dev deployment to Firebase App Tester
| (...)
| A GitHub release is created -> Triggers a new production deployment to App Store/Play Store
| (...)

I think this is an interesting idea which I think we should explore.

On your suggestions to branch naming semantics, I'm unsure if we would benefit from this or it becomes tedious to manage. We do not want to have long living branches but rather merge as often as possible, then one could imagine that there would be commits for a partial feature on main. That would make it a little difficult to then deduce the semantic versioning from each commit.

Anyhow, let's discuss next time we meet up. Great work! 💪