libgit2 is a portable, pure C implementation of the Git core methods
provided as a linkable library with a solid API, allowing to build Git
functionality into your application. Language bindings like
Rugged (Ruby),
LibGit2Sharp (.NET),
pygit2 (Python) and
NodeGit (Node) allow you to build Git tooling
in your favorite language.
libgit2 is used to power Git GUI clients like
GitKraken and gmaster
and on Git hosting providers like GitHub,
GitLab and
Azure DevOps.
We perform the merge every time you click "merge pull request".
libgit2 is licensed under a very permissive license (GPLv2 with a special
Linking Exception). This basically means that you can link it (unmodified)
with any kind of software without having to release its source code.
Additionally, the example code has been released to the public domain (see the
separate license for more information).
Most of these instructions assume that you're writing an application
in C and want to use libgit2 directly. If you're not using C,
and you're writing in a different language or platform like .NET,
Node.js, or Ruby, then there is probably a
"language binding" that you can use to take care
of the messy tasks of calling into native code.
But if you do want to use libgit2 directly - because you're building
an application in C - then you may be able use an existing binary.
There are packages for the
vcpkg and
conan
package managers. And libgit2 is available in
Homebrew and most Linux
distributions.
However, these versions may be outdated and we recommend using the
latest version if possible. Thankfully libgit2 is not hard to compile.
Quick Start
Prerequisites for building libgit2:
CMake, and is recommended to be installed into
your PATH.
Python is used by our test framework, and
should be installed into your PATH.
C compiler: libgit2 is C90 and should compile on most compilers.
Windows: Visual Studio is recommended
Mac: Xcode is recommended
Unix: gcc or clang is recommended.
Build
Create a build directory beneath the libgit2 source directory, and change
into it: mkdir build && cd build
Create the cmake build environment: cmake ..
Build libgit2: cmake --build .
Trouble with these steps? Read our troubleshooting guide.
More detailed build guidance is available below.
via Slack: visit slack.libgit2.org to sign up,
then join us in #libgit2
Getting Help
If you have questions about the library, please be sure to check out the
API documentation. If you still have
questions, reach out to us on Slack or post a question on
StackOverflow (with the libgit2 tag).
Reporting Bugs
Please open a GitHub Issue and
include as much information as possible. If possible, provide sample code
that illustrates the problem you're seeing. If you're seeing a bug only
on a specific repository, please provide a link to it if possible.
We ask that you not open a GitHub Issue for help, only for bug reports.
Reporting Security Issues
Please have a look at SECURITY.md.
What It Can Do
libgit2 provides you with the ability to manage Git repositories in the
programming language of your choice. It's used in production to power many
applications including GitHub.com, Plastic SCM and Azure DevOps.
It does not aim to replace the git tool or its user-facing commands. Some APIs
resemble the plumbing commands as those align closely with the concepts of the
Git system, but most commands a user would type are out of scope for this
library to implement directly.
The library provides:
SHA conversions, formatting and shortening
abstracted ODB backend system
commit, tag, tree and blob parsing, editing, and write-back
As libgit2 is purely a consumer of the Git system, we have to
adjust to changes made upstream. This has two major consequences:
Some changes may require us to change provided interfaces. While we try to
implement functions in a generic way so that no future changes are required,
we cannot promise a completely stable API.
As we have to keep up with changes in behavior made upstream, we may lag
behind in some areas. We usually to document these incompatibilities in our
issue tracker with the label "git change".
Optional dependencies
While the library provides git functionality without the need for
dependencies, it can make use of a few libraries to add to it:
pthreads (non-Windows) to enable threadsafe access as well as multi-threaded pack generation
OpenSSL (non-Windows) to talk over HTTPS and provide the SHA-1 functions
LibSSH2 to enable the SSH transport
iconv (OSX) to handle the HFS+ path encoding peculiarities
Initialization
The library needs to keep track of some global state. Call
git_libgit2_init();
before calling any other libgit2 functions. You can call this function many times. A matching number of calls to
git_libgit2_shutdown();
will free the resources. Note that if you have worker threads, you should
call git_libgit2_shutdownafter those threads have exited. If you
require assistance coordinating this, simply have the worker threads call
git_libgit2_init at startup and git_libgit2_shutdown at shutdown.
See conventions for an overview of the external
and internal API/coding conventions we use.
Building libgit2 - Using CMake
Building
libgit2 builds cleanly on most platforms without any external dependencies.
Under Unix-like systems, like Linux, *BSD and Mac OS X, libgit2 expects pthreads to be available;
they should be installed by default on all systems. Under Windows, libgit2 uses the native Windows API
for threading.
The libgit2 library is built using CMake (version 2.8 or newer) on all platforms.
On most systems you can build the library using the following commands
Once built, you can run the tests from the build directory with the command
$ ctest -V
Alternatively you can run the test suite directly using,
$ ./libgit2_tests
Invoking the test suite directly is useful because it allows you to execute
individual tests, or groups of tests using the -s flag. For example, to
run the index tests:
$ ./libgit2_tests -sindex
To run a single test named index::racy::diff, which corresponds to the test
function test_index_racy__diff:
$ ./libgit2_tests -sindex::racy::diff
The test suite will print a . for every passing test, and an F for any
failing test. An S indicates that a test was skipped because it is not
applicable to your platform or is particularly expensive.
Note: There should be no failing tests when you build an unmodified
source tree from a release,
or from the main branch.
Please contact us or open an issue
if you see test failures.
Installation
To install the library you can specify the install prefix by setting:
CMAKE_INSTALL_BINDIR: Where to install binaries to.
CMAKE_INSTALL_LIBDIR: Where to install libraries to.
CMAKE_INSTALL_INCLUDEDIR: Where to install headers to.
BUILD_SHARED_LIBS: Build libgit2 as a Shared Library (defaults to ON)
BUILD_TESTS: Build the unit and integration test suites (defaults to ON)
USE_THREADS: Build libgit2 with threading support (defaults to ON)
To list all build options and their current value, you can do the
following:
# Create and set up a build directory
$ mkdir build
$ cmake ..
# List all build options and their values
$ cmake -L
Compiler and linker options
CMake lets you specify a few variables to control the behavior of the
compiler and linker. These flags are rarely used but can be useful for
64-bit to 32-bit cross-compilation.
CMAKE_C_FLAGS: Set your own compiler flags
CMAKE_FIND_ROOT_PATH: Override the search path for libraries
ZLIB_LIBRARY, OPENSSL_SSL_LIBRARY AND OPENSSL_CRYPTO_LIBRARY:
Tell CMake where to find those specific libraries
LINK_WITH_STATIC_LIBRARIES: Link only with static versions of
system libraries
MacOS X
If you want to build a universal binary for Mac OS X, CMake sets it
all up for you if you use -DCMAKE_OSX_ARCHITECTURES="i386;x86_64"
when configuring.
Android
Extract toolchain from NDK using, make-standalone-toolchain.sh script.
Optionally, crosscompile and install OpenSSL inside of it. Then create CMake
toolchain file that configures paths to your crosscompiler (substitute {PATH}
with full path to the toolchain):
Add -DCMAKE_TOOLCHAIN_FILE={pathToToolchainFile} to cmake command
when configuring.
MinGW
If you want to build the library in MinGW environment with SSH support enabled,
you may need to pass -DCMAKE_LIBRARY_PATH="${MINGW_PREFIX}/${MINGW_CHOST}/lib/" flag
to CMake when configuring. This is because CMake cannot find the Win32 libraries in
MinGW folders by default and you might see an error message stating that CMake
could not resolve ws2_32 library during configuration.
Another option would be to install msys2-w32api-runtime package before configuring.
This package installs the Win32 libraries into /usr/lib folder which is by default
recognized as the library path by CMake. Please note though that this package is meant
for MSYS subsystem which is different from MinGW.
Language Bindings
Here are the bindings to libgit2 that are currently available:
If you start another language binding to libgit2, please let us know so
we can add it to the list.
How Can I Contribute?
We welcome new contributors! We have a number of issues marked as
"up for grabs"
and
"easy fix"
that are good places to jump in and get started. There's much more detailed
information in our list of outstanding projects.
libgit2 is under GPL2 with linking exception. This means you can link to
and use the library from any program, proprietary or open source; paid or
gratis. However, if you modify libgit2 itself, you must distribute the
source to your modified version of libgit2.
请发表评论