The GitHub Blog

When you're building software with people from around the world, sometimes it's important to validate that commits and tags are coming from an identified source. Git supports signing commits and tags with GPG, and starting today GitHub will show you when commits and tags are signed.

When you view a signed commit or tag, you will see a badge indicating if the signature could be verified using any of the contributor's GPG keys uploaded to GitHub. You can upload your GPG keys by visiting the keys settings page.

Many open source projects and companies want to be sure that a commit is from a verified source. GPG signature verification on commits and tags makes it easy to see when a commit or tag is signed by a verified key that GitHub knows about.

To learn more about how to generate a GPG key and start signing your work, read our GPG documentation articles.

There are no shortage of open source projects making an impact on our world, and we’ve been especially excited to see an increase in collaboration across the healthcare community. A few months ago we met a team at the Fred Hutchinson Cancer Research Center that is working to break down silos across cancer research by open sourcing their data and a tool called Oncoscape to visualize and interact with it. We thought the best way to introduce you to Oncoscape and the team behind it was through OctoTales, our video series about incredible companies using GitHub to work better together.

Meet Desert, Lisa, Jenny, and Eric, and discover what Oncoscape is all about.

"The project needs help at every level, from simple CSS improvements, to D3 refinements, to new interactive visualizations and extending all the way to novel challenging computational tasks, such as robust implementations of recently published computational biology algorithms", says our friend Paul Shannon, the founding architect of Oncoscape. "Cancer researchers at Fred Hutch and around the world will welcome your contribution!"

If you’re inspired to help the Oncoscape team advance their goals, you can find out more in the project repository. They have detailed contributing guidelines, issues labeled Help Wanted, and even a contributions cheat sheet.

If you would like to be a part of the OctoTales series, tell us your story at tales@github.com

Community is one of the most important aspects of open source, but sometimes a few bad actors can ruin the experience for the group. To help address the problem, organization owners now have the ability to block abusive users from public repositories. This feature allows project owners to block users, and prevents blocked users from opening or commenting on issues or pull requests, forking repositories, and adding or editing wiki pages.

All records of blocked activity are available in the organization's audit log for your reference.

To learn more about encouraging positive contributions in your organization, read our community documentation articles.

To stimulate the growth and show our support of the student hacker community, we've partnered with Major League Hacking (MLH) to provide each new member hackathon with a $1,000 grant and one sponsored ticket to Hackcon, the conference for hackathon organizers.

Hackathons are amazing social gatherings where students interested in technology can come together to learn, build, and share brand new creations over the course of a weekend.

For a small, first-time hackathon, $1,000 can make or break the event budget. For organizers, having the opportunity to meet the people behind the most successful student hackathons at Hackcon is invaluable to the continued success of their events.

As the official student hackathon league, MLH provides member events with organizational support including mentorship, hardware labs, and connections to technology companies. Last week, they announced their seed funding and B-Corp certification to reaffirm their mission-driven focus on empowering student hackers. Together, GitHub and MLH have supported a community of 50,000 students at over 150 global events in the last year.

We're proud to be part of the rapidly growing movement of hackathons organized for students by students. GitHubbers regularly participate in student hackathons as mentors, guest speakers, and judges while the GitHub Student Developer Pack gives student hackers free access to the best developer tools to use for their hacks.

To organize a hackathon at your school with support from GitHub start an MLH member hackathon in the 2016-2017 season.

Git’s flexibility allows you to shape your workflow however you like. The organization of your git history is just one of the choices to make, but up until now the merge button on GitHub only created merge commits, resulting in a style of history that didn’t necessarily match your own workflow.

Merge commits

For years, the merge button on GitHub has created merge commits (i.e. git merge --no-ff) which retain all of the commits in your branch and interleaves them with commits on the base branch. The result of a merge commit is a visually complex, but more accurate log that depicts how changes from a feature branch came to be on the base branch. Here’s what that looks like today:

Enter commit squashing

Commit squashing has the benefit of keeping your git history tidy and easier to digest than the alternative created by merge commits. While merge commits retain commits like “oops missed a spot” and “maybe fix that test? [round 2]”, squashing retains the changes but omits the individual commits from history. Many people prefer this workflow because, while those work-in-progress commits are helpful when working on a feature branch, they aren’t necessarily important to retain when looking at the history of your base branch. Here’s what squashing on merge looks like:

What’s changing?

Repository administrators now have a few options to choose from when deciding how to handle history.

Allow merge commits and commit squashing

This option will leave the decision to create a merge commit or squash up to the user doing the merging. This lets repository administrators stay flexible when deciding whether or not to retain all history from a feature branch.

Only allow merge commits

This is the default behavior and is exactly how the merge button worked before this change. Collaborators won’t have the option to squash their commits via the merge button.

Only allow squash commits

This is a new option which lets you force commit squashing on all pull requests merged via the merge button.

Check out the documentation or get in touch with any questions or feedback. Enjoy!

Two months ago, we announced that GitHub Pages is dropping support for the RDiscount, Redcarpet, and RedCloth (Textile) markup engines on May 1st. For the vast majority of users, this should be an easy transition, as kramdown supports all of RDiscount and Redcarpet's most popular features, and if you're making the transition from Textile, @jldec's post last month should walk you through the process.

With the May 1st sunset quickly approaching, we wanted to take a few moments to take a look at the numbers and the discussion behind our decision to drop support for the non-kramdown markup engines within GitHub Pages:

Web publishing has come a long way since the Jekyll project began some eight years ago. Today, Markdown is largely the lingua franca of the open source community, but that doesn't mean that certain regional dialects haven't emerged over the years, as each markdown engine adopted a slightly different interpretation of how they thought Markdown should work. As Markdown engines diverged, so too did the experience of authoring content on GitHub Pages and authoring content elsewhere on GitHub.com such as in comments and READMEs.

One of our historic design philosophies at GitHub is that "anything added dilutes everything else". While being able to fine tune the pipeline that's used to render your content may be helpful in some unique cases, for the vast majority of users, that added complexity is one more thing that you'll have to learn, one more decision that you'll have to make, and ultimately that option serves to heighten the learning curve for new users.

Today, GitHub Pages is home to just over one million distinct sites, with thousands more being added each day. On an average day, we'll process upwards of 50,000 builds, and of those 50,000 builds, more than 40,000 either don't ask for a specific Markdown engine, or ask us to use kramdown, the default. That means that when we look at markup rendering across GitHub Pages, Redcarpet accounts for just shy of 2% of all builds, RDiscount accounts for about half a percent, and Textile accounts for one-tenth of one percent.

In standardizing on a single Markdown engine, we are able to improve the publishing experience for the vast majority of GitHub Pages users. Not only are we able to remove the complexity and confusion associated with new users being forced to distinguish between multiple markup engines or reading documentation for the incorrect interpreter, we are able to bring the experience of authoring Markdown content on GitHub Pages more closely in line with the experience you've come to expect when using Markdown anywhere else on GitHub.

If you're still using RDiscount, Redcarpet, or RedCloth, next time you push to your GitHub Pages site, you will receive an email from us with instructions on how to upgrade. We highly recommend you test building your site with kramdown prior to the May 1st deadline. If you're a GitHub Enterprise user, this change will affect GitHub Enterprise versions 2.7 and later.

In most cases, upgrading to kramdown should be a matter of updating your site's configuration. If in the off chance you do run into any trouble, please get in touch with us, or if you have questions about what this change means for your GitHub Enterprise appliance, please contact GitHub Enterprise support. We're here to help.

GitHub Satellite is the first-ever international event in the GitHub Universe series, and it's happening May 11, 2016, in Amsterdam.

More than 500 developers, team leads, and open source contributors will gather at the Westergasfabriek to explore how people learn, build, and work together to define the future of software.

We'll post a full schedule in the coming days--here's a preview of what you can expect. Tickets are still available--get yours now, and we'll see you in Amsterdam!

Prototyping for the Internet of Things

How do you begin to build a product that can take any shape, communicate with a user in a number of ways, and collect constant streams of data using an array of sensors? You prototype quickly and cheaply to allow for iterative validation. Fortunately for us, rapid prototyping for IoT has never been more accessible. Many tools are open source with vibrant maker-community support, but you have to understand what’s available in the toolbox to know what you can build.

This talk will help you understand the tools available to you, while also defining a process for bringing them together into a highly usable, well-integrated, connected device. We’ll discuss:

• how to use design thinking to brainstorm and refine your ideas
• interaction options beyond touch screens
• hardware prototyping
• the software and connectivity necessary to bring your idea to life

Erica Stanley is a cofounder of the Atlanta chapter of Women Who Code, as well as a software engineer, researcher, and tinkerer.

In pursuit of open source security

Open software platforms are helping the security industry achieve important goals by enabling better communication, information sharing, and code quality. But open source security differs from other open source communities in a number of ways, as we learned with osquery. The vision for open source security is for offensive and defensive security professionals to work together on important security challenges, benefit from shared knowledge, and drive the industry forward. During this talk, engineers from the Facebook security team will discuss what they've learned building and supporting the most popular security project on GitHub and how that lead to the development of a new open source project for the GitHub community that will be debuted during this talk.

Marjori Pomarole is a Software Engineer on the Security Infrastructure team at Facebook London. She currently leads development for Invariant Dectector, a security tool for finding and blocking anomalies in write requests on Facebook.

Javier Marcos is a security engineer at Facebook with experience working on both offensive and defensive teams. He is currently a member of Facebook's Detection Infrastructure team and manages the Facebook CTF platform.

Using pull requests to drive continuous delivery

Developers all know this story. There is a piece of software that runs in the cloud. All the code lives on GitHub, and is tested with Travis CI. You have a production app, usually have a staging app, and maybe, sometimes, a development app. And then you've got your local development environment.

Delivering the code to these environments tends to involve a series of manual steps, tweaking, fairy dust, and hoping for the best. We all dream for Continuous Delivery, where we've automated a good chunk of this work, and at the push of a button, this just, well, happens.

For the past year, Heroku has been working on addressing this problem, deeming it the "Heroku Flow:" a structured workflow for Continuous Delivery. This allows you to automatically deploy to staging when CI passes and manually promote to production when ready. Create and tear down ephemeral development environments for all of your pull requests.

Gudmunder Bjarni is a developer experience engineer at Heroku.

Git Merge kicks off in less than a week in New York City on April 5th—and tickets are already sold out! The conference will bring together Git contributors, source control teams, and end-users from around the world for a full day of sessions, trainings, and networking. Here’s a peek into some of the talks and workshops you won’t want to miss:

Tips and tricks

Ready to brush up on your Git skills? Check out these sessions:

• Emma Jane Hogbin Westby will teach us about making the Git on-boarding experience easier for others.
• Charles Bailey from Bloomberg will uncover techniques and tools for letting all team members—especially those less familiar with advanced uses of Git—easily migrate their work in progress to the new history.
• Tim Pettersen from Atlassian will cover the computer science behind Git LFS' internals and architecture, as well as CLI usage and how to build an effective Git LFS workflow for a development team.
• Ryan Hodson from Cloudflare will discuss streamlining the static website development workflow.
• Spencer Krum from IBM will share his favorite command line tricks to make the Git experiences more straightforward.
• Syste Sijbrandij from GitLab will walk us through the essential steps of making the collaborative DVCS workflow a reality at any company.
• Emily Xie from Wayfare will dissect Git’s plumbing commands to uncover what’s going on behind the scenes.

A look inside

Discover how some of the most interesting companies in the world are using Git:

• Greg Kroah-Hartman from The Linux Foundation will kick off the day with a discussion around how Linux is developed, how fast it is happening, and how we all try to stay sane keeping up with it (hint: Git is the reason).
• Patrick Reynolds from GitHub will explore the challenges GitHub encounters when working at the scale of billions of operations per day.
• Lars Schneider from Autodesk will recount their journey to on-board 4000+ engineers with 200+ different code bases.
• John Haley and Hamid Shojaee from Axosoft will describe the creative (and oftentimes argumentative) process of GUI development.
• Saeed Noursalehi from Microsoft will share the journey—both social and technical—of moving the majority of Microsoft’s product development onto Git.
• Juan Pablo Buritica from ride.com will teach us to stay relevant by looking at the surprising parallels between modern kitchens and effective engineering teams.

Expert trainings

You’re invited to join some of the best Git trainers in the world for deep-dives into a variety of topics:

• Scripting Git
• Get out of (almost) anything with Git
• Making the switch to Git LFS
• Mastering git-imerge

After party

At the end of the day, join us at SpinNYC for our afterparty, sponsored by GitLab. With 17 ping-pong courts, a special appearance by two world champion players, and a light selection of late-night snacks, you won’t want to miss this celebration.

Live streaming

Want to join us but can’t make it? We’ll be live streaming the main sessions throughout the day on our website, git-merge.com

Special thanks

Git Merge would not be possible without the support of our sponsors. Special thanks to GitLab, Atlassian, Bloomberg, Compose and SAP for joining us as partners for this event.

Git Merge will be held on April 5 at New World Stages (340 West 50th Street, New York City, NY 10019). For more information, visit git-merge.com.

Over 100,000 people push to protected branches nearly 300,000 times every week. We’ve been listening to how we can make protected branches even better and we’re happy to introduce two workflow improvements.

Merging out-of-date pull requests

Required status checks currently provide a strong guarantee of compatibility between a pull request’s base and head branches. Not only must the status checks be passing, the head branch must also be up to date with the protected base branch in order to be merged. This catches hard-to-spot incompatible changes that don’t cause merge conflicts but result in broken code nonetheless.

The extra status check runs required by this policy can be a burden for teams where many changes are being made to a protected branch. To make this easier for those teams, we’ve added a setting which will still enforce required status checks but will no longer require a pull request to be up to date before merging.

User and team restrictions

Sometimes merges to a protected branch are best left to a release manager or a team of people responsible for the stability of that particular branch. Organizations can now specify which members and teams are able to push to a protected branch. Note that organization and repository administrators are always able to push.

Protected branches help you keep your codebase safe from force pushes and buggy code. These changes give you better control over whom can push to your protected branches and make the experience for very active repositories much smoother. Check out the documentation for more information or get in touch with any questions or feedback.

We know from community feedback and open source projects (like @notwaldorf’s Chrome extension) that replying with the same response to Issues and Pull requests over and over can be tedious. Saved replies allow you to create a response to Issues and Pull requests and reuse it multiple times, saving you a ton of time typing and posting the replies you use most frequently. It’s available on all repositories starting today.

Using Saved replies

To get started, go to your personal settings and click “Saved replies”. Here, you can add custom replies based on the types of responses you use most frequently. You can edit and update these anytime.

You can access your Saved replies when composing or replying to an Issue or Pull request.

Check out the documentation for additional information on the feature.

To highlight the people behind projects we admire, we bring you the GitHub Developer Profile blog series.

If you know Sean Marcia, chances are that it’s through Ruby for Good, an annual event that brings Ruby developers together to work on projects that benefit their communities. But when he’s not empowering developers to use their skills for collective good, he’s partnering with academics at George Mason University to advance their research through software and the web. Oh, and saving the world’s pollinators, of course. We asked Sean to share the story of how he became a developer, and what he’s learned from his work.

Erin: How long have you been developing software?
Sean: Let’s see... It’s been my legit full-time career for about five years now. Like many nerdy types, I’ve been poking and prodding at computers since I was a wee one. Getting paid to do it is a relatively new and delightful thing!

Erin: What programming languages do you use?
Sean: I primarily use Ruby on Rails and Javascript for the projects I work on at George Mason University. I also sneak in Go whenever I am able.

Erin: Who did you look up to in your early days?
Sean: In my early days, full-stop, I definitely looked up to (and continue to look up to) Jim Henson and Mr. Rogers. These guys genuinely cared about people and their happiness. My favourite Jim Henson quote nicely sums up why I admire him so much and what I strive for everyday:

My hope still is to leave the world a bit better than when I got here.

In my early days of career software development, who did I look up to? Hmm, it’s tough to narrow it down to a short few. I definitely have to mention _Why, James Edward Gray II, Greg Brown, Jim Gay, and Evan Light. These folks were helpful (understatement), encouraging, smart, generous with their time and expertise, and just all-around great people; I hope I can offer back even half of what they’ve given me. Ruby fosters a culture of inclusion, kindness, and learning. It’s a community comprised of some of the best people I’ve ever met. As a newbie, I was privileged to be exposed to this great bunch, and now as a Ruby Meetup organizer I count myself lucky to see newcomers’ passion about development and their world.

Erin: Tell us about your journey into the world of software development.
Sean: Okay, brace yourself, best sit down for this one: I've always been a bit of a computer nerd with an affinity towards technology. No big shocker that this interest manifested itself in computer games. The first substantive programming I did was using a language called LPC for a multi-user-dungeon (MUD). That’s right, I wear my nerd badge proudly! For those who have no idea what I’m talking about, MUDs were the precursor to MMORPGs. Everything was text based, there were no snazzy graphics, and they only had a few hundred people playing at once (none of this thousands upon thousands business). It was great fun, as I was friends with a lot of the people who used the things I built and was able to directly observe their happiness and pains when they were interacting. Quite the dichotomy from today when some of the things I build disappear into the ether after delivery and I never see how it is used or what happens next.

Erin: What resources did you have available when you first got into software development?
Sean: Not a lot! I remember begging my parents to buy me Borland's C++ compiler but it was outside their budget so I was only able to read the code in the book but not compile and execute it myself.

Erin: What advice you would give someone just getting into software development?
Sean: I would tell them to get involved in the community! I have learned and benefitted so much from having access to people at meetups, conferences, and other events. I wouldn't be where I am today without the help. I would also let everyone know that you don’t need a computer science degree to get into software development. We live in an amazing world where information is so widely available that you can learn anything you want with a few clicks. It is fantastic that schools like MIT, Stanford, and others have open sourced so many courses. If you have access to an Internet connection you can access courses taught by some of the smartest people in the world. This isn’t to say that software development isn’t hard! Don’t get discouraged. Don’t give up.

Erin: What additional advice would you give someone looking to get into open source?
Sean: I would tell them to not be afraid! Everyone I've met who works on or maintains an open source project is super nice and generally pretty overworked. They are friendly, welcoming to new people, and love the help! An easy way to get started with an open source project is to help with documentation. I think most people would be surprised with how much help even well-established projects need in that area. If you are new to development and are using and learning an open-source project, document your learning, and submit it to the project’s GitHub wiki as a newbie's guide to help others.

Erin: I was inspired (and entertained!) by your talk on saving the bees with Ruby and was amazed at how much you did with so little. What advice would you give to someone with a big, impactful idea, but a small budget?
Sean: Not to sound like a broken record, but get involved with your community! I couldn't have done everything I did without the help of my community. For the project you mentioned, several people donated a Raspberry Pi that would have otherwise been collecting dust on a shelf. Plus, a friend did all the soldering for me and was nice enough to allow me to record him so others could replicate it. And, the wealth of knowledge and feedback that so many people provided made it a success. A lot of people are happy and want to help, you just need to ask!

Erin: Are there any misconceptions out there about software developers that you think need to be retired?
Sean: I think the biggest misconception is that you need a computer science degree to be a software developer. This is an archaic notion as there are so many paths into the software development field, from boot camps to those who are self-taught. One of the best developers I know, who has published several popular books on software development, has a fine arts degree in ceramics. I firmly believe that excellent mentorship, bootcamps, and community events are producing better software developers than universities.

Erin: What role did MINASWAN play in inspiring you to start Ruby for Good? Can you share with us an example or two of how you’ve personally experienced MINASWAN (or perhaps seen others experience it)?
Sean: MINASWAN played a huge part. Outside of the technology industry many people are struggling and I believe that because we have it so good in tech it is easy to lose sight of that. The genesis of Ruby for Good was to provide a way to help and make a difference for the people who need it most. There are everyday MINASWAN heroes in this community and one person I'd particularly like to shine some light on is Zander Hill and the amazing work he does mentoring. Getting into software development can be intimidating and overwhelming, but I've seen Zander take the most difficult concepts and make sense of them for his mentees.

Erin: Okay, we’ve talked a little bit about Ruby for Good, a conference that gets Ruby developers together to hack on projects that make an impact on the world outside of tech. What are some of your favorite projects that have been helped by the conference attendees?
Sean: I think my favorite project was a ticket-tracking app we built. Before we helped them through Ruby for Good, the nonprofit was using a telephone line and its voicemail as their project management tool. The telephone line would ring continuously throughout the day. People would check messages with the rule that you could only delete a message once the task was completed. This required people to forward through as many as 80 messages before getting to the one they needed and they estimated that each employee who used it wasted at least five to six hours a week on the phone. The new system has made their lives much better and given them more time to devote to the great work they are doing. I'm also pretty excited about the help we provided the Fairfax Humane Society because it doesn't get much better than helping puppies and kittens! This year, Ruby for Good is going to be held June 16-19 where we will be helping some truly amazing organizations, including researchers who are working with red pandas. I'd encourage anyone who wants to do good and hang out with red pandas to attend!

Erin: Where would you point someone who wants to get involved, but can’t attend the conference?
Sean: If someone wants to specifically get involved with Ruby for Good, check out the projects with open issues on our GitHub organization page and submit a pull request! I would also encourage people to look closer to home. Stop by a local non-profit that appeals to them and offer to help. One ubiquitous issue among non-profits that we've spoken to is how starved they are for help with technology. Nonprofits desperately need the help that we can offer, but for most part it is completely outside of their budget. Through our volunteer work, they can get new ways of doing things that they might have done the same way for the past 20 or 30 years.

Erin: Anything else you’d like to share?
Sean: I've had a great deal of fun whenever I've been able to use Go and would love to do something more substantial with it. I'd love it if anyone could make some suggestions :).

The open source Git project has just released Git 2.8.0, featuring a variety of features, bugfixes, and other improvements from over 70 contributors. Here are some of the most useful new features:

Parallel fetches of submodules

Using "git submodules", one Git repository can include other Git repositories as subdirectories¹. This can be a useful way to include libraries or other external dependencies into your main project. The top-level repository specifies which submodules it wants to include, and which version of each submodule.

When you fetch into the top-level repository, you typically want to fetch into the submodule repositories as well:

git fetch --recurse-submodules

If you have a lot of submodules, all of these fetches can be time-consuming; git fetch is essentially run in each submodule in turn. But now you can speed things up by fetching from multiple submodules in parallel. For example,

git fetch --recurse-submodules --jobs=4

runs four submodule fetches at the same time. This should be a real time saver! [source]

Don't guess my identity!

If you use the same name and email address to commit to all of your Git projects, then you can configure those values once and for all in your global .gitconfig file:

git config --global user.name 'Me Myself'
git config --global user.email me@example.com

But if, say, you want Git to use one email address for your open source projects and a different one for your work projects, you've undoubtedly made the mistake of committing to a new Git repository without having first set your email address in that repository. In this situation, Git emits a warning, but it creates the commit anyway, using an email address that it guesses from the local system hostname. If you're trying to do something as complicated as different addresses for different projects, this is almost certainly not what you want.

Now you can tell Git not to guess, but rather to insist that you set user.name and user.email explicitly before it will let you commit:

git config --global user.useconfigonly true

[source]

Convergence with Git for Windows

There has recently been a big push to make Git feel as comfortable on Windows as it does on Linux and OS X. For example, it is relatively expensive to start processes on Windows, so many Git commands that were originally written as scripts have been rewritten in C to make them snappier.

In this release, a bunch of Windows-specific changes have been brought back from the Git for Windows project into the main Git project. This continuing effort will make it easier to keep the functionality of Git in sync across platforms as new features are added. [source, source, source, source]

Along the same lines, several Git commands that use text files as input have been made to accept both LF and CRLF line endings. That should reduce friction on Windows, where many tools may produce files with CRLF line endings. [source]

Security fixes

Git 2.8.0 includes the security fixes for CVE-2016-2324 that were first made available in Git 2.7.4. This vulnerability is not known to have any exploits in the wild, but could result in executing arbitrary code when cloning a malicious repository. We recommend that everybody upgrade to a version of Git with these fixes, namely 2.4.11+, 2.5.5+, 2.6.6+, 2.7.4+, or of course 2.8.0+.

In addition to these fixes, this release contains a number of cleanups designed to make it easier to avoid similar bugs in the future.

[source]

Brief mentions

• Git's clean and smudge filters can now be turned off by setting them to the empty string. This feature is notable mainly because it is used by the new git lfs clone command, which can dramatically reduce the time to clone a repository that uses Git LFS. [source]

• Git configuration values are read from several different places, including system-level, user-level, and repository-specific files. This can make it hard to figure out where a setting has to be changed. Now you can use git config --show-origin to show where a particular setting came from:

  $ git config --show-origin user.name
  file:/home/me/.gitconfig    Me Myself

  [source]

• You can use the new git ls-files --eol FILENAME to help diagnose end-of-line problems in a file:

  $ git ls-files --eol README.md screenshot.png
  i/lf    w/lf    attr/                   README.md
  i/-text w/-text attr/                   screenshot.png

  The output shows (i) the EOL style auto-detected from the file's contents in the index, (w) the EOL style detected from file's contents in the working copy, and (attr) the style that is configured for the file via gitattributes. [source]

• git ls-remote can now also tell you a remote repository's default branch:

  $ git ls-remote --symref origin HEAD
  ref: refs/heads/master  HEAD
  db6696f653b917509dac1ac13b922e12773a84ff        HEAD

  [source]

• Support for cloning via the rsync protocol, which was superseded long ago by better alternatives, has been dropped. [source]

The rest of the iceberg

That's just a sampling of the changes in Git 2.8.0. Check out the the full release notes for the complete list.

[1] Git submodules are analogous to Subversion's svn:externals.

We have reached an exciting milestone: one million people have launched some version of Atom in the last month. That's three times the number of active users we had under a year ago at the one-year anniversary of Atom becoming completely open-source.

Atom has been successful because of the community that has grown around it. The people that have contributed to Atom—that have given their time, expertise, feedback, suggestions, and insight—have helped Atom improve by leaps and bounds. We also hear of exciting or just plain cool things that people are doing with Atom all of the time—like MuleSoft's API Workbench, Jibo Robot's SDK tools, and Facebook's Nuclide.

It's not just companies that are coming up with interesting ways to use Atom. Some packages written by individuals that have caught our attention recently are:

• Atomic Chrome - Syncs what you type in Atom to text inputs on web pages in Chrome so you never have to worry about losing what you wrote
• Git Time Machine - Shows an interactive plot of the current file's Git commit history
• Activate Power Mode - A fun package that infuses your typing with power

All of us on the Atom team appreciate the work that the community has put in to our collaborative project. We're looking forward to what Atom will look like when we reach the next million users and hope that you are, too!

At the heart of what makes GitHub great are the thousands of open source communities that build incredible things every day. The brand new GitHub Community Cast shines a light on these awesome projects and the people that make them.

Take a look inside a project, learn about their tools and workflow, discover where you can get involved, and get inspired for your own work. In addition to seeing behind the curtain on a great open source project, you'll also get news and updates from around the GitHub community.

The inaugural episode features an interview with Andy Miller from the Grav project, a modern flat-file CMS with some bold ideas. We also share some of the new features recently landed in GitHub and events going on around the GitHub community.

You can each episode from our SoundCloud page or subscribe to the podcast feed.

At Git Merge—a conference for the Git community—you'll join developers who are committed to the future of Git. In addition to seeing an amazing lineup of speakers, attendees of all levels are invited to participate in a series of workshops led by the best Git trainers in the world. You won’t want to miss this unique opportunity to brush up on your skills while learning from the experts.

Workshops are 60-90 minutes and will take place concurrently with the general sessions. Take a moment to RSVP here to reserve a seat. Please note that you must also be registered for the main conference in order to attend any workshops.

Get out of (almost) anything with Git
One of the big advantages of version control is knowing you have a safety net in case anything goes awry. In this workshop, we'll explore common predicaments and discuss how to use the best tool for the job to get out of different tight spots. While the material we'll cover can help the beginner and the seasoned professional alike, attendees should have a basic working knowledge of Git and be comfortable on the command line.

Making the switch to Git LFS
If you're starting a new project, using Git LFS is easy. Converting an existing project, however, can present a few challenges. In this workshop, we'll adapt a sample project to use with Git LFS, Git's filter-branch command, and the BFG Repo-Cleaner. We'll also talk about the implications these approaches have on your project and your collaborators. Attendees should have a general understanding of Git internals and be comfortable working on the command line.

Mastering git-imerge
Git-imerge reduces the pain of merge conflicts to its unavoidable minimum, by finding and presenting the smallest possible conflicts: those between the changes introduced by one commit from each branch. It also lets you interrupt, save, and publish in-progress merges—so you can test partially-merged code, or even collaboratively fix conflicts. In addition, it offers a straightforward method for preserving history while rebasing. This workshop will teach you how to use git-imerge to do all of this. It is intended for reasonably experienced users though it requires no expertise in Git.

Scripting Git
This workshop will cover several ways to write Git scripts. We will start by using the command-line client and Git's plumbing commands in shell scripts. Then we'll demonstrate how to write Git scripts in scripting languages, by using libgit2 and the various bindings to it (the workshop examples will focus on Ruby and Rugged). Attendees should understand the basics of Git internals.

Check out the full conference schedule here. Git Merge is happening on April 5, 2016 in New York City. We hope to see you there!