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
--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
.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
git checkout -b master git merge --no-ff docs
Now I’m ready to start developing the code in the
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
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
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
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.
2 thoughts on “Embracing Git”
I’ve been trying to improve my process by using git, but came across an issue I’m surprised no one else has documented.
If I clone an old project back onto my laptop, I have none of the compiled assets (as expected by the gitignore). This is resulting in me getting an error when I open a SMW: “GUI Extender file association needs reconciliation. …”
If I recompile the VT-Pro SDGs before opening the SMW, I still get the error, even though they now exist.
Because the Extenders are missing, all of the signals associated with them are also gone and I’d have to rebuild the symbols. This seems like a huge problem for project continuity.
I commented out the sdg sdg_ line from the gitignore and recommitted the original project folder and avoided this issue.
Am I missing something in the version control process with Crestron?
LikeLiked by 1 person
Hi Alan, have you tried adding the smw and sgd files to your gitattributes to check them in as binary? I had problems with git treating the smw file as text and corrupting it. I have had other problems with GUI extenders getting corrupted where git wasn’t even involved…