Since the earliest days of being a Mobile Product Manager, I overheard terms like branch, merge and commit in developer discussions during which my role was much more the one of the ‘client’. But it wasn’t until I started to closely work with developers on my own side projects, when I truly tapped into the world of Git and version control in general.

Suddenly, I was asked to create a new branch for the changes I had in mind myself. And how the hell was I supposed to merge anything, leave alone handling merge conflicts or even opening up a Pull Request? At that point, I already celebrated the creation of a new repo like launching in the App Store.

Despite my own ambitions to learn coding, I always kind of avoided to really understand Git and was focussed on just not completely messing-up collaborative code efforts.

But when the idea of starting Git2Go began to become more and more concrete, I knew that I had to become way more comfortable and also confident with Git when I wanted to make an app work, which wants nothing less than to re-invent Git on mobile devices.

Video Tutorials about Git just aren’t enough

So, I went back to the place where I received almost all my theoretical technical skills from - Treehouse. I always enjoyed taking courses there and was confident that it wouldn’t disappoint me this time.

But already after the first couple of clips, I still didn’t really felt connected to the topic. I also struggled to make progress on this new discipline more than I was used to and lacked concrete hands-on repos to make my own marks. The only experiences I did made back then have been with repositories I contributed to on my own - Which really didn’t gave me any impression of collaborative Git workflows. I even cloned my code to Dropbox back then, as I mostly thought in folder structures than in repositories.

Thankfully, Piet is quite a good and patient teacher when it comes to help a rookie making his first steps in untapped waters. He always had (and still has) an ear for me when it comes to Git mechanics, vocabulary and how I could contribute to our repositories in a meaningful way.

Collaborating on code for the first time

All of our code around the Git2Go product is of course hosted on GitHub. Since I’m rather a threat to our Swift code than a meaningful contributor, it was clear that I couldn’t really get going on our iOS code. But as our website is based on good old html and css, I could pretty much get going on this end without the need of too much supervisory.

So I quickly learned how to create branches, regularly commit and sync my changes (what’s the point of having a branch locally on your computer at home, right?) and how to use the benefits of version control in general to make progress on our web presence.

I’ll never forget those moments when I opened my first pull request back in the days, got a PR assigned myself or even hit the merge button without the need to hectically call Piet afterwards. It was such a rewarding feeling to get more productive with every achievement I unlocked - but also with every mistake I made along the way.

The power of Git for non-developers

While I meanwhile also learned to push code into collaborative repositories, I was far away of calling myself a developer. And even while I make some progress regarding my ‘engineering‘ skills, I still feel more comfortable in non-code environments - e.g. writing.

So, in order to have other playgrounds of practice for a continuous improvement of my Git skills, I tried to think of other scenarios to contribute content within a Git environment.

That’s why the idea to base our own product blog on Jekyll was such a great kicker for me. While I was way more comfortable with blogging through a GUI like WordPress, writing for a Jekyll-based blog opened up the opportunity to perform Git workflows way more often for me - contributing content I’m already quite used to produce.

I now don’t have to wait for another app update or bug to touch our website repository, but can rather start-out new blog post ideas in a new branch, get a copy review from Piet through a Pull Request and publish it by merging the PR to our master.

For the future, I’m also already thinking about moving other collaborative writing efforts like the Productish show notes and episode preparation to GitHub repositories. This way, I could have even more regular opportunities for working with Git and would become way more flexible for updating those Markdown files than storing them on Dropbox.

How I learned to love Git on iOS

Even though I saw a lot of people being crazy productive with Git from the command line, I still heavily rely on a traditional GUI to feel comfortable. While even modern Git clients like Tower or GitHub Desktop are still rather complex to look at and use, one of the main benefits of iOS apps has been the simplification of user flows.

This is why I try to get as much Git work down on iOS as possible. What desktop-minded people would maybe consider a lack of functionality, gets embraced as a welcomed constraint from me. I’m only presented with the actions I can really use at the respective moment of a workflow and am not distracted (or furthermore sometimes even cowed). This way, I’m having such a pleasureful and succeeding experience every time I push code from my iOS device. And with the neat integration of Document provider extensions in apps like Textastic I also came to enjoy even long-form publishing for our Jekyll-based blog.

I already learned a ton of new stuff around Git through our journey of making Git usage on iOS a better place and have never been more amazed by the effect of dogfooding. Especially outside your comfort zone.