[v6,1/1] ci: Introduce travis builds for github repositories
Checks
Commit Message
GitHub is a service used by developers to store repositories. GitHub
provides service integrations that allow 3rd party services to access
developer repositories and perform actions. One of these services is
Travis-CI, a simple continuous integration platform.
This is a simple initial implementation of a travis build for the DPDK
project. It doesn't require any changes from individual developers to
enable, but will allow those developers who opt-in to GitHub and the
travis service to get automatic builds for every push they make.
Additionally, the travis service will send an email to the test-report
list informing anyone interested in the automated build (including a
result).
Signed-off-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Michael Santana <msantana@redhat.com>
---
v6:
Removed all classic make builds
.ci/linux-build.sh | 21 +++++++++
.ci/linux-setup.sh | 3 ++
.travis.yml | 73 +++++++++++++++++++++++++++++
MAINTAINERS | 6 +++
doc/guides/contributing/patches.rst | 4 ++
5 files changed, 107 insertions(+)
create mode 100755 .ci/linux-build.sh
create mode 100755 .ci/linux-setup.sh
create mode 100644 .travis.yml
Comments
On Mon, 2019-03-04 at 11:12 -0500, Michael Santana wrote:
> GitHub is a service used by developers to store repositories. GitHub
> provides service integrations that allow 3rd party services to access
> developer repositories and perform actions. One of these services is
> Travis-CI, a simple continuous integration platform.
>
> This is a simple initial implementation of a travis build for the
> DPDK
> project. It doesn't require any changes from individual developers
> to
> enable, but will allow those developers who opt-in to GitHub and the
> travis service to get automatic builds for every push they make.
>
> Additionally, the travis service will send an email to the test-
> report
> list informing anyone interested in the automated build (including a
> result).
>
> Signed-off-by: Aaron Conole <aconole@redhat.com>
> Signed-off-by: Michael Santana <msantana@redhat.com>
> ---
> v6:
> Removed all classic make builds
>
> .ci/linux-build.sh | 21 +++++++++
> .ci/linux-setup.sh | 3 ++
> .travis.yml | 73
> +++++++++++++++++++++++++++++
> MAINTAINERS | 6 +++
> doc/guides/contributing/patches.rst | 4 ++
> 5 files changed, 107 insertions(+)
> create mode 100755 .ci/linux-build.sh
> create mode 100755 .ci/linux-setup.sh
> create mode 100644 .travis.yml
Acked-by: Luca Boccassi <bluca@debian.org>
On 3/4/19 1:14 PM, Luca Boccassi wrote:
> On Mon, 2019-03-04 at 11:12 -0500, Michael Santana wrote:
>> GitHub is a service used by developers to store repositories. GitHub
>> provides service integrations that allow 3rd party services to access
>> developer repositories and perform actions. One of these services is
>> Travis-CI, a simple continuous integration platform.
>>
>> This is a simple initial implementation of a travis build for the
>> DPDK
>> project. It doesn't require any changes from individual developers
>> to
>> enable, but will allow those developers who opt-in to GitHub and the
>> travis service to get automatic builds for every push they make.
>>
>> Additionally, the travis service will send an email to the test-
>> report
>> list informing anyone interested in the automated build (including a
>> result).
>>
>> Signed-off-by: Aaron Conole <aconole@redhat.com>
>> Signed-off-by: Michael Santana <msantana@redhat.com>
>> ---
>> v6:
>> Removed all classic make builds
>>
>> .ci/linux-build.sh | 21 +++++++++
>> .ci/linux-setup.sh | 3 ++
>> .travis.yml | 73
>> +++++++++++++++++++++++++++++
>> MAINTAINERS | 6 +++
>> doc/guides/contributing/patches.rst | 4 ++
>> 5 files changed, 107 insertions(+)
>> create mode 100755 .ci/linux-build.sh
>> create mode 100755 .ci/linux-setup.sh
>> create mode 100644 .travis.yml
> Acked-by: Luca Boccassi <bluca@debian.org>
>
ping
Hi,
04/03/2019 17:12, Michael Santana:
> .ci/linux-build.sh | 21 +++++++++
> .ci/linux-setup.sh | 3 ++
> .travis.yml | 73 +++++++++++++++++++++++++++++
Please, could you explain somewhere what is the relationship
between these files?
What is specific to Travis?
What is specific to GitHub?
May we add "travis-" as filename prefix of the scripts?
Or rename .ci to .travis?
> +++ b/.ci/linux-build.sh
> @@ -0,0 +1,21 @@
> +#!/bin/bash -xe
If possible, I would prefer a simple /bin/sh.
> +function on_error() {
> + FILES_TO_PRINT=( "build/meson-logs/testlog.txt" "build/.ninja_log" "build/meson-logs/meson-log.txt")
> +
> + for pr_file in "${FILES_TO_PRINT[@]}"; do
You can make FILES_TO_PRINT as a simple word list,
and so avoid bashism.
[...]
> +if [ "${AARCH64}" == "1" ]; then
Please explain in the comment where this variable comes from.
I suggest renaming it to ARMV8 as this is what it is translated to:
> + # convert the arch specifier
> + OPTS="${OPTS} -DRTE_ARCH_64=1 --cross-file config/arm/arm64_armv8_linuxapp_gcc"
I think -DRTE_ARCH_64=1 is useless.
> +fi
> +
> +OPTS="$OPTS --default-library=$DEF_LIB"
> +meson build --werror -Dexamples=all ${OPTS}
> +ninja -C build
[...]
> --- /dev/null
> +++ b/.travis.yml
> @@ -0,0 +1,73 @@
> +language: c
> +compiler:
> + - gcc
> + - clang
> +
> +dist: xenial
Are we going to update the distribution frequently?
Why not adding more distros?
> +os:
> + - linux
Is it possible to run on FreeBSD?
> +addons:
> + apt:
> + update: true
> + packages:
> + - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
> +
> +before_install: ./.ci/${TRAVIS_OS_NAME}-setup.sh
> +
> +sudo: false
> +
> +env:
> + - DEF_LIB="static"
> + - DEF_LIB="shared"
> + - DEF_LIB="static" OPTS="-Denable_kmods=false"
> + - DEF_LIB="shared" OPTS="-Denable_kmods=false"
How is it different of the matrix below?
Why testing disabling kmods?
> +
> +matrix:
> + include:
> + - env: DEF_LIB="static" OPTS="-Denable_kmods=false" AARCH64=1
> + compiler: gcc
> + addons:
> + apt:
> + packages:
> + - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
> + - [gcc-aarch64-linux-gnu, libc6-dev-arm64-cross]
Why packages are repeated here again?
(sorry, I don't know Travis and I want to understand)
> + - env: DEF_LIB="shared" OPTS="-Denable_kmods=false" AARCH64=1
> + compiler: gcc
> + addons:
> + apt:
> + packages:
> + - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
> + - [gcc-aarch64-linux-gnu, libc6-dev-arm64-cross]
> + - env: DEF_LIB="static"
> + compiler: gcc
> + addons:
> + apt:
> + packages:
> + - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
> + - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
> + - env: DEF_LIB="shared"
> + compiler: gcc
> + addons:
> + apt:
> + packages:
> + - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
> + - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
> + - env: DEF_LIB="static" OPTS="-Denable_kmods=false"
> + compiler: gcc
> + addons:
> + apt:
> + packages:
> + - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
> + - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
> + - env: DEF_LIB="shared" OPTS="-Denable_kmods=false"
> + compiler: gcc
> + addons:
> + apt:
> + packages:
> + - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
> + - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
It seems clang is not in the matrix. Why?
Thanks for this v6.
I will be available to follow more closely in next days,
so we can merge this feature soon this week.
Thank you for taking at look at this
On 3/20/19 12:01 PM, Thomas Monjalon wrote:
> Hi,
>
> 04/03/2019 17:12, Michael Santana:
>> .ci/linux-build.sh | 21 +++++++++
>> .ci/linux-setup.sh | 3 ++
>> .travis.yml | 73 +++++++++++++++++++++++++++++
> Please, could you explain somewhere what is the relationship
> between these files?
> What is specific to Travis?
> What is specific to GitHub?
>
> May we add "travis-" as filename prefix of the scripts?
> Or rename .ci to .travis?
Only the .travis.yml is specific to travis. The other two files are used
by travis, but are independent of travis.
This allows us for in the future to change travis as CI and use
something else instead, or add another CI in addition to travis if we
wanted to. Other CI's would just run these scripts just like travis does.
With that said, I would not change the names, but if you really think
they should then it's not a problem
>> +++ b/.ci/linux-build.sh
>> @@ -0,0 +1,21 @@
>> +#!/bin/bash -xe
> If possible, I would prefer a simple /bin/sh.
>
>> +function on_error() {
>> + FILES_TO_PRINT=( "build/meson-logs/testlog.txt" "build/.ninja_log" "build/meson-logs/meson-log.txt")
>> +
>> + for pr_file in "${FILES_TO_PRINT[@]}"; do
> You can make FILES_TO_PRINT as a simple word list,
> and so avoid bashism.
Will look into it
>
> [...]
>> +if [ "${AARCH64}" == "1" ]; then
> Please explain in the comment where this variable comes from.
> I suggest renaming it to ARMV8 as this is what it is translated to:
The variable comes from travis. If you look at the matrix in the
travis.yml you will see lines containing environment variables like
AARCH64=1.
These lines tell the travis build job to explicitly export these
variables so that they can be used by the CI scripts like this one.
As for ARMV8 someone had asked specifically to be named AARCH64
>
>> + # convert the arch specifier
>> + OPTS="${OPTS} -DRTE_ARCH_64=1 --cross-file config/arm/arm64_armv8_linuxapp_gcc"
> I think -DRTE_ARCH_64=1 is useless.
>
>> +fi
>> +
>> +OPTS="$OPTS --default-library=$DEF_LIB"
>> +meson build --werror -Dexamples=all ${OPTS}
>> +ninja -C build
> [...]
>> --- /dev/null
>> +++ b/.travis.yml
>> @@ -0,0 +1,73 @@
>> +language: c
>> +compiler:
>> + - gcc
>> + - clang
>> +
>> +dist: xenial
> Are we going to update the distribution frequently?
> Why not adding more distros?
The only Linux distribution travis supports is Ubuntu, and the latest
Ubuntu version they support is xenial which is code name for Ubuntu 16.04
>
>> +os:
>> + - linux
> Is it possible to run on FreeBSD?
Not that I am aware. Travis only supports Ubuntu, Windows, and Mac
>
>> +addons:
>> + apt:
>> + update: true
>> + packages:
>> + - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
>> +
>> +before_install: ./.ci/${TRAVIS_OS_NAME}-setup.sh
>> +
>> +sudo: false
>> +
>> +env:
>> + - DEF_LIB="static"
>> + - DEF_LIB="shared"
>> + - DEF_LIB="static" OPTS="-Denable_kmods=false"
>> + - DEF_LIB="shared" OPTS="-Denable_kmods=false"
> How is it different of the matrix below?
> Why testing disabling kmods?
This list inherits the packages from the package list above.
The main difference is that this list does not contain extra packages
such as libbsd-dev, libpcap-dev, etc, where as the matrix below does.
This is so that we have a series of builds with minimal libraries
installed (Minimal build) and another series of builds with many
libraries installed (Full build).
We want to mix and match all the possible build scenarios and see if a
new changes breaks any of the build cases.
The more builds we have with the many different configurations we can
have the wider the net we can cast to ensure everything is working as it
should
>
>> +
>> +matrix:
>> + include:
>> + - env: DEF_LIB="static" OPTS="-Denable_kmods=false" AARCH64=1
>> + compiler: gcc
>> + addons:
>> + apt:
>> + packages:
>> + - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
>> + - [gcc-aarch64-linux-gnu, libc6-dev-arm64-cross]
> Why packages are repeated here again?
> (sorry, I don't know Travis and I want to understand)
Yeah, we don't want to repeat ourselves either but we have no choice.
This is due to a limitation in travis.
This matrix does not inherit any packages from the main package list way
above, which means we have to list them out manually here.
In addition to the required packages we also want to install full builds
with libraries like libbsd-dev, libpcap-dev, etc.
We could of just put those libraries in the main package list above and
put all the builds in the env: list because then the libraries would be
inherited.
The problem with that is that is that travis would not keep minimal
builds and full builds separate.
We could not have minimal builds because the minimal builds will also
inherit the additional libraries; Meson will then automatically detect
those additional libraries and builds with them.
What we would like to have is a way to tell meson which libraries we
want to use and which we dont, instead of being auto-detected. This
would help us to get rid of this matrix.
If someone knows a better way to do this we would greatly take in your
ideas, but so far this is the best we could come up with
>
>> + - env: DEF_LIB="shared" OPTS="-Denable_kmods=false" AARCH64=1
>> + compiler: gcc
>> + addons:
>> + apt:
>> + packages:
>> + - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
>> + - [gcc-aarch64-linux-gnu, libc6-dev-arm64-cross]
>> + - env: DEF_LIB="static"
>> + compiler: gcc
>> + addons:
>> + apt:
>> + packages:
>> + - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
>> + - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
>> + - env: DEF_LIB="shared"
>> + compiler: gcc
>> + addons:
>> + apt:
>> + packages:
>> + - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
>> + - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
>> + - env: DEF_LIB="static" OPTS="-Denable_kmods=false"
>> + compiler: gcc
>> + addons:
>> + apt:
>> + packages:
>> + - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
>> + - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
>> + - env: DEF_LIB="shared" OPTS="-Denable_kmods=false"
>> + compiler: gcc
>> + addons:
>> + apt:
>> + packages:
>> + - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
>> + - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
> It seems clang is not in the matrix. Why?
It looks like my mistake, will look into it
>
> Thanks for this v6.
> I will be available to follow more closely in next days,
> so we can merge this feature soon this week.
>
>
On Wed, 2019-03-20 at 15:28 -0400, Michael Santana Francisco wrote:
> > > +matrix:
> > > + include:
> > > + - env: DEF_LIB="static" OPTS="-Denable_kmods=false" AARCH64=1
> > > + compiler: gcc
> > > + addons:
> > > + apt:
> > > + packages:
> > > + - [libnuma-dev, linux-headers-$(uname -r), python3-
> > > setuptools, python3-wheel, python3-pip, ninja-build]
> > > + - [gcc-aarch64-linux-gnu, libc6-dev-arm64-cross]
> > Why packages are repeated here again?
> > (sorry, I don't know Travis and I want to understand)
> Yeah, we don't want to repeat ourselves either but we have no
> choice.
> This is due to a limitation in travis.
> This matrix does not inherit any packages from the main package list
> way
> above, which means we have to list them out manually here.
> In addition to the required packages we also want to install full
> builds
> with libraries like libbsd-dev, libpcap-dev, etc.
> We could of just put those libraries in the main package list above
> and
> put all the builds in the env: list because then the libraries would
> be
> inherited.
> The problem with that is that is that travis would not keep minimal
> builds and full builds separate.
> We could not have minimal builds because the minimal builds will
> also
> inherit the additional libraries; Meson will then automatically
> detect
> those additional libraries and builds with them.
> What we would like to have is a way to tell meson which libraries we
> want to use and which we dont, instead of being auto-detected. This
> would help us to get rid of this matrix.
>
> If someone knows a better way to do this we would greatly take in
> your
> ideas, but so far this is the best we could come up with
It's yaml so you can write the list to a variable once and reference it
multiple times for brevity, see for example:
https://github.com/zeromq/czmq/blob/master/.travis.yml#L128
On 3/20/19 5:11 PM, Luca Boccassi wrote:
> On Wed, 2019-03-20 at 15:28 -0400, Michael Santana Francisco wrote:
>>>> +matrix:
>>>> + include:
>>>> + - env: DEF_LIB="static" OPTS="-Denable_kmods=false" AARCH64=1
>>>> + compiler: gcc
>>>> + addons:
>>>> + apt:
>>>> + packages:
>>>> + - [libnuma-dev, linux-headers-$(uname -r), python3-
>>>> setuptools, python3-wheel, python3-pip, ninja-build]
>>>> + - [gcc-aarch64-linux-gnu, libc6-dev-arm64-cross]
>>> Why packages are repeated here again?
>>> (sorry, I don't know Travis and I want to understand)
>> Yeah, we don't want to repeat ourselves either but we have no
>> choice.
>> This is due to a limitation in travis.
>> This matrix does not inherit any packages from the main package list
>> way
>> above, which means we have to list them out manually here.
>> In addition to the required packages we also want to install full
>> builds
>> with libraries like libbsd-dev, libpcap-dev, etc.
>> We could of just put those libraries in the main package list above
>> and
>> put all the builds in the env: list because then the libraries would
>> be
>> inherited.
>> The problem with that is that is that travis would not keep minimal
>> builds and full builds separate.
>> We could not have minimal builds because the minimal builds will
>> also
>> inherit the additional libraries; Meson will then automatically
>> detect
>> those additional libraries and builds with them.
>> What we would like to have is a way to tell meson which libraries we
>> want to use and which we dont, instead of being auto-detected. This
>> would help us to get rid of this matrix.
>>
>> If someone knows a better way to do this we would greatly take in
>> your
>> ideas, but so far this is the best we could come up with
> It's yaml so you can write the list to a variable once and reference it
> multiple times for brevity, see for example:
>
> https://github.com/zeromq/czmq/blob/master/.travis.yml#L128
>
Thank you Luca!
I had previously tested this approach and then it wasn't working the way
I was hoping it would.
I just finished testing it again and it seems to be working correctly
this time!
I got it working with the required packages in one list and use a
variable to reference to that list.
Next I will see about having a list for extra packages, and another for
ARM packages
Again, thank you! Will work on it
new file mode 100755
@@ -0,0 +1,21 @@
+#!/bin/bash -xe
+
+function on_error() {
+ FILES_TO_PRINT=( "build/meson-logs/testlog.txt" "build/.ninja_log" "build/meson-logs/meson-log.txt")
+
+ for pr_file in "${FILES_TO_PRINT[@]}"; do
+ if [ -e "$pr_file" ]; then
+ cat "$pr_file"
+ fi
+ done
+}
+trap on_error ERR
+
+if [ "${AARCH64}" == "1" ]; then
+ # convert the arch specifier
+ OPTS="${OPTS} -DRTE_ARCH_64=1 --cross-file config/arm/arm64_armv8_linuxapp_gcc"
+fi
+
+OPTS="$OPTS --default-library=$DEF_LIB"
+meson build --werror -Dexamples=all ${OPTS}
+ninja -C build
new file mode 100755
@@ -0,0 +1,3 @@
+ #!/bin/bash
+
+python3 -m pip install --upgrade meson --user
new file mode 100644
@@ -0,0 +1,73 @@
+language: c
+compiler:
+ - gcc
+ - clang
+
+dist: xenial
+
+os:
+ - linux
+
+addons:
+ apt:
+ update: true
+ packages:
+ - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
+
+before_install: ./.ci/${TRAVIS_OS_NAME}-setup.sh
+
+sudo: false
+
+env:
+ - DEF_LIB="static"
+ - DEF_LIB="shared"
+ - DEF_LIB="static" OPTS="-Denable_kmods=false"
+ - DEF_LIB="shared" OPTS="-Denable_kmods=false"
+
+matrix:
+ include:
+ - env: DEF_LIB="static" OPTS="-Denable_kmods=false" AARCH64=1
+ compiler: gcc
+ addons:
+ apt:
+ packages:
+ - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
+ - [gcc-aarch64-linux-gnu, libc6-dev-arm64-cross]
+ - env: DEF_LIB="shared" OPTS="-Denable_kmods=false" AARCH64=1
+ compiler: gcc
+ addons:
+ apt:
+ packages:
+ - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
+ - [gcc-aarch64-linux-gnu, libc6-dev-arm64-cross]
+ - env: DEF_LIB="static"
+ compiler: gcc
+ addons:
+ apt:
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
+ - env: DEF_LIB="shared"
+ compiler: gcc
+ addons:
+ apt:
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
+ - env: DEF_LIB="static" OPTS="-Denable_kmods=false"
+ compiler: gcc
+ addons:
+ apt:
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
+ - env: DEF_LIB="shared" OPTS="-Denable_kmods=false"
+ compiler: gcc
+ addons:
+ apt:
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
+
+
+script: ./.ci/${TRAVIS_OS_NAME}-build.sh
@@ -119,6 +119,12 @@ F: config/rte_config.h
F: buildtools/gen-pmdinfo-cfile.sh
F: buildtools/symlink-drivers-solibs.sh
+Public CI
+M: Aaron Conole <aconole@redhat.com>
+M: Michael Santana <msantana@redhat.com>
+F: .travis.yml
+F: .ci/
+
ABI versioning
M: Neil Horman <nhorman@tuxdriver.com>
F: doc/guides/rel_notes/deprecation.rst
@@ -32,6 +32,10 @@ The mailing list for DPDK development is `dev@dpdk.org <http://mails.dpdk.org/ar
Contributors will need to `register for the mailing list <http://mails.dpdk.org/listinfo/dev>`_ in order to submit patches.
It is also worth registering for the DPDK `Patchwork <http://patches.dpdk.org/project/dpdk/list/>`_
+If you are using the GitHub service, you can link your repository to
+the ``travis-ci.org`` build service. When you push patches to your GitHub
+repository, the travis service will automatically build your changes.
+
The development process requires some familiarity with the ``git`` version control system.
Refer to the `Pro Git Book <http://www.git-scm.com/book/>`_ for further information.