It took me a while to figure out the correct collection of magical incantations required to make RuboCop run in a GitHub workflow, but ONLY on the files that were changed within the PR. This is a useful configuration if you have a codebase that has not yet been modified to satisfy all your “Cops”. I’ve also included a version of the same file that you can use when you’re ready to have RuboCop run on all non-excluded files.

Table of Contents Overview The Goal The Process The Learnings Overview Following on the heels of my last post on why you should (not) self host your git repos, I went ahead and used Gitea to set up a local mirror of all my repositories, and all the repositories I don’t want to loose access to. The results were surprising, and after reading this, you might want to do the same.

Table of Contents Why You Should Self-Host ➠What about GitLab and other Competitors? Why You Shouldn’t Self-Host So what’s a geek to do? What am I going to do? Once upon a time, GitHub was a successful geek enterprise. Then Microsoft bought it, and folks started arguing that you should abandon ship. You should self-host your repos they say. I 100% agree, and 100% disagree. Let me explain. GitHub’s been a benevolent host.

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. A great changelog does all that, and shows the personality of your team.

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”.

Finding the Github pull request associated with a branch. Work on a large enough project, with other people and sooner or later you’re going to find some commit, or branch, and want to know what was in the pull request that merged it in. Maybe you want to see what other commits got merged over at the same time. Maybe you want to see what the diff was at that point in time.

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.

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.

Using Git Bisect …to crush your enemies and/or bugs Or, how to save countless hours and find out where things broke Git bisect is the most awesome, and most poorly publicized feature of git. It allows git to walk through your branch and quickly find out which commit broke things. The usage is simple. You point git to a bad commit ( usually the most recent one ) and you point it to a good commit (the most recent one you know of when things were working).

Every week I, and millions of developers like me, have to put together a status report for our bosses, letting them know what we’ve been up to for the previous week. Like most of the developers I’ve encountered I’m always a little unsure of what *exactly* I was working on, and typically I just open up git to see what commits I made, and try to remember any non-code stuff I’ve Thinking it was silly to keep wading through everyone’s commits for the past week to see what I worked on I’ve put it all together in a script (in Ruby) called git status-report, which you can grab from github here.

Rebase is one of the most powerful tools in Git’s arsenal, but it can trip up people coming from centralized version control systems. This is just a quick example of why, and when, you’d want to use it. Let’s say we’ve got a team of three developers. Monday morning they all come in, Bob makes a quick commit, and shares it with everyone. They all do a git pull and suck it into their repos.

John Kelvie said: [To] me the fundamental challenge with existing version control systems is the difficulty of merging change sets from multiple developers across the same set of code. To me, this issue comes down to the diffing/merging functionality provided by the software, and I haven’t seen or heard of anything that really improves the state of the art. How does GIT address this? How does it make it easier to do?

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.

Sometimes you just want to distribute the source code without its history, and that’s where git-archive comes in. git-archive will create an archive of the files at any point in the history and wrap them all up for you in a tar or zip (defaults to tar). You can even make an archive from a remote repo by using the —remote=<repo> option in the administrator has enabled it. You’ll typically use git-archive like this:

There is also an SVG version of this flow, which is more readable (but poor IE folks will have issues). Notes: This is a simplest possible configuration. Be sure to check out the docs for git-remote to see how to, optionally, designate specific local or remote branches. Many of the initial commands could be performed locally and then just uploaded to the server. This particular sequence guarantees that all the connection pieces are in place and working correctly.

Not too long ago I decided to start writing a book about distributed version control. I was originally going to focus on Mercurial (Hg) because it’s quite good and of the two leading systems it was the only one that ran on every OS (because it was written in Python). The fact that it could also run under Windows meant that I could help spread the word about distributed version control to more people, and it slightly increased the chance that I might actually make some money in the process.

The best thing about Distributed Source Control Managers ( IMNSHO ) is how quick and easy it is to branch and merge. The problem is that most of us cut our teeth on centralized systems that couldn’t even hope to take advantage of cherry picking, which is, in short the ability to take a single patch out of the middle of a sequence of patches, or every patch but one from a sequence.

I was reading some articles yesterday that finally made the light bulb go off about distributed source control management (scm) and why we should be using them. First off, a distributed scm, unlike CVS or Subversion, has no central repository that all others pull from. It’s possible to set one up and say that it’s the master and tell people to pull from and push to it but that’s more a matter of convention.