Inserting a new commit in the Git history

Most tutorials about Git history rewriting state that history should never ever be rewritten. Like all principles, it depends mostly on the exact context. The principle should probably be updated like this: Public Git history should not be rewritten The reason is that once the Git history has been pushed, it has been made public: other developers might have started working on top of it. Then, and only then, is rewriting the history an issue. It also means that sometimes, there are reasons

Git cloud GitHub GitLab Bitbucket

Git service providers comparison

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


The multiple usages of git rebase --onto

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