Indie Support Weeks: Working Copy - Fully Featured iOS git Client

Teaser image

Since COVID-19 doesn’t seem to go away any time soon, I figured I might as well continue with #IndieSupportWeeks to show you what I use and can recommend.

A dev tool I use on iOS is Working Copy. Usually, I don’t interact with my project code at all from iOS, but when I do, I check git stuff with this app.

Over the past 10 years or so I’ve tried a couple git clients for light work on mobile, but Working Copy sticked with me ever since I was participating in the TestFlight beta.

For a casual git fan-person, Working Copy’s settings might be a bit overwhelming, but for developers, I think this is a very fine app to browse, search, push and pull, and even commit changes.

Now the “commiting changes from mobile” part in someone’s daily workflow is utterly confusing to me, because I cannot imagine what that’d be like on an iPad, say.

I have edited posts on my website this way to fix typos. That went well. I also used it for light maintenance of Open Source projects. But I haven’t tried to commit to my Swift projects, because I don’t see how editing Swift files without a compiler would be a good idea. Then again it’s not my job to figure out user personas for a mobile git client – I’m here to tell you that if you’re in the market for such a tool, Working Copy is good at that.

The one thing I can testament to is that it works without a hassle, and it works well. That’s not much, but that may also be all you truly care about.

Working Copy is a free download + a $19.99 one-time in-app-purchase to unlock all the features. It also has a 4.9-star rating on the App Store, so, wow!

gitlogger Improved

I use Brett Terpstra’s little Ruby script called “gitlogger” to write git commit messages from selected repositories into my Day One journal once a day. My commit messages tend to be a bit longer when I work on projects which really matter. Unfortunately, gitlogger wasn’t intended to handle multi-line commit messages. Every commit message resides in a list item. But if you know Markdown, you’ll know this markup won’t render as expected:

Continue reading …

Nanoc3 Boilerplate

I put my personal nanoc boilerplate setup on GitHub. Maybe you find the deployment process useful.

Deployment Process

I assume you’re public html folder is called htdocs/ and you can create new folders below your domains folder but outside htdocs/.

I also assume you use my Rakefile: upon rake build it will checkout the branch ‘deploy’ and put all files from output/ in there. Uploading from ‘deploy’ to the production server will only copy the HTML output, not the nanoc setup.

  1. Initialize bare production git repository on the server:

    git init --bare ~/doms/example.com/git
    
  2. You’ll want automatic updates when you push to the server. Use git’s own
    post-receive hook:

    # add to ~/doms/example.com/git/hooks/post-receive
    echo "Updating website ..."
    cd /the/full/path/to/doms/example.com/htdocs || exit
    unset GIT_DIR
    git pull origin 
    echo "Update complete."
    

    Make it executable:

    chmod +x post-receive
    
  3. Initialize git repository in htdocs/. This will point to the bare
    repository on the server and check out the current version:

    # given you're in ~/doms/example.com/htdocs
    git init
    git remote add origin ../git
        
    # setup branch to pull from:
    git config branch.master.remote origin
    git config branch.master.merge refs/heads/deploy
    
  4. Setup production server locally:

    git remote add production ssh://user@example.com/~/doms/example.com/git/
    git remote show production
    
  5. Commit changes locally and put them on the server:

    git commit
    rake build
    git push production deploy
    

    You can push all branches via git push production to backup your code.
    Only the branch ‘deploy’ will be visible to the public.

Sources

I once combed this together from various sources: