The GitHub File Finder is now available on your mobile device. Just click the "Jump to file" link on any repository.

GitHub is pleased to announce that version 1.0 of the Atom text editor is now available from atom.io. Read the full behind the scenes story over on the Atom blog.

The entire Atom team is attending CodeConf this week and will be presenting a session all about Atom 1.0 featuring Chris Wanstrath, Ben Ogle, and Daniel Hengeveld. Watch along tomorrow, June 26th, at 11AM EDT: https://live-stream.github.com

Graphs, and pencils, and locks...Oh my! Now you can collect themed Octicon buttons with the four new button packs offered in the GitHub Shop.

We're hosting Hackcon III at our San Francisco office on July 18th and 19th.

Hackcon is the place to be for student hackathon organizers. The event is run by our friends at Major League Hacking and will bring together 150 student leaders for two days of talks and workshops. Participants will share experience and best practices in everything from starting a campus group to producing large scale campus events.

If you lead a student hacker community at your university, we'd love to see you at Hackcon. You can find more information about the event and pre-register at hackcon.io. You can also check out the videos from Hackcon I and Hackcon II on YouTube.

CodeConf is next week, and I couldn't be more excited to bring the open source community together to exchange ideas and have some fun in Nashville. There are a few updates I'd like to share:

• On June 24, the day before the conference, we'll be hosting a meet & greet for attendees who would like to register early. This event is free and open to the public, so if you aren't attending CodeConf but live in the Nashville area and would like to stop by, grab a ticket here. We'll be congregating on the second floor of Acme Feed & Seed downtown beginning at 5:30pm

• The workshop schedule has been updated, and I have opened up more space in each session for those interested. If you'd like to snag one of the newly available tickets, go for it!

There's still time to grab a CodeConf ticket. Take a look at the website for the full schedule of sessions, workshops, and sponsors. I hope to see you in Nashville.

Last week we opened our first international office in Japan. This week we thought we'd take a closer look at Europe, which happens to be the largest demographic of GitHub users around the world, representing 36% of site traffic.

Around 32 million people visit GitHub each month, and most of this traffic comes from outside of the United States (74% in fact!). The most active countries in Europe are Germany, the United Kingdom, and France, but if we look at users per capita we see a different story -- Sweden, Finland, and the Netherlands lead the way. London, Paris and Stockholm top the list of European cities most active on GitHub.

The goals of building better software are universal, and several European organizations are setting the example. Companies like SAP and XS4ALL are driving innovation with software, while The UK Government Digital Services and dozens of other European government agencies and services are developing new ways to serve citizens.

Today, around 10% of GitHub employees are based in Europe, with a dozen new faces in the last year alone -- many of whom are focused solely on helping our European customers build great software. A few of us are here in the UK for London Tech Week and EnterConf in Belfast. There will be plenty more meetups ahead if we don't see you there.

You can now create deploy keys with read-only access. A deploy key is an SSH key that is stored on your server and grants access to a single GitHub repository. They are often used to clone repositories during deploys or continuous integration runs. Deploys sometimes involve merging branches and pushing code, so deploy keys have always allowed both read and write access. Because write access is undesirable in many cases, you now have the ability to create deploy keys with read-only access.

New deploy keys created through GitHub.com will be read-only by default and can be given write access by selecting "Allow write access" during creation. Access level can be specified when creating deploy keys from the API as well.

Navigating what's most important to you on GitHub.com just got a little easier with our updated site header.

The new header gives you faster access to your pull requests and issues dashboards from anywhere on the site. If you're unfamiliar with them, these dashboards list all of your open pull requests and issues—as well as those you've been mentioned in or are assigned to—in one place. Use them to stay up to date on what needs to be done across your projects.

Lastly, clicking your avatar now opens a new dropdown menu with links to your profile, account settings, and more. As a small bonus, we've also included a new Your stars link for easy access to your starred repositories.

Enjoy!

Organizations have always been the best way for teams to work together and collaborate on code. We're happy to announce major improvements to GitHub organization permissions. These improvements include new customizable member privileges, fine-grained team permissions, and more open communication.

The improved permissions system gives your organization the flexibility to work the way you want. Here are just a few highlights:

• (Opt-in) Members can view and mention all teams, even when they're not on those teams.
• (Opt-in) Members can create repositories without help from an owner.
• Members can create new teams to self-organize with the people they work with.
• Owners can give just the right amount of access to contractors and interns by adding them to repositories without giving them the privileges of organization members.
• And many more! Learn about GitHub's improved organization permissions.

All of these new features give your organization the ability to work together seamlessly without everyone needing to be an owner.

Once these features launch, organization owners will be able to turn on new permissions as needed. Simply opt-in when you're ready.

Coming soon

In the next few months, every organization on GitHub.com will have the improved permissions system.

One of the most useful features of any version control system is the ability to "undo" your mistakes. In Git, "undo" can mean many slightly different things.

When you make a new commit, Git stores a snapshot of your repository at that specific moment in time; later, you can use Git to go back to an earlier version of your project.

In this post, I'm going to take a look at some common scenarios where you might want to "undo" a change you've made and the best way to do it using Git.

Undo a "public" change

Scenario: You just ran git push, sending your changes to GitHub, now you realize there's a problem with one of those commits. You'd like to undo that commit.

Undo with: git revert <SHA>

What's happening: git revert will create a new commit that's the opposite (or inverse) of the given SHA. If the old commit is "matter", the new commit is "anti-matter"—anything removed in the old commit will be added in the new commit and anything added in the old commit will be removed in the new commit.

This is Git's safest, most basic "undo" scenario, because it doesn't alter history—so you can now git push the new "inverse" commit to undo your mistaken commit.

Fix the last commit message

Scenario: You just typo'd the last commit message, you did git commit -m "Fxies bug #42" but before git push you realized that really should say "Fixes bug #42".

Undo with: git commit --amend or git commit --amend -m "Fixes bug #42"

What's happening: git commit --amend will update and replace the most recent commit with a new commit that combines any staged changes with the contents of the previous commit. With nothing currently staged, this just rewrites the previous commit message.

Undo "local" changes

Scenario: The cat walked across the keyboard and somehow saved the changes, then crashed the editor. You haven't committed those changes, though. You want to undo everything in that file—just go back to the way it looked in the last commit.

Undo with: git checkout -- <bad filename>

What's happening: git checkout alters files in the working directory to a state previously known to Git. You could provide a branch name or specific SHA you want to go back to or, by default, Git will assume you want to checkout HEAD, the last commit on the currently-checked-out branch.

Keep in mind: any changes you "undo" this way are really gone. They were never committed, so Git can't help us recover them later. Be sure you know what you're throwing away here! (Maybe use git diff to confirm.)

Reset "local" changes

Scenario: You've made some commits locally (not yet pushed), but everything is terrible, you want to undo the last three commits—like they never happened.

Undo with: git reset <last good SHA> or git reset --hard <last good SHA>

What's happening: git reset rewinds your repository's history all the way back to the specified SHA. It's as if those commits never happened. By default, git reset preserves the working directory. The commits are gone, but the contents are still on disk. This is the safest option, but often, you'll want to "undo" the commits and the changes in one move—that's what --hard does.

Redo after undo "local"

Scenario: You made some commits, did a git reset --hard to "undo" those changes (see above), and then realized: you want those changes back!

Undo with: git reflog and git reset or git checkout

What's happening: git reflog is an amazing resource for recovering project history. You can recover almost anything—anything you've committed—via the reflog.

You're probably familiar with the git log command, which shows a list of commits. git reflog is similar, but instead shows a list of times when HEAD changed.

Some caveats:

• HEAD changes only.HEAD changes when you switch branches, make commits with git commit and un-make commits with git reset, but HEAD does not change when you git checkout -- <bad filename> (from an earlier scenario—as mentioned before, those changes were never committed, so the reflog can't help us recover those.
• git reflog doesn't last forever. Git will periodically clean up objects which are "unreachable." Don't expect to find months-old commits lying around in the reflog forever.
• Your reflog is yours and yours alone. You can't use git reflog to restore another developer's un-pushed commits.

So... how do you use the reflog to "redo" a previously "undone" commit or commits? It depends on what exactly you want to accomplish:

• If you want to restore the project's history as it was at that moment in time use git reset --hard <SHA>
• If you want to recreate one or more files in your working directory as they were at that moment in time, without altering history use git checkout <SHA> -- <filename>
• If you want to replay exactly one of those commits into your repository use git cherry-pick <SHA>

Once more, with branching

Scenario: You made some commits, then realized you were checked out on master. You wish you could make those commits on a feature branch instead.

Undo with: git branch feature, git reset --hard origin/master, and git checkout feature

What's happening: You may be used to creating new branches with git checkout -b <name>—it's a popular short-cut for creating a new branch and checking it out right away—but you don't want to switch branches just yet. Here, git branch feature creates a new branch called feature pointing at your most recent commit, but leaves you checked out to master.

Next, git reset --hard rewinds master back to origin/master, before any of your new commits. Don't worry, though, they are still available on feature.

Finally, git checkout switches to the new feature branch, with all of your recent work intact.

Branch in time saves nine

Scenario: You started a new branch feature based on master, but master was pretty far behind origin/master. Now that master branch is in sync with origin/master, you wish commits on feature were starting now, instead of being so far behind.

Undo with: git checkout feature and git rebase master

What's happening: You could have done this with git reset (no --hard, intentionally preserving changes on disk) then git checkout -b <new branch name> and then re-commit the changes, but that way, you'd lose the commit history. There's a better way.

git rebase master does a couple of things:

• First it locates the common ancestor between your currently-checked-out branch and master.
• Then it resets the currently-checked-out branch to that ancestor, holding all later commits in a temporary holding area.
• Then it advances the currently-checked-out-branch to the end of master and replays the commits from the holding area after master's last commit.

Mass undo/redo

Scenario: You started this feature in one direction, but mid-way through, you realized another solution was better. You've got a dozen or so commits, but you only want some of them. You'd like the others to just disappear.

Undo with: git rebase -i <earlier SHA>

What's happening: -i puts rebase in "interactive mode". It starts off like the rebase discussed above, but before replaying any commits, it pauses and allows you to gently modify each commit as it's replayed.

rebase -i will open in your default text editor, with a list of commits being applied, like this:

The first two columns are key: the first is the selected command for the commit identified by the SHA in the second column. By default, rebase -i assumes each commit is being applied, via the pick command.

To drop a commit, just delete that line in your editor. If you no longer want the bad commits in your project, you can delete lines 1 and 3-4 above.

If you want to preserve the contents of the commit but edit the commit message, you use the reword command. Just replace the word pick in the first column with the word reword (or just r). It can be tempting to rewrite the commit message right now, but that won't work—rebase -i ignores everything after the SHA column. The text after that is really just to help us remember what 0835fe2 is all about. When you've finished with rebase -i, you'll be prompted for any new commit messages you need to write.

If you want to combine two commits together, you can use the squash or fixup commands, like this:

squash and fixup combine "up"—the commit with the "combine" command will be merged into the commit immediately before it. In this scenario, 0835fe2 and 6943e85 will be combined into one commit, then 38f5e4e and af67f82 will be combined together into another.

When you select squash, Git will prompt us to give the new, combined commit a new commit message; fixup will give the new commit the message from the first commit in the list. Here, you know that af67f82 is an "ooops" commit, so you'll just use the commit message from 38f5e4e as is, but you'll write a new message for the new commit you get from combining 0835fe2 and 6943e85.

When you save and exit your editor, Git will apply your commits in order from top to bottom. You can alter the order commits apply by changing the order of commits before saving. If you'd wanted, you could have combined af67f82 with 0835fe2 by arranging things like this:

Fix an earlier commit

Scenario: You failed to include a file in an earlier commit, it'd be great if that earlier commit could somehow include the stuff you left out. You haven't pushed, yet, but it wasn't the most recent commit, so you can't use commit --amend.

Undo with: git commit --squash <SHA of the earlier commit> and git rebase --autosquash -i <even earlier SHA>

What's happening: git commit --squash will create a new commit with a commit message like squash! Earlier commit. (You could manually create a commit with a message like that, but commit --squash saves you some typing.)

You can also use git commit --fixup if you don't want to be prompted to write a new commit message for the combined commit. In this scenario, you'd probably use commit --fixup, since you just want to use the earlier commit's commit message during rebase.

rebase --autosquash -i will launch an interactive rebase editor, but the editor will open with any squash! and fixup! commits already paired to the commit target in the list of commits, like so:

When using --squash and --fixup, you might not remember the SHA of the commit you want to fix—only that it was one or five commits ago. You might find using Git's ^ and ~ operators especially handy. HEAD^ is one commit before HEAD. HEAD~4 is four commits before HEAD - or, altogether, five commits back.

Stop tracking a tracked file

Scenario: You accidentally added application.log to the repository, now every time you run the application, Git reports there are unstaged changes in application.log. You put *.log in the .gitignore file, but it's still there—how do you tell git to to "undo" tracking changes in this file?

Undo with: git rm --cached application.log

What's happening: While .gitignore prevents Git from tracking changes to files or even noticing the existence of files it's never tracked before, once a file has been added and committed, Git will continue noticing changes in that file. Similarly, if you've used git add -f to "force", or override, .gitignore, Git will keep tracking changes. You won't have to use -f to add it in the future.

If you want to remove that should-be-ignored file from Git's tracking, git rm --cached will remove it from tracking but leave the file untouched on disk. Since it's now being ignored, you won't see that file in git status or accidentally commit changes from that file again.

---

That's how to undo anything with Git. To learn more about any of the Git commands used here, check out the relevant documentation:

• checkout
• commit
• rebase
• reflog
• reset
• revert
• rm

GitHub <3s Japan, and today we’re excited to announce the formation of GitHub Japan G.K., a subsidiary of GitHub, Inc. Our new office in Tokyo is our first official office outside of the United States.

The Japanese developer community

GitHub couldn’t exist without the Japanese open source community — after all, our site is built on Rails, which is built on Ruby, an open source project started in Japan. Japan has historically been one of the most active countries on GitHub, ranking in the top 10 countries visiting github.com since GitHub was founded in 2008. The thriving software community in Japan keeps growing; in 2014, activity on github.com from Japan increased more than 60 percent from the previous year.

GitHub Enterprise in Japan

In addition to an active local open source community, Japanese businesses including Hitachi Systems, CyberAgent and GREE are collaborating and building the best software with GitHub Enterprise. To that end, we’re also announcing that we'll be partnering locally to provide Japanese language technical support for GitHub Enterprise users, as well as the ability to pay in Japanese Yen in Japan.

Stay up to date

Keep tabs on everything happening in our Tokyo office by following @GitHubJapan on Twitter and checking out github.co.jp. We’d also love to see you at our meetup in Osaka on June 6.

Yoroshiku-Onegaiitashimasu!

初めましてGitHub Japanです！

GitHub <3s Japan, 本日、私達はGitHub, Inc.の子会社である、GitHub Japan合同会社の設立の発表ができる事をとても光栄に思っております 。東京にオープンした新しいオフィスは、米国外でオープンする初のオフィスになります。

〜日本のデベロッパー・コミュニティにむけて〜

GitHubは、日本で生まれたオープンソース・プロジェクトのRubyで作られたRailsというフレームワークによって開発されており、日本のオープンソース・コミュニティーなしではGitHubは存在しえないと言っては過言ではない程、日本とGitHubは深いつながりがあります。 また、2008年のGitHub設立当初から、日本からgithub.comへのアクセス数は上位10ヶ国に入り続けてきました。そして、日本のユーザーは現在も増加し続けており、2014年の日本ユーザーのGitHub上でのアクティビティは、前年比60％も増加しました。

～「GitHub Enterprise」の日本展開～

GitHubは広く開かれた開発を支援するオープンソース・プラットフォーム以外にも、全世界で企業向けに「GitHub Enterprise」を提供して参りました。これまで「GitHub Enterprise」は、英語でのサポートのみだったにもかかわらず、日本国内では、株式会社日立システムズ、ヤフー株式会社、株式会社サイバーエージェントやグリー株式会社 などの大手企業をはじめとして、多くの先進的な企業にご活用頂いて参りました。そして今回、さらに迅速できめ細かいサービスやサポートを提供するため、GitHubは大手代理店と業務提携を行い、日本語による「GitHub Enterprise」の法人向け導入サポートも開始しました。この販売パートナー提携により、円建て決済や日本語のテクニカルサポートも可能になります。

GitHub の最新の情報を得よう

東京オフィスで何が起こっているか知る為にはTwitterで @GitHubJapan をフォローするか、 github.co.jpにアクセスしてくださいね。そして大阪で開催されるuser meetup にも是非お越しください！ お待ちしております！.

よろしくお願い致します！

CodeConf is coming June 25 & 26 to Nashville and will feature the best that the open source community has to offer.

We're excited to share that there will be several talks about the Atom ecosystem presented for your enjoyment and edification, kicked off by GitHub CEO Chris Wanstrath. Speakers will include:

• @bolinfest talking about Nuclide
• @lee-dohm talking about the Atom community
• @paulcbetts talking about Slack and Electron

We will also be hosting an Atom workshop led by Nathan Sobo, and a lounge where you will be able to meet with the core team and hack on Atom together.

Grab your CodeConf and workshop tickets now and we'll see you there in Nashville!

When we shipped the new GitHub Issues, we made it easy to scope lists of Issues and Pull Requests with filters like author, date, mentions, and team mentions. With the new status: filter you can now filter the Pull Requests in your repositories by combined status.

If you're taking advantage of the Status API, or using an integration that does, try out the new filters:

• status:success Only pull requests with all successful statuses
• status:failure Only pull requests that have statuses in the failure or error state
• status:pending Only pull requests with no statuses or at least one status in the pending state

GitHub for Windows now makes it even easier to see everything local to your machine, whether it's uncommitted changes or commits you haven't synced yet.

One of the things you'll notice when creating commits is the new, compact list of changed files in your working directory.

GitHub for Windows shows the number of files that a commit changed and lets you drill down to see what changed in a given file.

The updated branch selector now groups your recently used branches so that you can jump straight back in to what you were doing before that pesky hotfix distracted you.

We've given branch creation a dedicated place in the toolbar. As a bonus, you can pick which branch to base the new one off.

Finally, you can collapse the repository list to reclaim some screen space.

If you have GitHub for Windows installed it will automatically update to the latest version. If you don't have it installed, download GitHub for Windows from windows.github.com.

With the purchase of the Pridetocat Shirt you will be assisting Lesbians Who Tech, Maven, and Trans*H4CK to further their work. All proceeds from sales will be donated to these organizations that are helping educate, connect and empower LGBTQ people in tech.

This limited edition shirt is available in the GitHub Shop until August 31st.

More info about the LGBTQ tech organizations that benefit from the purchase of this shirt:

Lesbians Who Tech

Lesbians Who Tech is a global community of 9,000 queer women in tech. It exists to provide value to queer women in tech, a demographic that is rarely represented in both the tech community and the LGBTQ community.

Trans*H4CK

Trans*H4CK is a hackathon and speaker series that tackles social problems by developing new and useful open source tech products that benefit the trans and gender non-conforming communities, while bringing visibility to transgender tech innovators and entrepreneurs.

Maven

Maven partner with local LGBTQA youth serving organizations and LGBTQA tech professionals to provide free tech camps, workshops, Game Jams/hackathons for the queer youth community.