ArchaicMage

When I started working on Space Miners for Dream Build Play, I began with the same new-project process that I do with all my web projects.

git init

Little did I know that after a short while, I was going to run into some not so litte problems later on.

I think I speak on behalf of every programmer when I say that there is a sense of clarity when starting a new project. With no pre-existing design choices dictating the direction a project must go, the possibilities of writing a scalable, perfectly architected system sit waiting directly in front of you.

So why GIT; Why not SVN or Mercurial? For starters, I have never worked with Mercurial, and while knowledge of code-versioning transfers pretty well I did not want to spend the time learning a new code-versioning tool when I already had years of experience with the former candidates.

I chose GIT over SVN for its distributed nature.Since each local copy of my project is itself a git repository, I am able to work and commit changes without network access to my repository, and sync it with my remote origin later. SVN is completely dependent on acess to remote origin in order to commit changes, so if I were to work away from network access, I would simply be forced to sit on pending changes until I had the ability to commit to remote origin.

Unfortunately, GIT does not play extremely well with large binary files. To accomodate this, GIT offers LFS or (Large File Storage) which replaces large files with text pointers inside GIT, while storing contents on a remote server. Unfortunately I did not really find out about GIT LFS until my repository on BitBucket was over the 2Gb hard-limit, and my repository was set to read only. This was exacerbated by the fact that for some of my project, I used a tool called GitKraken, which DOES NOT contain support for GIT LFS. This meant that for some of my commits, the large files were commited to my project without GIT LFS, increasing my repository file size considerably. These files in question were primarily contained within a large audio package, but by the time I noticed, these files were already committed way back in my project history, and I would need to use a tool like git filter-branch or the BFG Repo-Cleaner.

In the end, I was almost ready to push my project to Unity Cloud Build anyways, and really just needed one last push to remote origin, so I opted to create a new repository on BitBucket, push my code once and wire up Cloud Build, since I was no longer making code changes to my project, the read-only enforcement on the repository was not an issue.