This is July’s GitHub Changelog digest. Subscribe to the Changelog or follow the official GitHub Changelog Twitter account to read about updates as they happen.
Here’s a complete list of last month’s releases:
Strong authentication credentials are critical to preventing malicious access to your account. Everyone on GitHub has a password, so a strong password is an excellent starting point. And, for even stronger assurances, we highly encourage users to enable two-factor authentication (2FA). We’re introducing two new features to help you balance the security, usability, and recoverability of your accounts.
Common password advice is to use a long and unique password for each website you have an account with. It’s challenging to remember a strong and unique password for each website without either using a password manager or using a trivially discovered theme. As a result, password reuse is extremely prevalent. Regardless of the strength of a password, a single breach can nullify its security when used elsewhere.
Several years ago, security researcher Troy Hunt sought to tackle the compromised passwords problem with his HaveIBeenPwned.com project. While Troy hosts a service that people and services can use to check for compromised passwords, he also generously made the approximately 517 million record dataset available for download. Using this data, GitHub created an internal version of this service so that we can validate whether a user’s password has been found in any publicly available sets of breach data.
Starting today, people using compromised passwords will be prompted to select a different password during login, registration, or when updating their password. Don’t worry, your password is protected by the password hashing function
bcrypt in our database. We only verify whether your password has been compromised when you provide it to us.
Using two-factor authentication is a best practice and can help protect you even when low quality or compromised passwords are used. However, two-factor authentication can be a double-edged sword. Two-factor authentication ensures that access to a single factor, such as your password or email address where a password reset can be sent, is not sufficient to access an account. But, if you lose access to your two-factor credentials, it can lead to losing access to your account.
If you have two-factor authentication enabled, GitHub will now periodically remind you to review your 2FA setup and recovery options. We highly recommend using a 2FA authenticator application that supports cloud backups in the event your phone is lost, stolen, or falls in the ocean.
These new account security enhancements will help improve the security of your account. We hope you will take this opportunity to review the security of your account. Balancing security, usability, and recoverability is a personal decision.
If you haven’t already set up two-factor authentication on your GitHub account, visit your account settings and click on the “Security” tab.
The latest version of our Electron-based GitHub Desktop app has just launched. With the GitHub Desktop 1.3 release, you’ll be notified when your branch diverges from your repository’s default branch.
We’ve found that one of the easiest ways to prevent really complicated merge conflicts is to merge early and often. But if you’re working on a branch, you shouldn’t have to lose your focus just to periodically check if there are updates on the master branch. You’ll now be notified about changes on your default branch that are not in your current branch, and hopefully prevent merge conflicts from getting unwieldy:
This release also enables you to more easily keep up with changes across your repositories. You’ll now be able to see which repositories have had recent activity, uncommitted changes, and unpushed changes without having to click into each one:
A new version of Git LFS, the open-source Git extension for versioning large files, is now available. Git LFS v2.5.0 comes with three new migration modes, a handful of bug fixes, and more.
With v2.5.0, you can use the
git lfs migrate command in a few new ways.
Sometimes repositories can get into a broken state when large files that should have been committed with Git LFS aren’t. If your file is over 100 MB, you won’t be able to push to GitHub, and your history will require rewriting with
git lfs migrate import. If you have a file smaller than 100 MB, you can use
git lfs migrate import --no-rewrite to create new commits that move the file to Git LFS, allowing you to repair the state of your repository more easily than ever.
If you have committed a handful of files that should have been stored with Git LFS, but aren’t, you can let Git LFS determine the affected files for you by running
git lfs migrate import --fixup. The
--fixup flag automatically reads
.gitattributes file(s) in your repository, and converts Git objects that should be stored with Git LFS automatically:
In the following example, notice how our .gitattributes file says that
*.png’s should be tracked using Git LFS, but we added mona.png without Git LFS:
$ cat .gitattributes *.png filter=lfs diff=lfs merge=lfs -text $ git cat-file -p :mona.png | file -s /dev/stdin: PNG image data, 896 x 896, 8-bit/color RGBA, non-interlaced
We can easily fix this without having to tell Git LFS which files to start tracking:
$ git lfs migrate import --fixup migrate: Fetching remote refs: ..., done migrate: Sorting commits: ..., done migrate: Rewriting commits: 100% (2/2), done master 1002728154804338fe645976ad8b7258b0be0810 -> 076e2bfe114df5575b1130f694c18d1b26c86b86 migrate: Updating refs: ..., done migrate: checkout: ..., done $ git cat-file -p :mona.png version https://git-lfs.github.com/spec/v1 oid sha256:49afbfc61b10df78377f8f7dac774158e1a0197740e160ea3572d9839c61ac04 size 106277
Now mona.png is stored correctly using Git LFS!
Lastly, if you want to stop using Git LFS and export your large objects, you can use
git lfs migrate export. It accepts the same arguments as
git lfs migrate import, and easily allows you to take files out of Git LFS.
We have updated several of the scripts and programs used to develop and hack on Git LFS to feel more familiar to open source contributors. The test suite now outputs results using the TAP format, enabling it to be run with
prove. Similarly, the project can now be built using a
Makefile, which should feel more familiar to developers comfortable working with Git.
You’ll see a handful of other new features and bug fixes in v2.5.0 like improved support for object alternates, correct
git lfs status output from subdirectories, and more.
For instructions on configuring Git LFS, refer to this article.
Developers use more than one kind of tool to build software. With the flexibility to integrate exactly the right tools for the job, your team can work productively, however you work best. And when software development is accessible, intelligent, and open, you can spend less time calibrating your tool chain and more time focusing on the work that matters most.
Today, we’re simplifying an important part of your workflow: Continuous Integration (CI). We’re excited to be partnering with Google to bring Google Cloud Build to GitHub. Cloud Build helps you create fast, consistent, reliable builds across all languages. With this new integration, you can easily set up CI through Cloud Build and automate builds and tests as part of your GitHub workflow.
“The release of Cloud Build on GitHub Marketplace is the first step in an exciting partnership. Bringing our fully-managed continuous integration to the GitHub platform will provide fast, frictionless, and convenient CI for any repository on GitHub. Google Cloud and GitHub share a vision for developer productivity and we look forward to continuing to build on this partnership.” — Melody Meckfessel, Vice President of Engineering at Google Cloud
GitHub will detect Dockerfiles in the root of a repository and automatically suggest you use a CI tool like Cloud Build from GitHub Marketplace if one isn’t already set up. These smart recommendations will be rolling out to everyone in the coming months.
Cloud Build uses the new Checks API, a better way to get feedback from integrations on your code. Once a build is complete, you can see rich status reports, annotated code, and detailed information—all without leaving GitHub.
From large businesses to open source projects, every team has their own approach to CI. We built GitHub to support yours. And we’ll keep working with our partners to create an open platform, where your team can use the tools they need to stay productive and do their best work on GitHub.
Interested in building on our platform? Contact the Marketplace team to learn more.