Decide on Git Branching Strategy

[wmontwe]

As our Android application grows, we need to establish a robust Git branching strategy to improve our development, testing, and release processes.

Currently, we use a maintenance branch for patches and bug fixes post-release, testing changes in a beta version before merging back. However, this method isn't always followed consistently, leading to issues. For more details see RELEASING.md and update #7800.

With our growing team, we need to reassess if the current strategy efficiently handles our development needs.

Action Points

1. Define Requirements: Define requirements based on our project needs and team feedback. This will guide our choice of a Git branching strategy that best fits our needs.
2. Evaluating the Current Strategy: Discuss the pros and cons of our maintenance strategy and explore ways to enhance adherence.
3. Comparing Alternatives: Review GitFlow, GitHub Flow, and Trunk Based Development to identify a suitable model.
4. Development vs Maintenance: Strategies for managing stable production with feature development.
5. Communication and Collaboration: Enhance communication and collaboration, especially for maintenance and new features.
6. Continuous Integration and Testing: Improve integration and testing processes to ensure thorough testing of patches.
7. Documentation: Document the selected strategy in an Architecture Decision Record and update developer documentation.

Proposed Alternatives

1. GitFlow: A structured model with separate branches for features, releases, and hotfixes, though potentially complex.
2. GitHub Flow: A flexible, single-branch model suited for frequent releases and parallel changes.
3. Trunk Based Development: Focuses on a single main branch with frequent merges, supporting continuous integration and quick iterations.

Key Questions for the Team

1. What is the team's preferred development style, and how often do we want to release?
2. Which Git branching model aligns best with our team's workflow and goals?

Ask for feedback and suggestions

Please share your thoughts and suggestions on the proposed branching strategies to refine our approach for our Android app development.

[gdt]

As an outsider, some meta comments:

• Please do not adopt github-specific features. Only consider things that would work if e.g. this repo moved to codeberg, a self-hosted gitlab, or really just plain git. It's not clear to me if any of your possibilities cross into this.
• Simpler is better.
• Your evaluation of what to do should start with requirements. It's hard to know what approach is best without having written down what the project is doing.

Not clearly emphasized is that overall cleanliness pays huge dividends, so I would expect:

• all changes except perhaps revision# changes near release are on feature branches
• feature branches are expected to be clean, meaning rebased into clean commits, no backwards merge commits, no untidyness at all
• all merges of feature branches will have an explicit merge commit even if there is only one commit, to record the merge and who authorized it, and this happens only to trunk/develop/whatever
• fixes for releases should, if reasonable, first be merged to develop and then be cherry-picked to the release branch
• any fixes on release branches should be cherrypicked to develop more or less immediately

[wmontwe]

As an outsider, some meta comments:

* Please do not adopt github-specific features.  Only consider things that would work if e.g. this repo moved to codeberg, a self-hosted gitlab, or really just plain git.   It's not clear to me if any of your possibilities cross into this.

* Simpler is better.

* Your evaluation of what to do should start with requirements.  It's hard to know what approach is best without having written down what the project is doing.

Not clearly emphasized is that overall cleanliness pays huge dividends, so I would expect:

* all changes except perhaps revision# changes near release are on feature branches

* feature branches are expected to be clean, meaning rebased into clean commits, no backwards merge commits, no untidyness at all

* all merges of feature branches will have an explicit merge commit even if there is only one commit, to record the merge and who authorized it, and this happens only to trunk/develop/whatever

* fixes for releases should, if reasonable, first be merged to develop and then be cherry-picked to the release branch

* any fixes on release branches should be cherrypicked to develop more or less immediately

Thanks for your input and right, we need to define requirements and then continue with the evaluation. I updated the issue by that point.

[wmontwe]

We discussed with the team on how to approach this and need to document our current approach.