Repository files navigation

updated 21 April 2022

GitHub lets you create digital contenteasily as it is using Markdown. Thatreally fits for digital content writers,even for non-code. The most importantis that you can use GitHub withoutGit. I don't want to use Git to simplifythis workflow. Don't get me wrong,Git is a very powerful tool butfor the sake of my workflow simplicity,I'll not be using it for basiccontent creation.

When I'm doing tutorial or lessoncontent, I have my personalworkflow, so that I am always efficient.Take note, what I am referring tois not a software development workflow,that's a very different one.

The very first rule is that everythingshould be online, even the drafts ofmy content, so that I can access iteverywhere. The only downside is that,if there is no Internet connection, I reallydon't have access to my online contentunless I have an offline backup.

GitHub really is there as my activesite development more than Google Docsor Microsoft Word. I have coveredthis in one of my posts:

https://github.com/jdevstatic/github-pages-tutorial

The most important catch is thatyou want your content as a plaintextformat and let it be rendered fordifferent formats for distribution.Plus, when you put your content onGitHub, it is really efficienttracking the version of your fileparticularly when othersare collaborating with your work.But even if I'm just alone, it'sreally the best for me.

I tested several workflows of myown and I want it to be simple aspossible. I tried using GitHubDesktop and VS Code or GitHub Gist, etc.,as additional tools,but the workflow would not be that simple.Don't get me wrong, they are greattechnologies but the way I want itis as simple as possible. So,this workflow that I am adheringtoo, I am using this wheneverI am creating digital content.

Firstly, I will start creatinga repo here on GitHub and set ittoprivate first. For me, for everycontent is a separate repo, nomatter how short the content is.I will be putting all myinitial thoughts.This is still a draft even thoughI am using themain branch becausethis is still private. It is thedefaultREADME.md file that is theactual page and it should be the onlyone for my content. If thetutorial or lesson is very long,it can simply have a TOC. GitHubalso added this recently andby default, it is enabled.

Then, say, I feel that I'm done withthe content, this time, of course,I need to proofread, for spellingand grammar and the structure of thecontent itself. I found it out thatthe simplest way of doing thisis to use Google Docs. I willcopy and paste the rendered contenton Google Docs. Don't get me wrong,I am not using Google Docsfor content creation,it is just to check particularly forspelling. Also, thestructure of the content can beseen easily there. The only downsideis that sometimes embedded pictures willnot be allowedon Google Docs but this doesnot matter, because the focusis content structure, spellingand grammar.

After this, it is now ready. I'llbe making my content public. Iachieved several things here, mycontent can be rendered in differentformats like HTML just like thepage generated by GitHub Pagesor use GitHub Gistfor embedding on another siteor PDF for printingor downloading, while the repoon GitHub will still remain thedevelopment site for updates.

Now, when there is an update, thisis the time I use branchesbecause themain branch isalways deployable. Even if I'mdeveloping alone, this is veryimportant. Then, I'll push the changesin themain function when it'sready.

So, there you have it. To summarize:

1. Create a private repo. Consider itas a draft. And then, the final stepis to proofread using Google Docsfor spelling and grammar.

2. Once all checks are done, make itpublic. This is already the final version.This can be rendered in several formatsfor distribution.

3. When there is an update, usebranches because themain branchis always the deployable branch.Then just merge the branch intomain by pull request whenit's ready.