Nearly every software developer around the planet depends on numerous tools to get their job done. From languages, frameworks, and collaboration tools, developers require more tools than you might think.
And, besides programming languages, one of the most important tools in the developer toolkit is Git. With Git, your Java, JavaScript, .NET, Python, Ruby, and web application developers can work with internal teams, software outsourcing companies, and other third parties without missing a beat.
In fact, Git is (by far) the most popular tool in its class.
What is Git?
Before we continue, it’s important that you understand exactly what Git is. Git was created by Linus Torvalds (who also created the Linux operating system) to serve as a version control system for the Linux kernel developers. What Git does is track changes in any set of files (most often files related to software development), which allows multiple developers to collaborate on a single project.
One very important aspect of Git is that it works with repositories that house code for either solo or collaborative work. Those repositories can either be locally stored or housed by third-party solutions. The most popular remote repository service for Git is GitHub. As of now, GitHub has over 40 million users and 190 million repositories. No other service can compare to it.
Such popularity makes GitHub a target for hackers. Over the past couple of years, GitHub has experienced a number of breaches. And because so many developers continue to leave secrets in code, those who break into the service can wind up with the necessary credentials to get them into countless businesses and accounts.
That’s why GitHub had to change its authentication policy. Once upon a time users only needed a username and password combination to make Git work with their remote repositories stored on GitHub. That’s no longer the case. And with GitHub about to deprecate the standard username/password authentication process, developers need to know what to do moving forward.
It’s all about the access token
In order to make Git and GitHub work together, developers will now have to use personal access tokens. Personal access tokens work in the same way as ordinary OAuth access tokens and can be used instead of a password for Git over HTTPS. Password tokens can also be used to authenticate to the API over Basic Authentication.
With personal access tokens, developers get more flexibility (as well as security) than with simple password authentication. For example, a developer can create the means for other users to have access to repositories with specific permissions.
Say you want to create authentication for other developers to have full access to repositories, but not admin access or access to notifications. With access tokens, you can do that. Or maybe you want to create a token that would allow access to repositories, but not to repository invitations. For example, you might have a project that uses a certain JavaScript Framework that requires specific repository permissions. You can do that. In fact, with access tokens, you have control over:
- repo controls
- workflow
- write:packages
- delete:packages
- admin:org
- admin:public_key
- admin:repo_hook
- admin:org_hook
- gist
- notifications
- user
- delete_repo
- write:discussion
- admin:enterprise
- admin:gpg_key
As the owner of a GitHub account, you can fine-tune all of the above in order to create an access token that allows other users precisely the access you want to give them to your repositories.
How this affects developers using Git
Here’s the important part of the puzzle. Developers that use Git in conjunction with GitHub can no longer authenticate to their remote repositories with their GitHub username and password. Instead, they must authenticate with their username and an access token.
For example, issue the command:
git push
As expected, you’ll be asked for your GitHub username. Type your username and hit Enter. You will then be prompted for the password associated with that GitHub account. If you type the password and hit Enter, you’ll be informed that authentication failed. Instead, you must head over to your GitHub account and go to Settings > Developer settings > Personal access tokens. From the resulting page, click on the access token you want to use (if you’ve not already created it, you’ll have to do so), and then, when the token appears, copy it to your clipboard.
You can now paste the token in place of the password for user authentication.
Remember, you can create multiple access tokens for your GitHub account, so you want to be sure and copy/paste the token that has the proper permissions needed for the project. That’s where this new system can get a bit confusing. It’s also why you should make sure to give new access tokens names that clearly indicate their purpose (or if they’re for a specific client/project).
Two-factor authentication
It should go without saying that everyone should be using Two-factor authentication with every platform that offers the service. GitHub can now be counted among the many companies that allow users to enable 2FA for their accounts.
Because of the rampant and continuous hacking attempts on GitHub, it’s imperative that you and your developers all enable 2FA for GitHub accounts. This is especially true for any account that is associated with a business. You don’t want to leave that door open for hackers.
To enable 2FA, log into your GitHub account and go to Settings > Account Security > Two-factor authentication. You’ll also need an authenticator app (such as Authy) installed on your mobile device.
Once you’ve enabled 2FA on your GitHub account, you will have to use a new code from the mobile app in order to gain access. This should be considered a must-do for all developers and businesses that use GitHub.
Conclusion
Although the effects of GitHub on developers won’t be drastic, it does change the way you authenticate. Make sure your developers are up to speed with this new authentication method and that they’ve enabled 2FA, to ensure their accounts (and your code) are safe.
