There's more than one reason that I try to avoid GitHub. This post is about one of them.
Avoiding GitHub can be difficult, because it seems like almost everybody is using it. Fortunately, there are enough projects that don't include "not having a GitHub account" as a barrier to entry that if you're just looking for somewhere to participate, then you've got choices. Bonus points: in the world of open source GitHub is relatively new in the grand scheme of things, and many of the aforementioned projects that don't revolve around GitHub are that way because they predate it. So if you're contributing to one of them, it's likely that your contributions are going towards something that has shown it has staying power.
Unfortunately, there are times when you're not "looking for somewhere to participate", but instead "looking to fix something in project X"―and it turns out that project X is on GitHub.
So even though I'd like to avoid it, I still frequently find myself needing to use GitHub in order to participate. Really frequently. As in, like, daily.
The especially problematic thing here is that one of the biggest issues I have with GitHub is how it doesn't give you a choice about whether you want to opt in to the social network side of the site. If you have an account and you're participating in a project in any way through github.com, you're part of its social network. In fact, even if you have an account but never, ever use it to log in or touch anything, you're usually still part of the GitHub social network because your commits are probably getting linked to your account through your email address.
Since there is no way to select a GitHub-without-the-social-network "plan" when creating an account, I've adopted a set of routines to approximate it. Here are some things that anyone can do to keep a low profile on GitHub while staying active and contributing to projects hosted there:
Prioritize offsite contribution channels. Especially for those with long histories, many projects have a public face on GitHub as just a way to make it easier for contributors who prefer working there, and is not meant as the be-all-end-all for participating. If you're aiming to avoid GitHub, look for channels like mailing lists, self-hosted wikis, and real-time chats. If a project has any of these, it's likely a sign that they accept fixes and other input without requiring that it originate on GitHub.
Even if you can't find these, you can try sending a personal email. Maintainers, especially those of smaller projects that don't get much love, are sometimes just happy you're interested in sending in fixes and don't care whether or not you're doing that through a work item on GitHub.
Use a different email address for your commits. I already hinted at this before. Let's say you created an account on GitHub x years ago, poked around, and promptly abandoned it. Meanwhile, you've kept participating in one or more projects hosted elsewhere—maybe they're not even using Git for their source control. Suppose that at least one of those projects, though, is pretty popular, so somebody has used something like hg-git or a similar VCS conversion utility to push a mirror to GitHub, and forks abound. Your email address is in the commit log, but does that mean your activity will also show up in the GitHub contribution graph for that stale account you decided not to use? Yup.
Getting around this is as straightforward as making sure the email linked to your account is different from the one(s) in the commit log. You could use a throwaway address in your GitHub profile, but if you want the address in your profile to be your primary one that you generally make yourself reachable at, it requires using some trickier tricks.
The way I work is to never stamp my commits with my primary email address. If you already have wildcard addresses set up for your email (or use aliases set off by plus signs in your Gmail address), it's easy.
For example, I've never been a cpython contributor, but if I were I might use the address "84c2d27176e81dfa@x.colbyrussell.com" in my commits. That address is a live one, so if anyone were really wanting to get in touch with me there, they could. Alternatively, if they're a real live human they can probably figure out even more ways to reach me after coming across that address.
(There are other benefits to using these kinds of wildcard addresses. Reminder: email addresses in commit logs are public. This is not that big of a deal, nor should it even be surprising to hear, but it is for some. Making liberal use of wildcards/aliases with the online services you use will let you cut off a source of spam at the head, should you ever start running into problems with it.)
If you decide to start using wildcard addresses, but you already have a backlog of older commits containing your other address—as described before—then there's something you can do to take care of that, too.
Reset your account. GitHub doesn't actually have a "reset my account" button, so when I say to reset an account, what I mean is to delete it and recreate it. For that reason, when you do it, you really are wiping the slate clean.
This might sound crazy, and out of all the practices described here, it probably is the craziest on a conceptual level. But it's not actually an altogether time-consuming process. You can go from an account that needs to be reset to "done", including a full profile with contact details, in a few seconds.
If you're having to make really heavy use of GitHub, however, then even those seconds will add up. You could minimize the impact and consider adopting a routine where you have regular times for resetting your account—like once before lunch and once before the end of the day.
Batching your activity so that you're storing everything up to send out at once is another approach that can be applied on top of adopting a schedule of loosely defined reset times. If you time it right, you can make sure that nothing you send out is ever more than a minute or so away from an impending reset.
As far as account resets go, there is one exception to the blank slate description I used above. If you're not using a different email address in your commits, your old commits won't show up in your GitHub feed, but anyone browsing the commits will get linked to your profile, even across account resets. This may or may not be a desireable outcome for you, and I don't have any tips for how to handle it if it's not.
Prioritize patches and vanilla pull requests over GitHub PRs. A "pull request" isn't really a tangible thing with Git. It's just any message meant to communicate that you'd like for someone to pull in some changes you've made. Having said that, Git does include a command to generate a nicely formatted message for this purpose (
git request-pull). The format it uses is fairly self-explanatory, and if someone is staring at a pull request message generated bygit request-pull, it's actually easier to merge the changes from that than it is to go through the GitHub UI to do it.Caveat: All pull requests, whether they're the GitHub flavor or not, will require that you set up public repo somewhere allowing the changes to remain accessible until the maintainer merges them. You can host on bitbucket.org or gitlab.com but the downside is that both have social networks of their own. Self-hosting is also an option.
Caveat #2: No matter what, there will be some people who aren't open to integrating changes that don't originate from within GitHub, which means if you want to get them upstream then you'll need to file a GitHub-style pull request, which itself means you will need to create a fork on GitHub.
For the most part, you can file GitHub-style pull requests without it interrupting your ability to reset your account. When you reset your account, GitHub tells you that you will lose all of your issues and pull requests, but that actually only refers to the data for the repos you've created.
Resetting an account after filing a pull request leaves the pull request and its comments still available on GitHub, and the maintainer will still be able to to merge your changes. The only difference is that if there are merge conflicts and the merge button in the GitHub UI can't be used, then the command-line instructions GitHub offers up to the person doing the merge will be different. For pull requests from repos that have been removed, GitHub explains how to apply a patch instead of how to
git pullfrom the now-nonexistent repo. They both work out the same, though, and in the end if the maintainer is requiring you to file a GitHub-style pull request because they're not comfortable using Git or anything besides GitHub's merge button, then this isn't even something that they will ever notice.(Incidentally, instead of the forks-and-branches approach, a patch-based approach is the right solution for most one-off changes. But that's another topic in the "reasons I avoid GitHub" series.)
Caveat #3: Any changes you want to make (e.g., to address reviewers' comments) will need to happen in a new pull request if you've reset your account.
As I mentioned, these are all a part of the routine that I end up practicing every day. You might make different choices. For example, I have used GitLab to host some publicly accessible forks because I see having some presence there as less problematic than what happens at GitHub.
As far as wildcard addresses go, ideally, every commit would be using a unique address, but I haven't done anything to automate that. As it happens, there is some address reuse among the commits I push out.
And I haven't had to do it up to this point, but if things get especially onerous, I would consider whipping somethingup using the GitHub API or a browser extension to help out with batching my activity.
With that all said, here are some things not to do when trying to maintain a low profile on GitHub:
Don't write a script to automate account resets. It may be tempting, especially if you find yourself doing it a lot. However, registering an account through "automated methods" is against the GitHub terms of service.
Don't just create one account for each contribution you plan to make through github.com, e.g., so that you don't have to worry about deleting them. Unless you're paying for all those accounts, this is also against the GitHub terms.