Blogging With Git Flow
Blogging With Git Flow
Blogging is fun, that's why we do it! Take some of the headache out of publishing what you've written using Git Flow to push your content.
Join the DZone community and get the full member experience.Join For Free
Learn how error monitoring with Sentry closes the gap between the product team and your customers. With Sentry, you can focus on what you do best: building and scaling software that makes your users’ lives better.
For a while now, we've used Git Flow in our projects at the YooApps. Git Flow is an add-in for Git, that helps us to follow the feature branch process in a standard way. We usually use our Jira ticket number as names for features, bugs, or hotfixes, and we use the Jira Version as a Release name. This makes absolute sense to us and makes the flow pretty transparent. We also use BitBucket to host our Git repositories, which is directly linked to Jira. That means on every Pull Request we have the direct link to the Jira ticket.
Using Git Flow to Release New Posts
My idea is to also use Git Flow to release new blog posts.
My blog is generated by Pretzel, which is a Jekyll clone written in C#. I host it on an Azure Web Site. I write my posts in GitHub style Markdown files and push them to GitHub. Every time I push a new post, the Azure Web Site starts a new build and runs Pretzel to generate the static blog.
For about a year-and-a-half now, I've used Git on GitHub to publish my posts, but I've only used the master branch, and I don't commit the drafts. I sometimes write two or three posts in parallel and I typically have around ten drafts in the Pretzels _drafts folder. This feels a bit messy and I will probably loose my drafted posts if the machine crashes.
Using Git Flow, I don't need to use the _drafts folder anymore. Every unfinished feature branch is a draft. If I finish a post, I would just need to finish the feature branch. If I want to publish the posts, I can start a new release.
Maybe the release step is a bit too much. But currently I need to push explicitly to publish a new post and it shouldn't be a big deal to also create a new release to merge all finished posts from develop to master. If it doesn't fit, it would be easy to switch to the more simple feature branches.
Let's See How it Works
This blog post feature branch is created by using the following commands in the console:
git flow feature start blogging-with-git-flow
Now I'm in the draft mode and will create the blog post file, writing, adding images, linking between existing posts, and so on. If this is done I do a first commit and publish the feature branch to GitHub:
git add _posts/* git add img/* git commit -m "new post about blogging with pretzel" git flow feature publish
At this state, I can change and commit as much as I want to. If I finish the blog post, I'm going to finish the post and push the current develop branch to GitHub:
git flow feature finish git push
The last step is publishing the posts. I'm currently not sure, but I could probably use the number of posts as the minor version number, which will also be used as a tag for the release:
git flow release start 1.48.0 git flow release finish git push --all git push --tags
(I possibly should create a batch command to execute the four lines to release new posts)
After that push, Pretzel will start "baking" the blog, including the new blog post. If I want to see the current drafts, I just need to display the existing branches:
I'm sure this will be a clean way to publish and to handle the drafts and finished posts.
While publishing the blog like this, I realized that GitHub actually will display a release in the GitHub repository, this is quite nice. This is not really needed but a funny fact and a reason why I wanna think a little more about the version numbers if I release a new article.
My idea is to change the Major version, if I do a huge change on the layout of the blog or if I add a new feature. Because the layout is still the first version and I only did some really small changes, I'll keep it as version 1. For the minor version, I will use the number of published articles.
This doesn't really make sense from the semver perspective, but blogging should also be fun and this really is fun to me.
This means, with the published release 1.47.0 and this post will be in release 1.48.0.
In my last post on this subject, I wrote that I use MarkdownPad 2 to write my pots. Unfortunately, it seems that this editor is no longer maintained, no new version was published for a while. I paid for it, to have some more extended feature to use. Anyway, a few months ago it crashed every time I opened it and there was no way to get an updated or fixed version (I'm pretty sure it was related to the installation of CefSharp). This is why I now use Typora, which is pretty minimalistic and lightweight. It works completely different but in a pretty cool way. It doesn't use a split screen to edit or preview the content. With typora, you write markdown code directly and it immediately translates it to the preview in the same editor view. It also supports custom CSS and different Markdown styles. It is real WYSIWYG.
Any thoughts on the subject? Feel free to drop a comment and let me know!
Published at DZone with permission of Jurgen Gutsch . See the original article here.
Opinions expressed by DZone contributors are their own.