This turned out to be not that simple, as both repositories (Github Pages can only host one branch per repository, so you need two – one organization repository and one personal for example) need to have a CNAME and _config.yml file with different content.

So the actual question to answer was how can one commit and version changes to files in a git fork/branch but then not merge them back into the source, while still having a fully merged branch (so actual changes can be merged back via Pull Requests)?

The answer is to use the ours merging strategy when merging the changes that should be skipped:

Assume we have our production repo and staging repo both checked out locally, for now being identical (and having the same CNAME and _config.yml).

Check out staging, make the changes to the files and commit and push them.

If we were to do a normal merge to production, this change would now get merged over.

But now we run these commands:git checkout production
git merge --strategy=ours staging
(Source)--strategy=ours makes sure that during this merge, the production file remain unchanged. But the commit is still marked as merged.
If we want, we can now also edit the merge commit messageto be a bit more descriptive what we just did: We merged the two branches, but made it keep „our“ (in this case: production) version of the files.

Then push the changes to production:git push production production:master

Your next changes to staging can the be merged with production normally, without getting the CNAME and _config.yml changes.

As I am not a git power user – I use a GUI, SourceTree of GitKraken – for the more complicated commands and features, my mind tends to just „crash“ now and then and forget what they are and how they work.

A bit later I had it figured out again:

Answer myself: Rebase "reapplies" commits by creating "copies" of them. These "copies" can be modified. Rebasing on same "base" = rewrite.

If you have any projects on Github that span multiple repositories you know the pain when someone creates a valid issue, but uses the wrong repo to do so. Of course you could tell them to „Create another issue in the correct repo and gtfo“ but that a) wouldn’t be very nice and b) is a quite a lot of work and c) probably wouldn’t have the intended effect to grow your Github community.

So you need a way to move issues betweens repos.

Github doesn’t support this out of the box, but of course some other people jumped in and created things that do. Here is an overview of my research on this:

If you work on an older version of Mac OS, for example because Apple decided your Macbook is to old to upgrade to a recent version, you might be stuck with Xcode 8.2.x to develop and test your iOS apps. Unfortunately this can lead to this nice error message if you made the mistake to upgrade your iPhone to iOS 10.3:

Could not locate device support files
This iPhone 6s is running iOS 10.3.1 (14E304), which may not be supported by this version of Xcode.

This is because the old Xcode doesn’t get these „device support files“ via updates any more. Luckily the internet is here to rescue you.

trakt.tv offers a very comprehensive API with an amazing documentation. But thorough as it is – and the technical details like authentication, data formats, parameters etc. are really, really well covered – it can also feel a bit overwhelming when you jump in and want to get a first overview, or are only looking for some specific data or type of data.

As I just did exactly that, I went through the whole documentation and extracted the most relevant information. The order of this article, especially the API endpoints, follows the official API documentation. I only added some more headlines to group the endpoints in a better way:

Imagine you have a Google Spreadsheet with a „last active“ column where you e.g. log the date when you last worked on the line item. You don’t want to have to type the date every time you change something as a) typing is cumbersome and b) you don’t even know the current date anyway.

Normally there is a default keyboard shortcut for that in Google Spreadsheets:

Insert time:

Ctrl + Shift + ;

Unfortunately this doesn’t really work with a German keyboard (in Windows 10 with English OS language). In Chrome you can replace the Semicolon with Ü, but in Firefox this doesn’t work and I found no way to trigger this shortcut :(

Two solutions:

Create a field with formula `=TODAY()`, maybe in the second row of the headline of the table. (Unfortunately this value will be recalculated on every change – so you can’t just use THAT everywhere to get the date – this value will change.) Now you can just Ctrl + C to copy that value and then Ctrl + Shift + V to output its value (and not copy the formula) to the target cell.

Add a „Date“ validation to your column. Now you can double click the cell to get a nice calendar tooltip thingie where you can just click on the date you want.

To be honest 1) doesn’t really solve b), but you can leave the formula from 1) in the subheader for that anyway and just use 2) use this instead of the value pasting from 1).

Forestry does the same things as Siteleaf, but a lot better. Collections get their navigation, show the subfolders, front matter and config files stay untouched.The markdown and WYSIWYG editors are… okayish. Markdown view has a few strange bugs and although WYSIWYG is a great preview, using it to edit can break stuff quite fast. Switching between the two also can cause loss of data. Again the real editor is much too small, no fullscreen or „writing mode“ view – I don’t understand why this is not the focus.

Their team is very responsive via Intercom and also seems to fix bugs quite frequently. Let’s hope they continue doing so, then this could get pretty nice.

cloudcannon is a different beast – it actually manages to make your rendered pages editable in their „Visual Editor“. Unfortunately advanced stuff like Automated „Table of Contents“ Generation of kramdown gets overwritten by this. The „Content Editor“ (WYSIWYG without my design) has the same problem and the „Source Editor“ is very sourcy and feels more like an programming IDE.Besides that the Editors are awesome, really great work from the team. You can hide all the UI to make a very focused write environment and everthing seems very thought out.

Prose has no visual editor, no „structured“ view of the file system – but it just works. You can edit files, preview the Markdown, commit it to Github. The editor view is very clean and simple which makes for a great full screen experience. Before saving you also have a „diff“ view, that although a bit rudimentary, gives a great overview of the changes you (accidentally?) created.Although hosted on prose.io, Prose is also open source (since 2012!) and can be hosted on your own server. The instance on prose.io is great though, and you can (ab)use the Github issues as a support channel if needed. Nice people.

So because of the shortcomings of Siteleaf (unusable because of messing with my data), Forestry (buggy editors) and Cloudcanon (doesn’t support advanced stuff) I am actually using Prose right now.

(Of course there also several options you can self host, but as that kind of defeats the purpose to go to a Github Pages hosted static site – now I have o host the CMS myself – I skipped those. Still, some links: MeetHyde, jekyll-admin)