Embracing Git

I admit, I’ve used the poor man’s version control for many years since it’s what was adopted by the team I worked with: renumbering the file every time you go to save it. I’ve used git for many years in other projects, but never for my day-to-day work in the Crestron environment. I’ve played around with it a little and think I’ve come up with a set of guidelines that will make it work for me.

Start with the right template

SMW files may be text, but their contents are meaningless unless you’re in SIMPL Windows. For that reason, we need to make sure we treat those files differently. And in the process of building and testing SIMPL programs, a lot of temporary files get created that we can safely ignore. For that reason, I’ve created a repository on GitHub you can clone that has a good set of defaults for working on Crestron files.

When I’m ready to start on a new project, I make sure I have the latest template on my laptop:

git clone https://github.com/kielthecoder/CrestronProjectTemplate

Create a new repository

My project repositories don’t live on GitHub. I SSH into my private server and make sure a new folder exists for each project:

mkdir -p /repos/Customer-Location-Project.git
cd /repos/Customer-Location-Project.git
git init --bare

Passing the --bare option tells git not to create a working directory here. I’ll only use this directory to check in and out of remotely.

Naming repository directories this way will help keep them organized when we need to return to them later (to fix bugs or add new features). For example:

Innitech-CA-PaloAlto-Boardroom.git
Innitech-CA-SanDiego-HuddleRoom.git
Innitech-NY-NewYork-Cafe.git

Keeping every project in a separate repository will help keep them organized and easier to manage. I’m choosing not to use spaces because it makes it easier when working on the command line. Maybe I can get GitLab setup eventually and that will make it easier?

Maintain the workflow

When I’m ready to start working on a project, I check it out onto my laptop:

git clone kiel@server:/repos/Innitech-CA-PaloAlto-Boardroom.git

This creates a working folder on my laptop named Innitech-CA-PaloAlto-Boardroom that everything for that room needs to go into. My first step is to copy the .gitattributes and .gitignore files from my master template into this folder and commit those with:

git commit -a -m "Added git files for Crestron project"

Next I create a folder named Documents and stash all my project documentation there. I like to make sure any documents I add are checked in to the docs branch, so I do the following:

git checkout -b docs
git add Documents/
git commit -a -m "Checked in project documentation"

Since I’ll need these in all my branches, I merge back into master with:

git checkout -b master
git merge --no-ff docs

Now I’m ready to start developing the code in the dev branch:

git checkout -b dev

I’ll work in dev until I’m ready to package up a release to send to a technician in the field. Then I’ll merge back into master and tag it with a version number:

git checkout master
git merge --no-ff dev
git tag -a v1.0.0
git push --all
git push --tags

Revisiting a project

If I still have the working directory on my laptop, I can just issue a:

git fetch
git pull

Otherwise, I may need to clone the repository again.

Once I know my working copy is up-to-date, I switch back into my dev branch and make sure it’s in sync with master:

git checkout dev
git merge master

Reviewing the log may help me figure out what I was doing last in this program:

git log --oneline

Once I’m done making changes, I merge everything back into master and update the version number:

git checkout master
git merge --no-ff dev
git tag -a v1.0.1
git push --all
git push --tags

Experimenting

Sometimes I need to try something that I may have to undo and that’s where a test branch can be really handy. If I merge with dev, then the test branch has exactly what I was just working on

git checkout -b test
git merge dev

Then at the end, if I decide the test was a success, I can merge into dev:

git checkout dev
git merge test

If the test was a waste of time, well that’s OK too, I just go back to working in dev:

git checkout dev

Fighting with git

git is a tool that tries to keep you from losing your work. Sometimes it can be annoying about it. Here’s what I’ve learned dealing with some of the nagging from git.

git reset can get things back to where you want. Check out this great explanation in the Git documentation.