Protected branches make sure the right reviews happen, support passing CI, and prevent force pushes. With our latest update, you can automatically enforce protected branch settings across multiple branches in your repository.
If you’re a repository owner or have admin permissions in a repository, you can now customize branch protections and enforce certain workflows, such as requiring more than one pull request review or requiring certain status checks to pass before allowing a pull request to merge.

Branch protection rules build on our existing branch protection functionality. Instead of setting up individual protections for multiple branches, you can share the same set of protections across different branches matching the same naming pattern.
Branch protection rule patterns are based on fnmatch syntax. You could use releases/v?.? to automatically protect branches like releases/v1.0, releases/v2.0, and releases/v2.1. And [1-9]-[0-9]-stable could automatically protect branches like 1-0-stable, 2-0-stable, and 2-1-stable.
View more fnmatch documentation or learn more about configuring protected branches.
Managing your projects at the organization level just got easier. When creating or viewing an organization’s project board, you can now specify which repositories are most relevant to the project you’re working on. This new feature makes search faster and more relevant by automatically scoping it to your linked repositories.

Link to relevant repositories any time you create a new organization-owned project board—or while actively managing a project. As you manage a project, you can change and add up to five repositories where the work being done for your board can be referenced.
Linked repositories will appear on the project board list, making it easier to find your board and understand, at a glance, where work is happening within your organization.
Learn more about linking repositories to organization project boards
As of July 2018, GitHub Education has helped over one million students learn to code. Teachers around the world use version control to help students collaborate on software, participate in open source communities, and automate administrative tasks. But what impact does using GitHub have on students? What do students learn by using GitHub?
Education General Manager @mozzadrella and I wanted to find out how using GitHub in the classroom shapes learning outcomes for the 2018 GitHub Education Classroom Report. We surveyed 8,000 students and teachers who had (and had not) used GitHub in the classroom. This post will give an overview and key takeaways.
Overall, we found that how classrooms used GitHub matters—and that students benefited from using GitHub in the classroom in a few important ways. Compared to students who didn’t use GitHub in their courses, students who did:
Think of learning outcomes as goals for students. The education field uses these goals to design curriculum and to assess what students know.
In our survey, we focused on these key areas: preparation for the future, classroom experiences, developing a sense of belonging, feedback, and the experience of learning to use GitHub.
We compared answers from respondents who used GitHub and those who did not use GitHub in the classroom. Generally, we looked at what the average respondent reported, so the findings may not apply to every classroom.
Using GitHub (versus not using GitHub) in programming classes predicted greater positive learning outcomes:
Using GitHub (versus not using GitHub) in programming classes predicted a greater sense of belonging, a variable important to academic success:
Of the students who used GitHub in the classroom and received teacher feedback, those who received (versus did not receive) feedback via GitHub benefited more from teacher feedback.
Students felt they used their teachers’ feedback more effectively and found the feedback more helpful:
Students felt their teachers were more aware of their needs as a student:
Students needed more support from teachers and peers when learning to use GitHub. About a quarter of students felt they received less support than they needed from teachers, and about a third of students felt they received less support than they needed from peers.
@mozzadrella, who is also an instructional designer, sees important conclusions in the data around developing a sense of belonging and self-efficacy:
This study offers on-ramps to help more people succeed in Computer Science education. We now know that using GitHub in the classroom predicts a greater sense of belonging, which is related to persistence, overcoming obstacles, and overall academic success.
Feedback is a huge piece of learning, and students say feedback delivered through GitHub is both more effective and more helpful. Better feedback leads to better code. This is an urgent insight that will move the entire education field forward.
The last key insight is about student success: Students who use GitHub in their technical courses report being more prepared for future coursework and for work in industry. This has wide-ranging implications for student engagement in technical education.”
As the school year starts, teachers can use these insights to calibrate for the needs of students. Teachers who are looking for help getting up to speed on GitHub can use the online teacher training in Campus Advisors, or sign up to find out more about GitHub Education.
It was an exciting opportunity to conduct this study. As my background is in psychological research, I’m naturally curious about how different variables shape learning. The big questions we took on challenged me to put myself in the students’ shoes. And as a teacher myself, insight to the challenges students face and how resources may be leveraged to boost positive learning outcomes is incredibly valuable. Thank you to everyone who participated in our research. We look forward to sharing more research findings with you in the future.
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:
Js13kGames is a month-long JavaScript coding competition organized by @end3r. Running since 2012, it challenges participants to create a game in 13 kilobytes or less of JavaScript based on a theme that’s announced at the start of the competition.
Bonus: This year there’s a WebXR category meaning web developers can experiment with virtual reality experiences for the competition. For this category, you’ll have the same file size limit of 13 kilobytes, but you’ll get A-Frame or Babylon.js for free!
Developers of all skill levels are welcome to participate. It’s a great excuse to learn or level up your JavaScript, learn or improve upon game development skills, and have fun sharing your ideas. The theme for this year’s competition will be announced on August 13 at 13:00 CEST.
With final package sizes having to be 13kB or less—and most JavaScript game engines and libraries being much larger—the size limit does pose an interesting challenge. Thankfully, past participants have shared some of the micro game engines they’ve created specifically for js13kGames. Rather than starting from scratch, check out and use some of these engines:
Boilerplates and engines like @xem’s platform-engine, @kittykatattack’s Ga are useful for creating 2D arcade and platform games.
Kontra.js by @straker is a lightweight and highly modular library that allows you to pick what you need and stay under 5kB.
Create a simple sprite and game loop in just a few lines of code using Kontra.js:

var sprite = kontra.sprite({
x: 100, // starting x,y position of the sprite
y: 80,
color: 'red', // fill color of the sprite rectangle
width: 20, // width and height of the sprite rectangle
height: 40,
dx: 2 // move the sprite 2px to the right every frame
});
var loop = kontra.gameLoop({ // create the main game loop
update: function() { // update the game state
sprite.update();
// wrap the sprites position when it reaches
// the edge of the screen
if (sprite.x > kontra.canvas.width) {
sprite.x = -sprite.width;
}
},
render: function() { // render the game state
sprite.render();
}
});
loop.start(); // start the game
It’s definitely not cheating to submit minified version of your code to make it fit within 13kB. It’s almost a necessity. Tools like @xem’s s miniMinifer and @google’s Closure Compiler are heavily used by participants to minify code.
“Don’t worry too much about names, or golfing. The best way to make an entry is to concat everything in one file, minify, zip and use advzip (to save an extra 1kb over regular zipping)!” - @xem
Tip: You can keep the original, unminified source code in your repository and work the minification into your build process or manually upload the minified version during the competition submission process.
Your game probably won’t have many images given the size constraints. Whether you’re taking existing assets from websites like OpenGameArt.org, or creating your own using something like Piskel or Poxi, you’ll want to compress them as much as possible. Be sure to run your images through optimization tools like @catid’s Zpng or @voordmedia’s TinyPng.
Adding audio to your game can quickly raise your total project size, but it definitely adds to its appeal. Luckily there are some great tools and techniques you can use to generate your own audio.
Generate all sorts of weird blips and bleeps using @grumdrig’s jsfxr, or hit the music studio with @Mbitsnbites’s HTML5 synth music tracker/editor SoundBox. @xem’s miniMusic even lets you draw your masterpiece!

And play it back:
with(new AudioContext)[4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,6,6,6,6,6,6,6,6,6,6,6,6,6,7,7,7,7,7,7,7,7,7,7,7,7,8,8,8,8,8,8,8,8,8,8,8,9,9,9,9,9,9,9,9,9,9,9,9,10,10,10,10,10,10,10,10,10,10,10,10,10,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,13,13,13,13,13,13,13,13,13,13,13,14,14,14,14,14,14,14,14,14,14,14,14,14,15,15,15,15,15,15,15,15,15,15,15,15,16,16,16,16,16,16,16,16,16,16,16,16,17,17,17,17,17,17,17,17,17,17,17,17,17,18,18,18,18,18,18,18,18,18,18,18,18,18,18,18,19,19,19,19,19,19,19,19,19,19,19,19,19,19,19,19,19,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,21,21,21,21,21,21,21,21,21,21,21,21,21,21,21,22,22,22,23].map((v,i)=>{with(createOscillator())v&&start(e=[7,8,9,10,11,12,13,14,15,16,17,18,19,26,27,28,29,30,31,43,44,45,46,47,48,49,50,51,56,65,7,8,9,10,11,12,13,14,15,16,17,18,19,24,25,26,27,28,29,30,31,37,38,42,43,51,56,57,64,65,12,13,24,25,26,27,31,38,51,56,57,62,63,12,13,23,24,25,38,50,51,56,57,61,62,12,13,23,24,38,48,49,50,56,57,60,12,13,23,24,38,45,46,47,48,56,57,59,12,13,23,24,38,44,45,46,47,48,56,57,58,12,13,23,24,25,26,27,28,29,30,38,48,49,56,57,12,13,23,24,25,26,27,28,29,30,31,38,49,50,56,57,12,13,30,31,32,38,50,51,56,57,58,7,8,12,13,31,32,38,51,56,57,58,59,60,7,8,12,13,31,32,38,51,56,57,60,61,7,8,12,13,31,32,38,51,56,57,62,63,7,8,9,12,13,31,32,38,51,56,57,64,65,7,8,9,10,11,12,13,31,32,38,51,56,57,65,66,7,8,9,10,11,12,13,31,32,38,49,50,51,56,57,66,67,8,9,10,11,12,22,23,24,25,26,27,28,29,30,31,32,37,38,44,45,46,47,48,49,56,57,67,22,23,24,25,26,27,28,29,30,37,38,56,57,67,68,56,57,68,68][i]/5,connect(destination),frequency.value=988/1.06**v)+stop(e+.2)})
After the competition ends, some developers publish retrospectives—fantastic resources on what to do and what not to do to maximize your productivity (and your game’s playability) within the constraints of 30 days and 13kB.
If playing the games, viewing the source, and reading the developers’ retrospectives from last year’s event would be helpful, here are five of our favorites:
A Day in the Life is a minimalist endless runner controlled by just one button. It was created by @MattiaFortunati using Kontra.js, TinyMusic, and PixelFont–a novel way to squeeze a font into an entry.
View the source
Play the game
Read the postmortem
In LOSSST by @xem, you’re a puzzle-solving snake looking for a lost kid. Warning: the game is very addictive and the postmortem contains everything from the thought process coming up with the design to focused game implementation details.
View the source
Play the game
Read the postmortem
In Greeble by @Rybar, you control a space-mining bot searching for enough fuel and parts to repair and explore.
View the source
Play the game
Read the postmortem
@ElementalSystems’ Lost Packets is an abstract puzzle game where you help lost packets reach their destination—very impressive work for only 40-50 hours of work on nights and weekends.
View the source
Play the game
Read the postmortem
In Vernissage by @Platane you’re lost in a museum showcase low resolution works of art as a series of colored dots. Explore the world in VR or in browsers thanks to A-Frame–a web framework for building virtual reality experiences. The postmortem includes great detail on the genetic algorithm used to generate the art pieces.
View the source
Play the game
Read the postmortem
The js13Kgames website lists even more resources and retrospectives that should prove useful. If there’s something you’d like to add, please create an issue (or better yet, a pull request) on https://github.com/js13kgames/resources.
Follow @jsk13kGames on Twitter or visit the website on August 13 at 13:00 CEST (4am PT/7am ET) to find out what the theme will be. You can also use the hashtag #js13k to see how others are doing and to share your progress.