Developing a React Native app for both iOS and Android at the same time comes with some challenges. One of them is how to best organize your source code in a version control system such as Git. Even though most of the code will run on both platforms, there will also be quite a lot of things that need to be addressed differently for each platform.
A good approach for handling these differences is to implement a suitable Git branching strategy. Being a solo developer I have the luxury to decide exactly how I want it to fit my needs, so I started out by writing down the following "requirements":
- I want to have all my code in a single Git repository
- I need separate branches for the iOS and Android versions
- I want to be able to develop all features shared by iOS and Android in a single branch to make everyday development as smooth as possible
- I want merging to be painless
- I want to avoid cherry-picking commits between branches
- I want separate branches for development and production code (for each platform) that can have different configurations
- I prefer to develop my features for iOS first
- ios-dev: This will basically be my master branch, and all feature development is done here.
- ios-prod: No feature development or bug fixes. Only prod specific adjustments and config. Merge ios-dev into ios-prod.
- ios-release-<version>: Create new release branches from ios-prod whenever a new iOS version is about to be released.
- android-dev: Only development of Android specific features and fixes. Merge ios-dev into android-dev.
- android-prod: No feature development or bug fixes. Only prod specific adjustments and config. Merge android-dev into android-prod.
- android-release-<version>: Create new release branches from android-prod whenever a new Android version is about to be released.
Git branching strategy for a React Native iOS/Android app |
I've been applying this strategy for a while now, and so far I have to say it has worked out really well. Merges are usually without conflicts, and the times there are any conflicts they are most of the times very easy to solve. When merging a dev branch into a prod branch it's not completely uncommon that some config file has changed in both branches. However, when this happens it's almost always the case that you want to keep the file from the branch your merging into. To resolve this type of conflict, just use git checkout with the --ours flag (using --theirs would instead keep the file from the branch your merging from). Example merging from ios-dev into ios-prod:
git checkout ios-prod
git merge ios-dev
git checkout --ours <file-with-merge-conflict>
git add <file-with-merge-conflict>
git commit -m "resolved merge conflicts"
This simple branching strategy can easily be extended with feature branches and test branches if necessary. In my case I haven't had any need for these types of branches yet, so I prefer to keep it simple as long as possible.
Comments
Post a Comment