I am very excited to announce that Microsoft is acquiring GitHub and expect the agreement to close by the end of the year. While it will still take a few months to finalize, we wanted to share the news as soon as we were able.

When GitHub first launched ten years ago, I could have never imagined this headline. Git was a powerful but niche tool, clouds were just things in the sky, and Microsoft was a very different company. Open source and business, people said at the time, mixed as well as oil and water.

We disagreed. As developers, we knew this was a false dichotomy—we had been using open source software successfully in a business setting for a long time. What we really needed was an easier way to work with others regardless of whether the code was public, private, or something in-between. We wanted to do it using Git, we wanted anyone in the world to be able to join in, and we didn’t want it to cost a dime if it was open source. So we created GitHub.

Now, of course, things are different. Git is far and away the most popular version control system, clouds are mostly computers, and Microsoft is the most active organization on GitHub in the world. Their VS Code project alone is beloved by millions of developers, entirely open source, and built using GitHub’s Electron platform. Beyond that, today major enterprises regularly embrace open source. The world has realized how important happy, productive developers really are. And also, people have smartphones now.

What hasn’t changed, however, is our focus on the developer. From the beginning, we have been obsessed with building a product for the people using it. We want to make developers more productive and we want more people to become developers. From “Code to Cloud and Code to Edge”, GitHub’s mission is to help every developer—regardless of experience level—learn, code, and ship software effectively.

So as we look to the next decade of software development and beyond, we know it’s all about the developer. And as we’ve gotten to know the team at Microsoft over the past few years through collaborating on projects from Git LFS to Electron, we’ve learned that they agree. Their work on open source has inspired us, the success of the Minecraft and LinkedIn acquisitions has shown us they are serious about growing new businesses well, and the growth of Azure has proven they are an innovative development platform.

But more than that, their vision for the future closely matches our own. We both believe GitHub needs to remain an open platform for all developers. No matter your language, stack, platform, cloud, or license, GitHub will continue to be your home—the best place for software creation, collaboration, and discovery.

We both believe that software development needs to become easier, more accessible, more intelligent, and more open, so more people can become developers and existing developers can spend more time focusing on the unique problems they’re trying to solve.

We both see the growing need for developers and the growing importance of software in all facets of our lives.

And, most importantly, we both believe we can do greater things together than alone. Collaboration, after all, is at the heart of everything we do.

As part of this change, Nat Friedman will be taking on the role of GitHub’s CEO. We have been searching for a new CEO for some time and found in both Microsoft and Nat a partner we believe will strengthen and grow the GitHub community and company over the next few years. Nat has a ton of experience with software and the open source software community, having co-founded Xamarin and worked on numerous open source projects over the years, and is the perfect person to help GitHub grow and continue to make life better for developers.

As for me, I’ll be taking on a new role at Microsoft working closely with Nat and the team, and will share more details on that in the future.

I’m extremely proud of what GitHub and our community have accomplished over the past decade, and I can’t wait to see what lies ahead. The future of software development is bright and I’m thrilled to be joining forces with Microsoft to help make it a reality.

@defunkt
CEO & Co-Founder, GitHub

So you’ve given an assignment to your students in GitHub Classroom, either individually or in groups. But have you given a thought to how your students will work in a way that you can give them useful and instructive feedback?

One approach is linear: students make one commit a time on a single, master branch. In GitHub, teachers can give feedback on a sequential history by commenting on individual commits: view a diff, hover over any line, then click + to start commenting.

For students and teachers alike, this is a straightforward approach, but it’s a little limited. It doesn’t mirror the workflow software development teams use outside the classroom. And what if we want to work collaboratively, in a way that fits with the branch, commit, and merge tools that Git gives us? Then that’s where pull requests come in.

Pull requests build on the branching model of Git. A pull request is GitHub’s way of organizing the merging of two branches, whether it’s within a repository or in between forks. Pull requests make space for collaboration and conversation during the development process. In this post, we’ll walk through setting up a pull request workflow for submitting student exercises and leaving feedback.

Pull requests for individual exercises

By starting with pull requests, even for individual assignments, students can develop the skills and collaboration mindset that will help them when it’s time to work with others on a team. Pull requests allow students to experiment and document their processes and let educators give feedback on their progress. It works a bit like this:

1. The student clones their assignment repository to their local machine.
2. They start a new branch to work on solving a problem.
3. They work on their branch by committing their changes as they go, leaving a trail descriptive commit messages.
4. When they’re ready, the student opens a pull request. In the pull request message, they can describe what problem they’re solving, how they’re thinking about it, and why it’s a good solution.
5. The teacher responds to the pull request by:
   • Adding to the threaded discussion
   • Leaving line-by-line comments on the diff
   • Making a pull request review that combines an overview comment with contextual commentary

Compared to comments on commits, a pull request is a great place for discussion. Authors and reviewers can comment on specific lines, leave Markdown-formatted messages, or give emoji reactions 👍⭐. The student can even push new commits to the to-be-merged branch, amending the original pull request.

When the student and teacher are happy with the result, they can press the big green Merge pull request button, bringing the changes into the master branch (or another development branch). After a successful merge, you can tidy up by deleting the dangling branch with a one click.

Pull requests for group exercises

For group assignments, pull requests become an especially important tool for coordinating the work of many. In a collaborative workflow, pull requests open up new ways for educators to understand their students’ development. It works like this:

1. Each student clones the repository to their local machine and starts a unique branch to work on their part of the assignment.
2. The students work on their branches, committing changes and pushing their branch to the shared repository.
3. When each student finishes their part of the assignment, they start a pull request.
4. The students work together to review the proposed changes, discuss improvements or alternatives, and resolve conflicting changes arising from concurrent development.
5. When the students agree on a resolution, they merge each pull request.
6. After the assignment, the teacher leaves additional feedback in the pull requests.

As in individual assignments, pull requests give teachers the chance to peek into their students’ process. The repository’s own Insights tab can give a big-picture view of the students’ work, such as the number of open and merged PRs, frequency of commits, or who has contributed to the repository. A closer look at the pull requests themselves can show the team dynamic: how quickly students respond to PRs, what they say in comments to each other, and how they resolve conflicts.

Groups’ pull requests become a great place for teachers to give feedback, continuing the students’ conversations. Want to bring something to a specific student’s attention? An @mention—the @ symbol followed by a username—notifies the student directly. You can even comment on merged and closed pull requests, just like you would an open one.

Whether your students are working individually or in groups, pull requests are a great way for them to sharpen their workflow and for educators to guide their students. To learn more about using pull requests to work collaboratively, check out the Campus Advisors training module 3—it goes in depth on pull requests, resolving conflicts, and more—or scope out the GitHub Glossary to refresh your collaboration vocabulary. If you’re having any trouble wrapping your head around all this, check out how other teachers are learning about pull requests in the GitHub Education Community.

P.S. Have you been building up your assignment repositories over several semesters?

If so, chances are you have a pretty lengthy commit history by now. Here’s a workflow, inspired by Dr. Diosino, that gives students a clean commit history so they won’t be distracted by your past activity. Here’s how to do it:

1. Create a new repository. This one will be the pristine copy that your students will see.
2. Clone the new repository to your computer.
3. In your clone, pull the changes from the long-lived **repository. Run git pull **
4. Squash (abbreviate, in Git parlance) the history. Run git rebase –root –interactive and follow the instructions Git gives you to collapse many commits into one previous commit.
5. Push the new, abbreviated history to your new repository. Run git push origin.

Last month, we let you know of some updates to our Privacy Statement and Terms of Service and asked for help from our community. Thanks to everyone who commented and contributed feedback in our Site Policy repository, the updated Privacy Statement, Terms of Service, and Corporate Terms of Service are now in effect!

The updates

• Privacy Statement: As we mentioned in our blog post last month, we are proud to announce that our data protection practices are compliant with the GDPR for all our users, no matter where you live. This includes GitHub and our products and services like GitHub Pages, Atom, and Electron. Please check out the updated Privacy Statement or the Site Policy pull request to see what’s changed
• Updates to our Terms of Service and other policies: We made some changes to our Terms of Service and a few other policies. If you want to see the changes to our Terms of Services or Corporate Terms of Service, check out the pull requests or go to our Site Policy directory for the live policies.
• Update Release: If you’d like to see how our policies have changed over time, visit the “Releases tab” in the Site Policy repository and download copies of updates to our terms over the last year.

What this means for you

Updates to our Privacy Statement and Terms of Service are in effect as of today, May 25. You can accept them by continuing to use GitHub. Again, thank you so much to our user community for helping us improve our terms. Please let us know if you have any questions about the updates.

RightsCon—an annual conference on human rights in the digital age—brought together more than 2,000 people from 115 countries last week in Toronto. On the first day of the conference, we joined non-profits, academics, and other tech companies for a session on working together to protect and promote human rights.

Alongside conversations on bias in artificial intelligence (AI) decision-making and cybersecurity capacity-building, we led the discussion on working with our community to develop the policies that govern the use of our site. In the face of public discourse on who should be deciding what speech is legal—and who should be held accountable for these decisions—we provided this example of how a platform can adopt rules through a transparent, democratic process.

At the session, we also highlighted several other ways in which our policy work promotes human rights, like freedom of expression and privacy. Some examples:

Free expression

To promote freedom of expression, we limit censorship by making sure requestors meet our detailed requirements for takedown requests and by limiting the impact of the takedown when possible. For example, we geo-block content that isn’t illegal in all jurisdictions and, when possible, ask users to remove parts of a repository that contain infringing content, rather than blocking an entire repository. In addition, we promote the right of access to information (related to the right to free expression) and transparency by publishing transparency reports and posting takedown notices in real time in our government-takedowns and DMCA repositories. We also described there (and at another RightsCon session) our work on the global implications of the EU’s copyright proposal on free expression.

In our submission to United Nations Special Rapporteur David Kaye’s upcoming report on content moderation and free expression, we note that our approach is consistent with international human rights law. As many speakers at RightsCon pointed out, those international standards are useful for companies looking for a baseline for evaluation that applies to users globally, without imposing one country’s norms on countless others.

Privacy

Millions of developers trust us with their data—and protecting their privacy is a top priority for us. We didn’t need to change the way we handle user data to comply with the EU’s General Data Privacy Regulation (GDPR), which recognizes data protection as a fundamental right. We are proudly in compliance with the GDPR ahead of the law’s deadline this Friday.

Anti-slavery and child labor

GitHub’s Statement Against Modern Slavery and Child Labor outlines the steps we take to make sure modern slavery and child labor are not in our business or supply chain. RightsCon participants were interested to hear how companies that aren’t typically associated with these abuses are taking steps to show how they prevent them, including by placing requirements on their suppliers.

Beyond these examples, a human rights perspective runs through much of our work, such as immigration, open source, net neutrality, and cybersecurity. Hopefully, this illustrates how important it is for tech companies to consider the human rights implications of so much of what we do.

Coming off the heels of an invigorating week of learning and collaborating at RightsCon, we look forward to continuing our work to keep the internet free, open, and secure, and to protect human rights.

A fresh release of our Electron-based Desktop app is here! GitHub Desktop 1.2 ships with new features and enhancements that help you stay up-to-date with your coworkers’ changes and keep you in sync with your team.

Compare branches

Now you can compare your branch to any other branch in the repository, like your master or base branch, and merge that work into your current branch—and there’s more to come.

Multi-file select

In previous versions of GitHub Desktop, you could either perform actions, like discarding changes, on one file at a time or all files at once. Now you can select multiple files to perform an action on by holding down Shift or Command/Ctrl and clicking on the files you want selected.

Community involvement

GitHub Desktop is open source. Thanks to our community, we’ve merged 26 contributions from 18 different contributors. Since launching 1.1 in February, we’ve fixed bugs, improved existing features, and extended GitHub Desktop. In fact, our multi-file select feature started as a pull request from our community :heart:. We’d love to have you join us and contribute to future versions of Desktop.

Check out our release notes to learn more.