Search code examples
iosgitworkflowgit-flow

How to use gitflow for one release

I'll start working on iOS app from scratch that is simply a replication of an existing android app.

There're 7 modules in this app (Login, register...), the client want to test each module upon finished so the app will be published to the app store when all modules are completed and well tested.

I'll use git-flow in this project and it has many branches (master, develop, release, features...)

My question is how can I use "release" branch in that case when I have only one version (1.0) that will be published until the end of project ?

And how I can manage delivering an IPA for a module (feature) to test when a new module (feature) is already in development phase ?

Solution

  • You're overthinking it.

    Tags in master don't represent code that is "released to the public", it represents code that has "finished development and testing". These tags are not public, they are markers to help the development team manage the code.

    Publishing code to the users (public or private) is a business decision that is NOT relevant to git-flow or any other branching model. Saying that something meets the expected requirements is a project decision that IS relevant. *

    So for the situation you describe, I think the following process (or something similar) makes sense:

    1. Create a feature branch of of develop
    2. Complete development work (including code review and developer testing)
    3. Merge feature back to develop
    4. Create a release branch for QA testing **
    5. After testing (and fixing) is complete, merge release to master and tag it as version "0.1"
    6. Merge release to develop
    7. Repeat for version "0.2", "0.3", etc.

    In master you will have tags "0.1", "0.2", etc. These represent incomplete versions of the application that are functional and stable, but not suitable for complete release. Finally, when you have version "0.7" (or however many cycles this takes) the business will make the decision that "this version of code is complete and suitable for release". Then (and ONLY THEN) do you create the tag "1.0" in master.

    Future development will then use the tags "1.1", "1.2" etc. In short, in this versioning scheme the first number represents the "released version" (as determined by the business) and the second number represents the "development iteration".

    *Obviously these two concerns/processes interact and inform each other, but that is an entirely different topic. **You don't have to do this for every feature branch, but it sounds like you're working alone and will be developing things sequentially. It's completely reasonable to merge multiple feature branches and create a single release branch for testing.