I wrote this up in an answer on a Slack thread, so I figured I’d take a minute to polish it up a little and post it here so I can reference it in the future. This is the Git workflow that Ben and I follow for our project StudySwipe:
We work out of the same repo, which has a
master branch, a
development branch and then we each have our own branch for what we’re working on:
'master' (what we publish on Github and to the AppStore) | | 'development' (our main working branch prior to publishing to master. Each PR into master is a new version release following semantic versioning) | ––– 'dillon' (my branch to make PRs into development) | | ––– 'ben' (ben's branch same as mine) | | ––– Other feature branches (as needed)
We start by branching off of
development. To do that, we first make sure that our local version of
development is up to date:
1 2 3 4 # switch to the development branch git checkout development # pull anything the remote repo has that isn't here locally git pull
Then we make the new branch (or checkout the existing one):
1 2 3 4 # if we need to create a branch git checkout -b some-branch-name # otherwise we don't need the -b flag git checkout dillon
Then we do some work. This is the part that takes up the most time, but it is a small part of the Git workflow. We commit as regularly as we can with meaningful commit messages of the changes and we try to group the code for a PR into features that are a part of a user story.
1 git commit -m "Made a change to the api for CoreDataController" -m "Explanation and reasoning behind the change..."
When a feature is complete, or some bugs are fixed, or whatever, we get ready to make a pull request. First, we make sure
development is up to date:
1 2 git checkout development git pull
Then we merge it into our branch. This gives a great opportunity to fix any merge conflicts between anything we’ve written and what was added since we last pulled. It is nice because it leaves things clean and conflict-free for anyone who is going to review the PR.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 # switch back to our branch git checkout some-branch-name # merge development into it git merge development # cross our fingers that it just works # but fix any merge conflicts that occur # then push it up git push # if this branch hasn't been pushed before # you might have to do something like git push --set-upstream origin branch-name # but git will tell you and even give you # a command that you can just copy and paste # if you need to.
Then we actually make a pull request into development. Depending on how things are going, we will sometimes review them before merging, but this project started as a hack-a-thon submission, so we didn’t start with great review habits. Once the PR is merged, we start the loop over again.
The part that I don’t have an exact handle on the flow of, because Ben does it, is exactly how we get from
master to the App Store. My guess is something like this (I’ll confirm with Ben when I have a chance):
1 2 3 # Make sure development is up to date git checkout development git pull
Then update the version numbers and build numbers and what not, in Xcode. Then pull request and merge into
1 2 3 # Make sure master is up to date git checkout master git pull
Once the latest stable version is merged into
master and on the local machine, build and run the project in Xcode. Verify that it’s working and what not. Then, finally, archive it and push to the store.
I don’t know that it is the best flow to follow but it seems to be working for us right now. At some point we may look into some sort of CICD that would build the archive and push it to the store for us when we merge into development, but that is quite a bit of overhead for a side project, especially because right now we’re not even doing any testing. When/if we get there, CircleCI seems like a really solid option. They have great documentation and they will even give you some free time on a machine if your project is open source.
Let me know if you have a better Git workflow, or suggestions on how to improve this one, or suggestions on CICD products or whatever.