A digression into Git

At the moment I’m the sole developer working on my finance project and I can’t see that changing. It’s very much a learning exercise. If I’m going to do it as a learning exercise, though, I might as well do the thing properly. That means source control, and these days source control overwhelmingly means Git. I’ve browsed projects on Github, but never really got to grips with it.

My previous experience with source control was many years ago with Microsoft Visual SourceSafe, way back in the 90s. It followed the traditional model – when you want to work on a file, you check it out and then it’s locked exclusively to you. Git, at first glance, is more complicated. In theory it allows multiple developers to work on the same file simultaneously and then handles merging the result. In practice, most teams using Git probably try to avoid that as much as possible, as it just increases the overhead in resolving merge conflicts.

Git also uses the concept of branches. These can be as simple as having a development, QA and production branch of the code or a more complex model where individual features – or even bug fixes – are developed in branches. I’ll start off with a single branch – developing against master – to start off with, and then experiment with branches as I go along.

Adding my project to Github seemed like a good way to start. Even if I never gain contributors, it will mean I can keep code snippets in the blog short and to the point as the code will be available to view on Github.

I should note that my project will be set to private to start off with, at least until there’s enough code there to create a workable system.

I’m also using Github to solve the problem of developing on multiple machines. I’ve moved the development from my Linux “server” to my Mac desktop, but occasionally I’ll want to work on the code from my laptop. Obviously I could just stick the code in Dropbox or OneDrive and have the files sync, but I’m going to use Github for that job instead.

I wouldn’t actually recommend doing that if, like me, you’re a sole developer working from two machines. I’m only doing it to learn Git. OneDrive or Dropbox would actually be more appropriate. In order to sync a change via Github I have to commit it and push it back to Github.

That’s fine if it’s a change that forms a completed piece of work, but what if I’m just saving it because I’ve been working on the desktop and fancy going out for a coffee and continuing on the laptop? That’s not a good reason to commit code. I’m only doing it that way to gain familiarity with the tools.

In order to learn more about the ecosystem, I’ll be using command line git on my desktop and the GUI on my laptop.

To make matters even more complicated, I’m splitting development between OSX and Windows. That introduces the thorny issue of line endings – OSX uses a line feed character (LF) and Windows uses a carriage return followed by a line feed (CRLF). Luckily Git handles it well using the core.autocrlf setting – setting it to true on the Windows system will add the CR when I pull files and remove it when I push them back.

I could avoid the issue altogether by running my Django development in Ubuntu running under WSL – the Windows Subsystem for Linux – but since the point of the exercise is to learn I figure I might as well go the whole hog and use native Windows Python.

So to summarise, it’s as if there are two developers working on a Django project. One is using OSX, the other is using Windows and the completed project will run on Linux… what could possibly go wrong?

in Finance Project

Related Posts