It’s been two years since the first cohort of student leaders became GitHub Campus Experts. In that time, more than 100 Campus Experts in 20 countries have made their campuses a better place to learn about technology. As GitHub Interns, they have built tech communities in Africa, organized inclusive conferences, and shipped amazing projects.
Now it’s your turn! If you’re a student—age 18 or older—using the Student Developer Pack, you’re eligible to apply for the next class of Campus Experts. Once accepted, you can access the Campus Experts training and develop skills in public speaking, workshop design, and community management. You will also receive training and mentorship from GitHub employees, opportunities to participate in exclusive events, and support to help you grow the developer community at your school.
With the release of GitHub for Visual Studio 2.5.5, pull requests now support checks and statuses.
Checks and statuses—like continuous integration builds or deployment services—determine if the conditions set for a repository are met. Once checks and statuses are set up, every commit will show a status of pending, passing, or failing for each check.
Bringing this functionality to Visual Studio provides necessary information to review and merge pull requests. It also takes us one step closer to building out a complete pull request workflow. Huge shoutout to @stanleygoldman for making this happen!
When you enable checks and statuses for a repository, the pull request list view shows the status of each pull request. The status displayed is that of the latest commit.
In the detail view, you’ll see a section for “Checks”. Expanding the “Checks” sections shows all the individual checks and their respective statuses.
Clicking Details next to each check will open the URL to the service where you can view more information and logs. When a check fails, for example, you can open up more details in your browser to see what went wrong.
Reach out to @GitHubVS to let us know what you think about this new functionality—and follow the latest updates on our work.
We’d also love to hear from you if you run into bugs or limitations in GitHub for Visual Studio. Feel free to open an issue in our repository. Or if you want to contribute to our extension, review our README, peruse our Contributor Guidelines, and join the fun!
Finally, if you’re interested in participating in usability studies around our extension, we invite you to fill out a short survey.
At GitHub, we want to build experiences that make it as easy and intuitive as possible for all developers to do their best work.
We know that all development teams work a little differently. Since we can’t possibly consider all development practices, we turn to our community for feedback and data on how to improve our product. From this feedback, we plan and iterate on exciting new ways to support a variety of workflows.
But what about those smaller issues you find in existing workflows? What about the usability nitpicks that bother you daily but might not be a part of our bigger product initiatives? You—the wonderful and diverse GitHub community—have been telling us about some of these smaller frustrations for a while now, and we want you to know that we’re listening. We don’t think you should be frustrated by these “paper cuts” anymore.
Project Paper Cuts is dedicated to working directly with the community to fix small to medium-sized workflow problems, iterate on UI/UX, and find other ways to make the quick improvements that matter most.
GitHub has always had feedback channels that influenced our product, though we aim to be more open and transparent with this work. We’re not only listening to email, sales, support, and Twitter. We’re also looking at the wider GitHub community’s creation of self-organized ‘feature request’ repositories and browser extensions, as well as actively asking for feedback about the small things that irritate you the most.
One big source of inspiration for us has been the Refined GitHub browser extension. Full-time open source developer Sindre Sorhus has built a great browser extension that builds on and improves the GitHub experience, along with a fantastic community that has come together to discuss workflows and build their favorite features. Project Paper Cuts has taken inspiration from a lot of Refined GitHub’s additions, and we’re building some of the most-loved features right into GitHub itself.
To give you an idea of the scope of Project Paper Cuts, over the past month, we’ve shipped:
Internally, we’re fielding feedback with a spotlight on fixes that will have the most impact with the least process, friction, discussion and dependencies, and shipping as rapidly as we can. Most paper cuts will have a public changelog entry associated with them so you can follow along.
What we’re seeing and learning from the community by working on Project Paper Cuts will forever change how we work and build features. We will continue to let our community know that we hear them and that we’re building products that help all developers do their best work, faster.
The last time we wrote about an EU copyright proposal affecting software development, we explained that policymakers in Brussels responded when you took action. We’re fast approaching another vote on that proposal in the EU Parliament.
Here’s an update on the status of the negotiations, along with some ideas of how you can help Members of European Parliament (MEPs) understand why and how to protect software development. Activism by people concerned about the copyright proposal is part of why it hasn’t passed yet, so keep reading to learn how you can help shape the debate.
The EU’s copyright proposal has the potential to impact the way we develop software. There’s still time to make our stance heard on several key issues of the proposal before it becomes law:
Upload filters (Article 13): Automated filtering of code would make software less reliable and more expensive. Upload filters pose larger concerns—like censorship, free speech, privacy, and ineffectiveness—and are problematic for all kinds of content, including software code.
Text and data mining (Article 3): The copyright exception for text and data mining in the EU is too narrow, because it only applies to research organizations for scientific purposes on a not-for-profit basis. It would undermine the EU’s efforts on AI and machine learning, as well as software development in the EU that depends on AI and machine learning.
New right (ancillary copyright) for press publishers (Article 11): Requiring a license to post snippets of text that describe links would add overhead to anyone developing software for the web. It would also run counter to copyright exceptions that allow copying for certain purposes, like commenting on a copyrighted work.
We’re focusing on software because that’s where GitHub and software developers can speak with authority.
You may have heard that Parliament “rejected the copyright proposal” on July 5. Actually, Parliament voted against one of its committee’s proposals, but it didn’t permanently reject it. Instead, they voted to open the negotiations to all 751 MEPs, rather than primarily one committee.
That said, the rejection was significant because MEPs used a rare procedure to challenge the committee’s decision, and public advocacy against the proposal contributed to that.
Parliament will vote on September 12 based on amendments received by September 5. This time, it will be the full Parliament—with more than 700 additional MEPs potentially voting than when the committee voted on the proposal. And while they’re restarting negotiations, they’re not starting over completely. They’ll vote on amendments to the Commission’s initial proposal, which is the one that kicked off the idea of upload filters in the first place.
Whatever happens in Parliament, it’s important to keep in mind that there are three institutions involved in lawmaking in the EU: Commission, Council, and Parliament. If Parliament adopts a version of the proposal, it will enter into negotiations—or trilogues—with the Commission (based on its original proposal) and Council (based on its negotiating mandate).
But for now, all eyes are on Parliament to see what it might adopt.
Leading up to Parliament’s vote, a Copyright Week of Action is happening September 4-11. Each day in that week is dedicated to a different constituency. September 5 is for developers and open source software.
Because so many developers from the EU work in the San Francisco Bay Area, we’re hosting an event at our headquarters in San Francisco on that day for EU developers to encourage them to contact their MEPs and encourage developers back home to do the same.
Many MEPs aren’t familiar with software development or how this proposal can affect it. Developers are in an excellent position to explain to MEPs how essential open source software is to software development overall and to the countless sites, apps, and programs people rely on and enjoy.
It can be a lot to take in, so here are a few things you can share with your MEP to get started:
Ready to take action? Contact your MEPs and tell them to protect software development by:
If you aren’t a citizen of the EU, there are still ways to get involved and speak out for the developer community. Public advocacy has already shaped Parliament’s response, so share your thoughts on the copyright proposal on social media, raise awareness in your community and circles, and stay tuned to what happens next.
It’s going to happen one day. One of your students tries to merge one branch into another, and the dreaded error appears:
CONFLICT (content): Merge conflict in filename.ext Automatic merge failed; fix conflicts and then commit the result.
When changes in two branches overlap, Git shouts out for a clever human (like you or one of your students) to reconcile the differences. Even if you follow all the best practices of Git—communicate with your collaborators, pull in changes regularly, and make commits that are small, logical chunks—merge conflicts can still happen.
But merge conflicts don’t have to be scary for you or your students! In this post you’ll learn how to help students resolve them.
There are many situations when a merge conflict can happen—when a student pulls in changes from a repository, after they open a pull request, or when they push changes to another repository (there are other, less common situations too, like unstashing, cherry picking, and rebasing, that won’t be covered here). Let’s look at a few examples:
git pullto bring in their teammates’ work, they find that they’ve made overlapping changes to the same file.
Each of these situations leads to a merge conflict, but the process for resolving them is similar.
When Git encounters a conflict, it pauses whatever it was doing (like pulling changes) and asks you to resolve the conflict. To help you sort out the situation, Git inserts conflict markers into your files, showing you what your changes are and what your collaborators’ changes are. Conflict markers look like this:
<<<<<<< HEAD See also: [re docs](https://docs.python.org/3/library/re.html) ======= See also [re docs](https://docs.python.org/3/library/re.html) >>>>>>> master
In this example, Students Frank and Helen have both modified README.md. Frank’s change has been merged to master while Helen’s changes are on a local topic branch. Helen discovered this when she tried to merge the changes from master into her topic branch.
Helen looks closely at the conflicting line. Both students have made roughly the same change to the file by adding a link, but Frank’s change includes a typo. Helen decides to keep her version (HEAD) and discard Frank’s (master). She does this by deleting Frank’s changes and the conflict markers, like this:
See also: [re docs](https://docs.python.org/3/library/re.html)
When she’s done resolving the conflict, she runs
git add README.md to tell Git. Satisfied with her changes, she runs
git commit to finish the merge.
Consider another example, however, where Helen and Frank have both changed the same line in different ways. Before either of their changes, the file they’re both working on contains this line:
Don’t forget to run the `linter!`
In this example, Frank has expanded the sentence while Helen has added a filename. Helen pulls in the changes and sees these conflict markers:
<<<<<<< HEAD Don’t forget to run `linter.sh!` ======= Don’t forget to run the `linter` for :100: source style! >>>>>>> master
It doesn’t make much sense to choose one side over the other, so Git offers another option: write a new line that wasn’t in either side’s commit history. Like this:
Don’t forget to run `linter.sh` for :100: source style!
If there are more conflicts, then Git will insert conflict markers for each conflicting chunk it finds. Resolving many conflicts is like resolving one, except there are more conflict markers to tidy up. Walk through them one-by-one to resolve all the conflicts in all of the affected files. When you’re finished, add the files and commit.
Sometimes you’ll see a merge conflict in the context of a pull request.
A conflict in a pull request is like one on the command line. In a pull request, you can discuss with your collaborators how you plan to resolve merge conflicts and revise your branch.
The first option: the pull request author can update their branch. Since pull requests work with branches, you can often resolve a merge conflict by adding one or more commits to the incoming branch. For example, you can merge changes locally (e.g.
git merge master) and push the branch with the newly-added merge commit to GitHub.
If it’s a complicated conflict, you can discuss the best approach right from the pull request comments. Alternatively, you can amend your pull request (for example, by rebasing the incoming branch or amending a previous commit). This can be confusing at times, especially if there’s already been discussion in the comments.
Another option is to let the person accepting the pull request resolve the conflict while merging it. You can do this within the web interface using the GitHub editor or with the command line instructions GitHub provides—either way, it’s just like resolving a conflict with Git alone by choosing the resulting lines and removing conflict markers.
Resolving merge conflicts under a deadline might not be the best time for students to learn about them. Deliberately introducing merge conflicts in the classroom can help students when it comes time to handle them on their own. Check out Dr. Mine Çetinkaya-Rundel’s talk in which she shares how she teaches students Git skills, including resolving merge conflicts.
Want to learn even more about helping students understand and resolve merge conflicts? Check out the Campus Advisors learning module #3. This video course will help you learn more about group work, pull requests, and how to get your students comfortable with resolving conflicts.
Do you have an assignment you like to use to teach merge conflicts? Let us know in the GitHub Education Community.