desktop / desktop

Focus on what matters instead of fighting with Git.

GitHub Desktop

GitHub Desktop is an open-source Electron-based GitHub app. It is written in TypeScript and uses React.

Where can I get it?

Download the official installer for your operating system:

• macOS
• macOS (Apple silicon)
• Windows
• Windows machine-wide install

Linux is not officially supported; however, you can find installers created for Linux from a fork of GitHub Desktop in the Community Releases section.

Beta Channel

Want to test out new features and get fixes before everyone else? Install the beta channel to get access to early builds of Desktop:

• macOS
• macOS (Apple silicon)
• Windows
• Windows (ARM64)

The release notes for the latest beta versions are available here.

Community Releases

There are several community-supported package managers that can be used to install GitHub Desktop:

• Windows users can install using winget c:\> winget install github-desktop or Chocolatey c:\> choco install github-desktop
• macOS users can install using Homebrew package manager: $ brew install --cask github

Installers for various Linux distributions can be found on the shiftkey/desktop fork.

Is GitHub Desktop right for me? What are the primary areas of focus?

This document describes the focus of GitHub Desktop and who the product is most useful for.

I have a problem with GitHub Desktop

Note: The GitHub Desktop Code of Conduct applies in all interactions relating to the GitHub Desktop project.

First, please search the open issues and closed issues to see if your issue hasn't already been reported (it may also be fixed).

There is also a list of known issues that are being tracked against Desktop, and some of these issues have workarounds.

If you can't find an issue that matches what you're seeing, open a new issue, choose the right template and provide us with enough information to investigate further.

The issue I reported isn't fixed yet. What can I do?

If nobody has responded to your issue in a few days, you're welcome to respond to it with a friendly ping in the issue. Please do not respond more than a second time if nobody has responded. The GitHub Desktop maintainers are constrained in time and resources, and diagnosing individual configurations can be difficult and time consuming. While we'll try to at least get you pointed in the right direction, we can't guarantee we'll be able to dig too deeply into any one person's issue.

How can I contribute to GitHub Desktop?

The CONTRIBUTING.md document will help you get setup and familiar with the source. The documentation folder also contains more resources relevant to the project.

If you're looking for something to work on, check out the help wanted label.

Building Desktop

To setup your development environment for building Desktop, check out: setup.md.

More Resources

See desktop.github.com for more product-oriented information about GitHub Desktop.

See our getting started documentation for more information on how to set up, authenticate, and configure GitHub Desktop.

License

MIT

The MIT license grant is not for GitHub's trademarks, which include the logo designs. GitHub reserves all trademark and copyright rights in and to all GitHub trademarks. GitHub's logos include, for instance, the stylized Invertocat designs that include "logo" in the file title in the following folder: logos.

GitHub® and its stylized versions and the Invertocat mark are GitHub's Trademarks or registered Trademarks. When using GitHub's logos, be sure to follow the GitHub logo guidelines.

desktop's Issues

List & clone GitHub repositories

Mac and Windows had different designs for this, so we'll need to decide on one.

`npm start` race

We currently use npm-run-all parallel to start both the dev server and launch the app. Since we start them both in parallel, there's a race where sometimes the dev server won't have started by the time the app launches and so trying to load the bundle will fail.

Autocomplete emoji

Sign apps/installers

We'll need to get some certificates we can use to sign the apps/installers. I can take care of the OS X side of this, but I haven't a clue about the Windows side.

• macOS
• Windows

Install git from the app

Sign in to GitHub

Both .com and Enterprise instances.

"Open Conflict Resolution Tool" button

If there are conflicts, we should offer to open the conflict resolution tool.

Rewrite our build scripts in TypeScript

Because T Y P E S

For some reason I was thinking we'd need to setup a whole compilation step for them. But we can use ts-node to run them and it should Just Work®.

Configure tracked LFS files

Manage the gitattributes file.

Should we hard wrap commit messages?

Enter a commit message and commit.

Save last clone location

Stage lines

Should we actually stage them as this point, or just keep them in memory?

Report crashes/exceptions somewhere

Probably central. We should also capture and track any uncaught exceptions from JS.

Setup gpg signing

We should explore setting up commit signing with GPG in Desktop. This could take two forms (or both):

1. Automatic commit signing using GitHub's GPG key in the same way that dotcom does it today, if the user is signed in to GitHub from Desktop.
2. Allow people to set up and utilize their own GPG key to sign commits in Desktop, and make that visible to users during the commit flow.

Report usage stats

To somewhere. Probably central.

Install updates

As of https://github.com/github/central/pull/266, Central should be serving us updates. So we should check for them and install them.

create delta packages on Windows

Following on from #47, we need to enable delta package creation and publishing:

• electron-windows-installer has a remoteReleases parameter which it should use to retrieve existing releases
• we'd need to then upload the right file as part of the release (see #47)
• there's probably some other work in the app to verify we're applying these updates

List branches

Sort by recency.

Give CircleCI a chance

Our Appveyor builds are currently ~3x faster than our Travis builds. It'd be interesting to see how CircleCI performs.

Collect metrics

TBD which metrics are worth collecting

Use npm shrinkwrap

We use shrink-wrap our dependencies so they don't move out from under us.

Autocomplete issue mentions

Packaging the app

Our logic for packaging the app is less than ideal. This is due to the combination of a few things:

1. We want to run the packaged app itself for development. This is because (1) we use a URL protocol, which means munging the Info.plist, (2) some behaviors differ between electron-prebuilt and a packaged app (e.g., default menu bar), (3) we gotta see that sweet icon.
2. We don't want to include most of our dev dependencies in the built development app because this means copying lots of small files, which slows build time way down, especially on OSes with shitty file systems (e.g., Windows).
3. But we do want to include a few of our dev dependencies (e.g., for hot module replacement).

To bring all these pieces together, we currently have a special debugDependencies section in our package.json:

desktop/package.json

Line 42 in 28fc410

"debugDependencies": {

. These are the dev dependencies we want in dev builds.

Then at build time we copy our package.json, munge it a bit, and install those modules into a new directory.

This whole arrangement works^*, but it has some downsides:

1. It's complex. We have to invent this debugDependencies thing and munge the package.json.
2. It doesn't really support shrink-wrapping. We'd have to do more custom work.

This feels more complicated than it should be. Is there some easier way? @desktop/electron any thoughts or advice you could give us?

^* For any sufficiently generous definition of "works."

Create new repository

In Desktop today, creating a new GitHub repository is a two-step process:

1. Create the local repo.
2. Publish to GitHub.

Should this continue to be a two-step? Or assume they wanna publish to GitHub?

Stage files

Should we actually stage at this point, or just keep the state in memory?

Publish branch

State Sharing And You

I'm looking for some Thoughts and Opinions on Electron app architecture.

In #81, I'm running into the first time where we have some state that I wanna access in both the main process and the renderer process. And I'm wondering how we should organize it. Who should own it and communicate it to those who want to know it?

I see a few options, but it's entirely possible there are others:

1. Main Process

The main process is the only global, shared thing in the app. So my initial thought is that the main process should own all global shared state:

1. 👍 Global.
2. 👎 No access to web APIs.
3. 👎 Harder to debug.
4. 👎 Ties up the main process from doing other important things.

2. Renderer Process

OK, so the main process has downsides. What if we make the renderer process the state keeper.

1. 👍 Access to web APIs.
2. 👍 Debuggable.
3. 👎 Conceptually weird to keep global shared state in something which is neither global nor shared. What if we have multiple windows?

3. Background Process

Some Electron apps employ a pattern where they have a hidden global renderer process.

1. 👍 Global.
2. 👍 Access to web APIs.
3. 👍 Debuggable.
4. 👎 IPC would (I think?) be two-step. Renderer -> main process -> background process.

I think (3) makes the most sense, but I'm not set on anything.

Thoughts? Ideas? @desktop/electron, I'd be really curious to hear what you all think.

Test updates

• macOS
• Windows

Create branch

1. Validate against existing branch names.
2. Sanitize whitespace/another not-allowed characters.

Checkout branch

What is says on the tin.

Set conflict resolution tool

Let the user select a conflict resolution tool that we can open for them.

Split app compilation from test compilation

Currently build compiles both the app and the tests. That's just silly.

Opt out of metrics

List added repositories

Show the list of repositories they've added to the app.

Serve updates from somewhere

Presumably central.

Support deployment, somehow

Ideally with Cha-Tops.

Windows already does this, right? Atom kinda did this, though it was less than ideal.

Report performance metrics

To somewhere. Probably central.

Show changed files

Release builds

As of #18 we have debug builds.

But we need to do some more work for release builds:

• Prune development modules.
• Remove Webpack hot reloading middleware.
• Uglify/compress JS.
• Webpack the browser code.
• Enable asar?

Package apps

• Windows
• OS X

We should look at using electron-packager or electron-builder or some such.

Add existing repository

Add ohnogit/nodegit

Package git in the app

Dependent on #5.

We'll need to shell out to git sometimes, so it'll need to be in the app.

• macOS
• Windows

UI design philosophy

Will we be re-creating the existing Desktop UI? Will it be something different? Will the UI be themed per-platform or universal?

Autocomplete user mentions

Merge branches

Stop extending BrowserWindow

We're currently extending BrowserWindow, but it turns out we shouldn't be.

Get notifications posting into #desktop

This'll probably be terrible since we're not in the GitHub org.

git-macos loses its soft links

Starting in #94, when we copy git into the app bundle for macOS, the soft links get converted to hard links which blow up the size of the app.

I'm not really sure why, but we should fix this. It's a ~180MB difference 😞

Setup git

Set the global name/email.