Maintaining a Productive Workflow
I work much better with a simple standardized work flow. If you followed my post on Installing Jekyll and getting ready, you’re ready to just use my workflow if you like it. Otherwise, tweak where necessary.
This workflow assumes you have a local (ubuntu maybe\?) environment for development, use vim to edit text, git on the command line to push most updates, occassionally change things on the github console, have an SSH key set up to authenticate you, and don’t mind being methodical about it.
In a nutshell..
I found it easier to work with Chrome and 2 tabs open, one for the repository itself and one for the page to refresh and watch changes live. I use a bash console to make my changes on the site, commit and push them to the master branch (because I haven’t figured out forks yet) and occassionally run a local jekyll server to do tests that I think might break my site. Otherwise, I’m pretty fast and loose and commit half pages occassionally (as you may be able to tell…) and it really doesn’t matter as long as you come back and clean it up in a reasonable amount of time.
These items were important in order to have an easy workflow
- Make sure wherever you develop matches production
- Don’t use unsupported themes in development, for example
Don’t make changes in the web console without pulling them back locally
- git pull
- git submodule update
Don’t make multiple huge changes at once. I feel pretty comfortable creating a full post page one at a time. I don’t feel comfortable changing my default.html layout without first testing it and changing one part at a time. It’s much harder to work backwards and troubleshoot if you’ve done a few different things and you can’t remember them all.
- Pick a style you like and stick with it, at least until you have some content. Once you have a decent amount of content, you can be aware of how changes you make affect all your content.
With that, it’s time to work. I do the following things
- Always keep my github.io page and my localhost page ready. You can quickly review changes and make sure you pushed them right this way.
- It’s easier for me to work from my root directory and tree around and edit files directories deep than to get into a directory and find out I didn’t back out before creating a new page.
- Refresh and test frequently. If I’m testing formatting, I often rebuild several times very quickly and refresh my localhost page to see them happen in action.
- Stand on the shoulders of giants. Copy that template, reuse that syntax, google that stackoverflow. Other people have solved these problems, so use their knowledge. Just pay attention to when a fix you want to apply breaks something you’re doing or follows a pattern you don’t use.
I work with a dual monitor set up both at home and at work. I don’t know how people get along with single monitors unless they’re ultrawide. Invest in a second monitor, it’s worth it.