I manage my Jekyll blog in a Git repo. My publication process uses 2 branches: master contains all production content, and feature/newposts has the new blog posts, ready to get published, one commit per post. To publish an existing post: I check the to-be-published post in the feature/newposts branch. Then, get the associated commit. And cherry pick it in the master branch. Finally, I push.
I started working with Git some years ago, and to be honest, it was not easy to pick up. It’s a huge beast, and there are several ways that can help to tame it. On the web, most articles focus on creating command shortcuts. In general, this goes like: instead of writing git pull --rebase, let’s create a shortcut to type gpr.
Since its inception, the attitude of GitHub toward repositories was to allow unlimited public repositories, while make private ones paying. Whether it’s a consequence of Microsoft’s acquisition or not, this stance changed recently: GitHub announced private repositories were also made free, for up to 3 contributors. There was a lot of celebration on the Web, but not from my side. This move looks more like a (desperate?) move to keep developers on GitHub. Whether that’s the case
I’m not Git expert and I regularly learn things in Git that changes my view of the tool. When I was showed git rebase -i, I stopped over-thinking about my commits. When I discovered git reflog, I became more confident in rebasing. But I think one of the most important command I was taught was git rebase --onto. IMHO, the documentation has room for improvement regarding the result of option. If taking the image of the tree, it basically uproots a part of the tree to replant it somewhere el