-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Git for Windows currently works with all recent, commercially released x64 versions of Windows, starting with Windows 8.1.
NOTE: Git for Windows version 2.46.2 was the last version supporting Windows 7 and 8.
NOTE: Git for Windows version 2.40.1 was the last version with full support for any 32-bit Windows version.
NOTE: Git for Windows version 2.37.1 was the last version supporting Windows Vista and Server 2008.
NOTE: Git for Windows version 2.10.0 was the last version supporting Windows XP and Server 2003.
Windows 7, 8, XP and Windows Server 2003 are long past their end of life, hence support for these versions was dropped from Git for Windows 2.47.0 and later. This limitation is inherited by Git's use of MSYS2, which in turn inherited it from Cygwin (see this and this mail).
More information here: Git for Windows' prerequisites.
There is currently no MSI package; there is an exe installer and a portable package. You are welcome to contribute a Pull Request that packages a new installer.
There is an existing Pull Request in development and looking for testers, please try out https://github.com/robmen/gitsetup/issues/1 and give feedback. It's closed by now. Future development is happening here.
In the meantime you could try:
- using the portable package
- deploying the exe installer with System Center Configuration Manager
- deploying the portable package via a script
- deploying the Chocolatey package via Puppet (or something similar)
In general, yes: it is a good idea to stay up-to-date.
If you have a version older than 2.45.1, it is highly advisable to upgrade. A couple of Git versions came with important fixes to security-relevant vulnerabilities: 2.45.1, 2.40.1, 2.39.2, 2.39.1, 2.38.1, 2.37.1, 2.36.0, 2.35.3, 2.35.3, 2.30.2, 2.30.0(2), 2.29.2(3), 2.29.2(2), 2.26.1, 2.24.1(2), 2.17.1(2), 2.14.1, 2.7.4, 2.7.0, 2.6.1, 2.5.2, 1.9.5-preview20150319, and 1.9.5-preview20141217.
This depends on how you installed Git for Windows. The bundle installation requires you to download and install the new version. Any customizations you made will be kept as long as you did so in the appropriate configuration folders.
Git for Windows comes with a tool to check for updates and offer to install them. Whether or not you enabled auto-updates during installation, you can manually run git update-git-for-windows. (For help, run git update-git-for-windows -h.)
For advanced users working with the Git for Windows SDK pacman is available as a package manager. See Package management
For hashes see https://github.com/git-for-windows/git/releases
For (G4W) release notes see the build-extra repo, or the top level of your installation (e.g. C:\Program Files\Git\ReleaseNotes.html - via manual browsing).
For extracting 7z/zip archives see page.
The Git for Windows builds are not quite that frequent, but there are Snapshot builds listed at https://wingit.blob.core.windows.net/files/index.html
These often 'fix' (or attempt fixes) recent issues before a new formal release. Check their commit notes and links to issues to see if your problem is included.
Official Git for Windows versions mainly follow Git's release cycle: every 12 weeks or so, a new major Git version is released (see details here: https://tinyurl.com/gitCal). Typically, Git for Windows will follow suit within a day.
Other than that, Git for Windows follows the newest Git version's maintenance releases (read: after Git for Windows v2.15.0 was released, no new Git for Windows v2.14.x version would be released). Indicators for imminent maintenance releases of Git are:
- The Git maintainer sometimes talks about this in the preamble of the "What's cooking in git.git" mails.
- The
maintin git.git accumulates critical patches.
Finally, Git for Windows is sometimes released in "out-of-band" versions, when critical fixes specific to Git for Windows necessitate it. These out-of-band versions are indicated by appending a (2) to the latest release (or (3), (4), etc). Examples for such out-of-band versions include: Git for Windows v2.15.1(2) and Git for Windows v2.16.1(4).
Git for Windows used to be developed using the development environment called "msysGit", but roughly coinciding with Git 2.1, msysGit was superseded by a new development environment: the Git for Windows SDK. See here to get a copy.
Git for Windows defaults to using mintty terminal. Compared to default Windows console host, it provides normal multi-line cut&paste, working resizing, defaults to unicode font and avoids some bugs in the default console host. However it does not present itself as console to native applications (those not built with MSys or Cygwin), so in these applications:
- Non-ASCII output may be corrupted due to mismatch in character sets (MSYS2 and Cygwin use UTF-8 while Windows will fall back to the legacy DOS codepages in this case).
- Interactive and full-screen applications won't work at all.
There are several methods for working around these problems:
- Run programs that have problems using the
winptyutility. This allows you to keep using the nicer mintty terminal, but can become unwieldy if you need the workaround for many programs. - Modify the shortcut for Git Bash to run
bashdirectly withoutminttyso it uses the default console host and configure it for "Quick Edit", reasonable size and scroll-back and suitable unicode font. You'll still have to live with the other quirks of console host. - Install and use ConEmu.
Windows file paths are by default limited to 260 characters. Some repositories may have committed files which contain paths longer than the limit. By default, Git for Windows does not support long paths, and will print errors when trying to perform any operation on a long file name. Set the configuration property core.longpaths to true to allow certain Git operations to properly handle these files. See this wiki page for more information.
All the apparent copies are simply hard links - see Issue 1997 Use symbolic links for libexec for more details.
Excel (and some other apps) do not update the modified time of its files which is used by Git to quickly detect changes. Rather Excel used the change time field. Git will notice the modifications if a git status is performed. See issue 1000 if you need more background.
The Microsoft Team Foundation Server is capable of hosting git repositories. If the server is a member of a windows domain, and your user account is in that domain, you can use domain authentication to identify yourself to the server, and can thus access git repositories without having to enter any credentials. For this to work, the server has to be configured to use domain authentication, not NTLM authentication. The repository URL can be obtained from the TFS web interface, it may look like http://server.example.com:8080/tfs/TWA/TeamDev/_git/reponame.
In order to instruct git to use domain authentication, prefix the server name with :@, like so: http://:@server.example.com:8080/tfs/TWA/TeamDev/_git/reponame. This is a special case of the usual username:password@server syntax, where both the username and password fields are empty. This causes git to look up and use your domain credentials.
See also: Clone an existing Git repo - Azure Repos
Some DSA keys are not considered secure anymore by OpenSSH 7. Adding "PubkeyAcceptedKeyTypes ssh-dss" to ~/.ssh/config helps.
If you choose to use OpenSSH that comes with git during installation (default option) and wish to work from Windows' Command Prompt (cmd) or PowerShell instead of Git Bash you should make sure:
-
You're calling the correct executables.
Windows comes with a different OpenSSH distribution and by default you might be calling it while git commands use its own. Set the environment PATH to use the git installation ssh commands first, those are usually atC:\Program Files\Git\usr\bin.
In CMD:set PATH=C:\Program Files\Git\usr\bin;%PATH%
In PowerShell:$Env:PATH = "C:\Program Files\Git\usr\bin;$Env:PATH"
This will make sure, for example, that you add the private keys to the correct ssh-agent service when callingssh-add. Otherwise you might be asked to introduce the passphrase on each git command call that connects to a remote repository. -
Git's ssh is able to connect to the ssh-agent.
In order to connect to the ssh-agent service, git's ssh needs to know how. This is accomplished by two environment variables calledSSH_AGENT_PIDandSSH_AUTH_SOCK. Luckily, there is a convenient scriptstart-ssh-agent.cmdincluded with the git installation you can call to set this up. The values are dynamic and only valid after calling the script. Forgetting to set them will fail silently, so be sure to call the script each time you open a new command prompt.
Some developers want to start git-bash (of Git for Windows SDK) with a different language.
To achieve this in windows following command could be placed inside the launcher:
C:\Windows\System32\cmd.exe /c "set LANG=en_GB && start C:\git-sdk-64\git-bash.exe && exit"
replace en_GB with your preferred locale.
(i.e. fatal error C1083: Cannot open include file: 'openssl/ssl.h': No such file or directory)
Try to open the console and invoke git\compat\vcbuild\vcpkg_install.bat. Make sure that it has completed successfully, then clean and rebuild the solution.
Ensure also that you are using proper Build Tools (v140). It's going by default in VS 2015. If you are using VS 2017, you need to install them manually. Do not upgrade the project to v141 - it can't be done automatically.
Reproduced from Git for Windows' release notes:
Git is an Open Source project covered by the GNU General Public License version 2 (some parts of it are under different licenses, compatible with the GPLv2). It was originally written by Linus Torvalds with help of a group of hackers around the net.
Git for Windows also contains Embedded CAcert Root Certificates. For more information please go to https://www.cacert.org/policy/RootDistributionLicense.php.
This package contains software from a number of other projects including Bash, zlib, curl, tcl/tk, perl, MSYS2 and a number of libraries and utilities from the GNU project, licensed under the GNU General Public License. Likewise, it contains Perl which is dual licensed under the GNU General Public License and the Artistic License.
This is the Git for Windows wiki. See how-to-participate.