用于移动开发的Git工作流程

Question

So, we started using gitflow workflow with our server side as well as mobile development. It works out really well with server side code, since there is test coverage and with build automation, feature branches get merged into development branch as soon as they are tested ok. Unlike mobile development, since the changes are live as soon as you wish to (no time to deploy apart from build and testing), you can quickly test if there are any bugs in code you pushed and quickly make changes. So this workflow works out really great for server side development. However we are facing issues with mobile development with this workflow.

With gitflow workflow, we have three persistent branches, namely development, staging and master. Code on master branch goes to our play store app, we have another closed beta google play store app for staging which is available only to our team members and we use crashlytics beta to distribute latest development branch code only to developers from our team. Whenever someone starts working on new feature, that person creates feature branch forked from master (previously we used to fork it from development) and once the feature is ready, creates a pull request into development. Everyday, we review pull requests and ones that are ok are merged into development.

Now there are two major issues that we are facing with this workflow. One is that suppose we merged some feature into development and later figured out that there are lot of bugs in it. Now it can't be pushed further, whole development cycle is stuck because that code is already merged with development. This is the reason we started forking feature branches from master rather than development as at least individual feature branches will have fully working code. One way is that each feature can be separately distributed to team members to test and only then will be merged to development but it's very cumbersome. So can this problem be solved with a different workflow?

Another problem is with conflicts in code. Since base code with every feature branch is from master branch and it has to be merged with development, there are lot of conflicts nowadays. Earlier when we used to fork from development, we used to regularly merge development branch with feature branches people are working on so there were no conflicts but can't do that anymore. So now to fix conflicts, we create another temporary branch from feature branch with which we merge dev code, fix conflicts and put that as pull request which is again little cumbersome.

This all looks like problem of gitflow workflow not suiting well for mobile development. Is there a better workflow for mobile development that people have adopted or even some practices that can be followed to solve these problems?

Answer 1

SpitFlow

There are opposing thoughts on this from conversations I've had with testing engineers. Your mileage may vary.

Consider when appropriate developers could fork the entire code base and work on their features in their own forks.

When ready, they merge into their own develop branches triggering a new build on CI box specific to that users develop branch. Yes, a separate build per user per develop branch. Overnight feature builds would be in the hands of (feature) testers without getting bogged down with code review.

Pros

• You can still follow gitflow to the T - without introducing another 'alpha' branch or 'BUT' (branch under testing) Gitflow and testing / deployment

• It's clean and isolated (code wouldn't mess with stable develop branch)

• The feature can get into (feature) testers hands without going through committee of people doing code review.
• Tester feedback could potentially weed out buggy features (without bothering other developers)
• A forked repo /feature could be an opportunity for developers to shine as the build could reach the hands of stakeholders who may love a feature that may not have been sanctioned by dev / product team committee.
• Bypass red tape to bubble up cool new features without 'approval'.

Cons

• Could introduce conflicts with product owners 'who approved this?'
• When the code is 'ok'ed by feature testers, it still needs a PR back to origin/develop + code review then back into QA more testing.
• Additional devops bandwidth needed to configure scripts to spit out new builds.
• Developers need to keep their dev branches in sync / up to date with the origin/develop head.
• Potential for bigger merge conflicts when working solo for longer.
• Fostering competition (not always a bad thing).
• Others?

If the downsides outweigh the pros then this is not for you. Consider it could be a temporal ticket for a specific feature then you can 'revert' back to gitflow.

Suggestion 2

Have developers build the feature to testers phone without jumping through so many gitflow hoops.