To protect your Git installation from accidental changes, use the default (privileged) path C:\Program Files\Git. We highly recommend it.

The default selections make sense. If you would also like a handy desktop icon, tick the Additional icons option.

On Windows, it is a good idea to create an additional folder in the Start Menu. If you ever lose your desktop icons, you can always find your important applications from there.

Every change you commit to a Git repository is accompanied by a short commit message that describes what changed. You can write that message on the command line (git commit -m "…​") or in a text editor.

The default editor for Git is vi (VIM), which is widely used on Unix and Linux but unusual for Windows users. For now, just leave VIM as the default. You can configure a GUI-based editor for Git commits later if you prefer.

A branch in a Git repository is the name of the current line of changes. For historical reasons the main branch used to be called master. That name is no longer the standard today; modern projects (and GitHub itself) use main. Pick main here so your repository matches GitHub’s default.

Git was originally developed on Unix systems like Linux. The Windows version of Git uses real Unix-style commands under the hood, through a compatibility layer called MSYS. Some of these Unix commands (for example find) share names with Windows commands.

The default option avoids conflicts between commands that happen to share the same name, so we highly recommend keeping it.

As mentioned, Git comes from the Unix world. On Unix-like systems the Secure Shell (SSH) subsystem is widely used to create secure, encrypted connections. Windows does not include SSH by default.

For most Git installations on Windows, the default option (use the bundled OpenSSH subsystem) is the right choice.

Similarly, SSL libraries are not available on Windows by default. SSH itself relies on SSL to establish secure encrypted connections.

For compatibility, keep the default option (OpenSSL).

Text files separate their lines with invisible line-ending characters. Annoyingly, different operating systems use different ones. Unix and Linux use LF (line feed). Windows uses two characters: CR (carriage return) followed by LF, together written as CRLF.

The best compromise is to let Git handle this for you. All text files stored in the repository use LF (the Unix style), but Git automatically converts them to CRLF when they are checked out on Windows.

As mentioned, Git uses MSYS to provide Unix-style commands on Windows. In addition to native Windows shells like the cmd.exe command prompt, Git also ships with its own Git Bash shell. Git Bash is based on the Unix shell bash, which is the standard on Linux.

For working with J1 projects, a Windows command prompt is perfectly fine. Still, a real Unix shell can be handy from time to time, so leave the default unchanged.

You already know that Git is a distributed version-control system. The core idea is that there is a remote repository on a server somewhere and a local working copy on each developer’s computer. From time to time, the local changes have to be merged back into the remote.

You can probably guess that merging changes from many people is not trivial and can produce conflicts. Git offers several strategies to do the merge. The simplest one is called fast-forward. Fast-forward merges work very well when the changes are small and frequent — which is exactly how most people work day to day.

Keep this default setting.

You already know GitHub as a service provider and have an account there for managing your repositories. Unfortunately, the Internet is not always a peaceful place: passwords and access tokens have to be stored carefully.

The Git Credential Helper takes care of storing your GitHub account information securely on your PC. Keep the default setting here for the simplest and safest way to authenticate to GitHub.

Git can also use extended features of the operating system for handling files and directories. These extensions apply to every supported operating system.

Keep both options enabled to get the best support for files and folders.

Experimental features can be useful, but they are intended for experienced users. They are not required for using Git with J1 projects, so do not enable them here.

You will work with version control throughout the next sections. There is no repository on your computer yet, so there is no point in starting a Git shell right now.

It is worth reading the release notes of any software you install. The "what changed" information is especially useful when upgrading to a new major version. For a fresh install you can skip the release notes for now and come back to them later if you need to.

The Atom installation runs fully automatically. The installer applies all the necessary default settings; you can adjust them later if you need to.

When installation finishes, Atom starts automatically and asks a few follow-up questions.

A URI (Uniform Resource Identifier) is a short string that identifies a resource — typically a file, a network location, or a program. URIs are how the web finds and loads pages, and they also work for resources on your local computer.

Atom uses URIs that start with atom:// to manage its add-ons and plug-ins. Let Atom register that URI scheme so the management of Atom-specific resources works correctly.

Atom can send usage information back to its developers over the Internet to help them improve the product. Whether to allow this is up to you. The author of this tutorial uses Atom on Windows mainly for J1 projects, with a very simple setup; in that case the telemetry data is not very useful, so the option is turned off.

But the choice is yours.

You can choose to display a welcome guide every time you start a new Atom window. The first time you use Atom, the welcome tab can be helpful. Plenty of good tutorials on Atom are available online as well.

Keep this option on or off as you prefer. You can disable the welcome tab at any time.