Subscribe

A whole new GitHub Universe

Learn about the exciting features and announcements revealed at this year's GitHub Universe conference. Learn more

GitHub Flow in the Browser

Now that you can delete files directly on GitHub we’ve reached a very exciting milestone—the entire GitHub Flow™ is now possible using nothing but a web browser.

What is GitHub Flow?

A little while ago our very own @schacon wrote an article outlining the workflow we use here at GitHub to collaborate using Git. It’s a deceptively simple workflow, but it works brilliantly for us across a huge range of projects, and has adapted extremely well as our team has grown from being only a handful of people to our current size of 183 GitHubbers.

Since we use this workflow every day ourselves, we wanted to bring as many parts of the workflow to our web-based interface as possible. Here’s a quick outline of the how the GitHub Flow works using just a browser:

  1. Create a branch right from the repository.
  2. Create, edit, and delete files, rename them, or move them around.
  3. Send a pull request from your branch with your changes to kick off a discussion.
  4. Continue making changes on your branch as needed, updating the pull request automatically.
  5. Once the branch is ready to go, the pull request can be merged using the big green button.
  6. Branches can then be tidied up using the delete buttons in the pull request, or on the branches page.
  7. Repeat.

Even before some of these steps were possible in the browser, this simple workflow made it possible for us to iterate extremely quickly, deploy dozens of times each day, and address critical issues with minimal delay. Probably the most compelling aspect of GitHub Flow however is that there is no complicated branching model to have to wrap your head around.

Now that this workflow is available entirely via the web interface though, a whole new set of benefits start to emerge. Let’s dive into a few of them.

Lowering barriers to collaboration

Perhaps the most interesting consequence of having these tools available in the browser is that people don’t have to interact with Git or the command-line at all—let alone understand them—in order to contribute to projects in meaningful ways. This makes for a much easier learning curve for anyone new to Git and GitHub, whether they’re non-technical team members, or experienced developers learning something new.

Lowering barriers to learning

These web-based workflows have been especially helpful for our training team too. For some classes they’ve been able to have people begin learning the basic concepts of Git and GitHub using just the browser, saving students the complexity of installing Git and learning their way around the terminal commands until after they’ve got their heads around the fundamental ideas. When a browser is all you need, hallway demos and super-short classes can also more effectively convey the GitHub Flow to people in less time, and without the distractions of preparing computers with all the necessary software.

Less disruptive workflows

Even if you are a command-line wizard, there are always times when you just need to make a quick tweak to a project. Even if it’s just a single typetypo, doing this in the terminal requires a crazy number of steps. So now, instead of:

  • Switching contexts from your browser into your terminal.
  • Pulling down the code to work on.
  • Making the change.
  • Staging the change.
  • Committing the change.
  • Pushing the change.

…you can simply make the change right there without leaving your browser, saving you time and maintaining your zen-like frame of mind. What’s more, if you have any kind of continuous integration server set up to integrate with our Status API, you’ll even see that your typo fix built successfully and is ready to go!

Writing documentation

When editing Markdown files in repositories, being able to quickly preview how your change will look before you commit is very powerful. Combining that with things like the ability to easily create relative links between Markdown documents, and the availability of fullscreen zen mode for enhanced focus when composing content which isn’t code, the end result is a set of tools which make creating and maintaining documentation a real pleasure indeed.

Working with GitHub Pages websites

For projects that make use of GitHub Pages for their websites, tasks like writing new blog posts, or adding pages to an existing site are incredibly simple now that these workflows are possible in the browser. Whether you use Jekyll or just regular static HTML for your GitHub Pages site, these new workflows mean that you’re able to make changes using GitHub in your browser, have your site rebuilt and deployed automatically, and see your changes reflected live on <username>.github.io or your custom domain before you know it.

To learn more about building websites using GitHub Pages, you should check out these articles.

Get your GitHub Flow on!

In using them ourselves, we’ve found that these web-based workflows have come in handy on an increasingly regular basis, and we’re noticing real benefits from the reduced barrier to contributing. We hope you find these workflows useful too, and we can’t wait to see the interesting ways we know you’ll put them to good use.

Explore Everyone's Stars

image

You've been able to sort, search, and filter your stars for a few months now, and today you can easily browse everyone else's stars, too. Most of the view is very similar to your stars browser, except we've made a few refinements. https://github.com/stars/jonrohan

Q: Why not use /jonrohan/stars?
A: Who are we to tell you that you can't have a repository named "stars"?

Quick Links

image

You can now browse around developers you're following. We found this very fun and interesting. Make sure you follow some good developers.

Scannable Starred/Unstarred

image

As you scan a list of your friends' stars, you might notice some stars you have seen before. These are easily scannable because of the darker Unstar button.

Have fun exploring.

Deleting files on GitHub

You know all those files you’ve been creating, editing, moving, and renaming? Well, you’ll be glad to know that you can now remove them using the web-based interface too! Simply view any file in your repository, click the delete button at the top, and commit the removal just like any other web-based edit.

Delete a file using GitHub

Commit removal of a file using GitHub

And just like that, 😗💨, it’s gone.

For help with these features, be sure to read our help articles on creating, moving, renaming, and deleting files.


Note: Since it’s a version control system, Git always has your back if you need to recover the file later. If you really, really need to completely delete a file from a repository for some reason, say a secret key or other sensitive file that was accidentally commited, you may need to consider 💀🔥the nuclear option🔥💀.

New History Tab in GitHub for Mac

Today, we're happy to announce an all-new look for the History tab in GitHub for Mac:

The new history tab

This new design has a far more efficient way of viewing your repository's history than its predecessor. Not only that, but it's fast. Really fast.

Specifically, we used libgit2 to massively improve the performance of diffs, and ReactiveCocoa to achieve a tab which loads faster and is more responsive than ever before.

This is just the first step in our new vision for GitHub for Mac. We can't wait to bring this level of awesomeness to the rest of the app.

Release Your Software

Today, we're excited to announce Releases, a workflow for shipping software to end users. Releases are first-class objects with changelogs and binary assets that present a full project history beyond Git artifacts. They're accessible from a repository's homepage:

header

Releases are accompanied by release notes and links to download the software or source code.

releases

Following the conventions of many Git projects, releases are tied to Git tags. You can use an existing tag, or let releases create the tag when it's published.

tags

We recommend projects use Semantic Versioning, but it is not required.

Creating Releases

As a repository collaborator, you can draft up a changelog in a release's notes. Any non-production releases (alphas, betas, release candidates) can be identified through the pre-release checkbox.

draft

You can also attach binary assets (such as compiled executables, minified scripts, documentation) to a release. Once published, the release details and assets are available to anyone that can view the repository.

upload

Happy shipping! 🚢

GeoJSON rendering improvements

Nearly two weeks ago, we announced support for rendering geographic data. Today, we're excited to roll out several improvements:

  • GitHub now supports rendering TopoJSON, an extension of GeoJSON that encodes topology and can be up to 80% smaller than its GeoJSON equivalent.

  • Starting today, you don't have to rename geo files with a new extension. GitHub will now render GeoJSON (and TopoJSON) in all .geojson, .topojson, and .json files.

  • Complex geographic datasets can often be difficult to visualize, especially if points are grouped close together. We now automatically cluster nearby markers, allowing us to better support larger datasets.

Embed Support

Want to make your geoJSON map available someplace other than GitHub? Simply modify this template, and place it in any HTML page that supports javascript, such as GitHub Pages, and you'll have a beautiful, portable map:

<script src="https://embed.github.com/view/geojson/<username>/<repo>/<ref>/<path_to_file>"></script>

For more information, including how to customize the embed code, see the help article Mapping geoJSON files on GitHub. Of course, you can always embed STL files as well.

Task Lists in Gist

Task Lists are a great way to organize and break down Issues and Pull Requests into small, feasible tasks. Naturally, we want to use Task Lists to track our personal endeavors, too.

Today we're happy to make Task Lists available in Gist.

Task Lists in your Gist

Task Lists work in any Markdown file in your Gist and in any comment. Read the docs for Task Lists in GitHub-flavored-Markdown for more information.

Simpler Milestone Workflow

We just made working with milestones simpler and more explicit. Now when you want to close or open a milestone, you can do so from the milestone listing. Milestones will no longer change state based on any sort of issue assignment.

milestones - github_mail-replies-2

New File Size Limits

Starting today, you will see warnings if you push large files to your GitHub repository. Git is not well suited to large binary files, and we have some recommendations about better ways to handle them.

We will also reject pushes which add or modify files that are larger than our generous hard limit.

Please see the Help article for more details, including Git's technical limitations, and the specific limits.

Repository Next

Today we’re proud to announce a redesigned repository experience focused on your content, built for everyday use.

overall

We’ll be slowly rolling out the ability to opt-in to this new design over the next few days. It’s a big change and we don’t want to interrupt you mid-day. Within a couple of weeks this will be the new face of GitHub for everyone.

banner-tease

Optimized for everyday use

GitHub is a product you use every day. We’ve focused on this and optimized for how people interact with GitHub on a daily basis. The next time you click through on a notification email, you’ll find a dramatic reduction of persistent section navigation cluttering up the page.

issues

Gone is the large, prominent section of the page dedicated to navigational debris — replaced with a slim, de-emphasized icon-based navigation.

Focus on the context you’re working on and jump to the repository root to switch sections.

The content is the interface

We want the interface to melt away and your content to take center stage. We’ve optimized the design for scanning and reading of your code — your issues — your pull requests. Let your code speak for itself — without tab bars and navigational text competing for attention.

code

Inside of sections, we’ve replaced many persistent navigation tabs with overviews and content links.

stats

stats-expanded

The new repository overview acts as a thumbnail for code — a visual fingerprint for each repository. Click the language bars to see the language breakdown.

If you work across many different repositories, the language bars are a nice way to tell the difference between repository pages, which have a tendency to look exactly the same project to project.

Speed

Responsiveness is one of the most important design aspects of software — so it comes as no surprise that this redesign puts a tremendous focus on speed and responsiveness. We've doubled down on pjax and upped our caching game to do everything in our power to reduce page load times.

For many projects on a typical connection, we’ve reduced total navigation time from around 1 second down to 300 milliseconds. We’ve made browsing files within a repository so fast that we no longer need the animations: in most cases, files are rendered nearly instantaneously.

A long time in the making

We've been working toward this redesign for almost a year now, and we think it's a massive step forward in using GitHub.

It's a big change, and may take a few days to feel right. As always, this is just the beginning. This redesign paves the way for an even faster, more focused GitHub. And we can't wait to see what the future holds.

There's a map for that

Not long ago, we began rendering 3D models on GitHub. Today we're excited to announce the latest addition to the visualization family - geographic data. Any .geojson file in a GitHub repository will now be automatically rendered as an interactive, browsable map, annotated with your geodata.

screen shot 2013-06-13 at 10 23 32 am

People are already using GitHub to store everything from Chicago zipcodes to community radio stations to historic hurricane paths, and we can't wait to see what the community will begin to collaborate on next.

Under the hood we use Leaflet.js to render the geoJSON data, and overlay it on a custom version of MapBox's street view baselayer — simplified so that your data can really shine. Best of all, the base map uses OpenStreetMap data, so if you find an area to improve, edit away.

Maps on GitHub support rendering GIS data as points, lines, and polygons. You can even customize the way your data is displayed, such as coloring and sizing individual markers, specifying a more descriptive icon, or providing additional human-readable information to help identify the feature on click.

Looking to get started? Simply commit a .geojson file to a new or existing repository, or dive into the docs to learn how to customize the map's styling.

Git Merge Berlin 2013

Last month GitHub was proud to host the first Git Merge conference, a place for Git core developers and Git users to meet, talk about Git and share what they've been working on or interested in. The first Git Merge was held in Berlin at the amazing Radisson Blu Berlin on May 9-11, 2013.

git-merge

The Git Merge conference came out of the GitTogether meetings that several Git developers held for several years at Google's campus directly after their Google Summer of Code Mentors Summit. We felt that we should hold a similar conference of the Git minds in the EU to accomplish the same things - get Git developers together to meet in person, talk about interesting things they're working on and meet some users.

dev-dinner

This conference was run a little differently than most. It was split up into three days - a Developer Day, a User Day and a Hack Day.

The first day was the developer day, limited to individuals who have made contributions to core Git or one of its implementations such as libgit2 or JGit. About 30 developers came and had discussions ranging from an incremental merge tool, to our participation and success in the Google Summer of Code program, to fixing race conditions in the Git server code.

dev-talking

The second day was the User Day, meant to allow everyone to share tools they were working on or issues they have with Git. The first half of the day was set up entirely in lightning talk format and over 40 talks were given, ranging in duration from a few seconds to nearly 20 minutes. After the lightning talks were done and everyone who wanted to had spoken, we broke up into small group discussions about more specific topics - Laws on GitHub, Git migration issues, tools and tips for teaching Git and more.

The final day was the Hack Day which gave attendees a chance to sit down with people they had met the previous day or two and start working on something interesting.

Notes for the entire conference, collaborated on by attendees, can be found here.

Recorded talks from each day can be found here. Some really interesting examples are Roberto Tyley's bfg-repo-cleaner talk, a tool to clean up bad history in git repositories, and this talk which covers the German federal law repository on GitHub.

Thanks to everyone who attended!

Introducing Octokit

We're happy to announce Octokit, our new lineup of GitHub-maintained client libraries for the GitHub API.

octokits

Today, we're making our first two libraries available.

octokit/octokit.rb

Octokit.rb (formerly pengwynn/octokit) has been developed by the Ruby community over several years and provides access to the GitHub API in idiomatic Ruby.

octokit/octokit.objc

OctoKit has been extracted from GitHub for Mac by the Mac team and is a Cocoa and Cocoa Touch framework for interacting with the GitHub API, built using AFNetworking, Mantle, and ReactiveCocoa.

Introducing GitHub Sudo Mode

In the ongoing effort to keep our users safe, we recently took inspiration from the Unix sudo command. We wanted to require password confirmation for dangerous actions on GitHub.com, but we didn't want to force you to be constantly entering your password.

Meet GitHub's "sudo mode"

sudo mode screenshot

Dangerous actions (e.g. adding email addresses or public keys) will now require password confirmation. If you're deep in the zone and you're doing a lot of these dangerous actions, we'll only ask you to re-authenticate every few hours.

With this balance of security and convenience, we help you keep your account safe, without getting in your way. Feedback is always welcome. Enjoy!

Installing Git from GitHub for Mac

In today's release of GitHub for Mac, you can now easily install Git for use on the command line, without needing to download any separate packages. And whenever we update the version of Git included with GitHub for Mac, you'll get the changes automatically – no work required on your part!

After updating the app, you may notice some changes to the Preferences window. On the newly renamed "Advanced" tab, simply click "Install Command Line Tools":

Advanced preferences pane

You'll be prompted for an administrator password so that Git can be installed into /usr/local/bin, and then you should very shortly see that it succeeded:

Installation Complete

If you're using GitHub for Mac for the first time, and want to install Git, you can also set it up from the welcome screen:

Configure Git welcome screen

Once installed, you can open up Terminal.app and run git commands to your heart's content. Command line aficionados, rejoice!

Update: We've since removed the ability to install Git from GitHub for Mac, because OS X Mavericks and later includes a version of Git already.