HN Explorer

Git workflow for mobile development

5 points by prats226 ↗ HN
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.

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

Another problem is since base code with every feature branch is from master branch and it has to be merged with development, there are lot of conflicts. Earlier when we used to fork from development, we used to regularly merge development branch with feature branches 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.

Is there a better workflow for mobile development that people have adopted or even some practices that can be followed to solve these problems?

10 comments

[ 2.9 ms ] story [ 36.4 ms ] thread
thecupisblue
I don't understand the issue, in mobile development you can also test changes as soon as the build is done and see if there are bugs. You can also publish (at least for Android) directly from CI to play store Alpha/Beta/Release and have that go straight to QA. You can build a branch on PR and have a link sent to your QA team via slack.

> 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

Why is buggy code being merged in? Why isn't it reviewed,covered with tests and tested manually?

Also, you can checkout commit before merge, create a new branch and continue development without any issues.

prats226
Yeah I agree we are lacking in sufficient testing right now because since we are in early stage of app development, we are building features at fast pace. One solution is to merge changes using --no-ff flag and using revert to remove changes if there is major bug in that merge.
MartinRogalla
I work with feature branches for iOS development as follows:

Whenever I want to create a new feature or fix a bug, I create a new branch. I am responsible to rebase and keep the branch up-to-date until it is reviewed and merged. When the branch is merged into master, using @KrausFX's fastlane tools we automatically build, test, submit a build to testflight and create a pre-release with the build number on GitHub. The appropriate people then review the App and submit a release for review by Apple whenever they're ready. Once the App is approved and released we create the corresponding official release on GitHub.

Works well and keeps us productive.

As I may have overlooked something, could you pinpoint where in this workflow you would have issues?

prats226
Since we are in early stage of our app, we release android app once every two days. Most of the problems are because since features need to built faster, we are lacking in sufficient tests. Also multiple people end up working on same file. Major problem is that if some spurious code goes into development branch and other people create feature branches from it, it becomes a problem. I think using --no-ff flag to merge and the using revert to remove such code should work well. Will try that out.
prats226
Don't know if it fits well but its a nice article talking about why github doesn't use gitflow workflow

http://scottchacon.com/2011/08/31/github-flow.html

I am not denying that automated tests are not necessary but I believe that continuously deploying code and then fixing bugs that occur in the code is atleast faster way to code.

Github flow certainly doesn't work very well with mobile development main reason being you cant deply code to production continuously but I was wondering if there is some middle way

gonyea
This isn't a git flow issue, unless I'm missing something. If anything, you can more easily revert a bad set of changes by simply reverting the merge commit.

Front-end testing is hard, but you need to figure that out. Ruby Motion can come in quite handy for that.

prats226
Yeah mostly issue is with front end testing. Also we were not keen on using revert so never really tried it. Is this correct way to revert a merge commit? Because it looks pretty complicated to revert merge commit on development and when need to push those changes back, you need to first revert the revert commit and then merge the branch back.

https://github.com/git/git/blob/master/Documentation/howto/r...

gonyea
If you're using github, you can also go into the merged PR and hit revert, assuming conflicting changes haven't been made.

Otherwise you can do `git revert SHA -m 1` and fix conflicts / commit.