Keeping a great Changelog

Changelogs are an invaluable, and often neglected part of any software project. So, how do you do that? A good changelog helps you users to understand: Why they should care about your latest version If any of your changes affect the problems or frustrations they’ve been having. If there are any changes that might affect how they use your app / library. Why your efforts are worth their continued support.

Why you can't auto-generate your Changelog

Let’s start by taking it as a given that a Changelog file is something very valuable that every product should come with. Even if your “product” is a library for other developers. With that in mind, the question rises of “How can I make it really easy to generate one”. Many developers have had exactly that thought. There are many free and some paid solutions that will “Autogenerate your changelog from your git commits/tickets”.

Rebasing A Pull Request on GitHub

It’s generally good practice to rebase commits on a topic branch into a single commit before merging. It results in a much cleaner commit history, and makes rollbacks easier. The Question However, the question was raised: what happens if you… fix a bug (commit 1) create a Pull Request get feedback via the Pull Request fix the bug fix (commit 2) rebase those two commits together (new tree-ish) push that back to GitHub (requires push -f ) The answer is based on understanding that a GitHub pull request has two forms of commenting: * comments on the pull request itself * comments on the commits that the pull request encapsulates.

Git: pushing and pulling from multiple repos

Lets assume you’ve already cloned a remote repo and have been working with it. Now, someone has set up a second repo out there for the same codebase, and you’d like to interact with both. *Please note: The following is based on the assumption that you have write privileges to the second repo, but don’t worry, you do essentially the same thing if you don’t and I’ll cover the differences at the end.

Why you should use a distributed version control system

If you’ve ever: made a commit and then realized you forgot “one little change”. made a commit and regretted it. wished you could combine some the past couple days worth of commits into one nice combined commit in the main branch. wished you could commit just part of a file. needed to drop work on one task and switch tracks to another one without having to make commits with unfinished changes, or commits with changes for one issue and a little of another.