Xilinx maintains a public Git tree for each of its open source projects.  This page will give you the information you need to start using those trees.

Git Documentation

The Git project is exquisitely documented. The online Git book is a must-read for any new user. You can find that documentation on Git's homepage here:  http://git-scm.com/documentation.

Github provides an interactive tutorial here.

Installing Git

Binaries for all common operating systems and sources can be downloaded from the Git homepage. Alternatively your distribution may provide packages through its packet manager.
On Ubuntu, Git can be installed through

Or, on Fedora run

Or, on OpenSUSE

Git Repository Conventions

The repository system is divided into server/repository/branch. Each branch is designed to serve a particular community of interest. The community contains developers and testers. Interest is based on the needs of the group members. Device driver developers, for example, will be most interested in the latest development branch. Developers of user software and TRDs will want something that is more tested. This document should help you understand what branch you should be using for your work. It will also tell you how that branch will change over time.

Branch Types

To pursue a common language to describe branches this document specifies type names that will help users distinguish between the branches in a repository. The type names will help indicate what community your work belongs to. The graphic shows the relationship between branch types.

Development

A development branch is an integration area for a team of developers. Developers commit new code for features and bug fixes into development branches. The intended audience is developers. Development branch may have bugs but are expected to work. Since the development branch is the leading branch it's best to use it if you are interested in adding new work to the project.

Stable

Stable branches are snapshots in time of development branches that are taken when the development branch is considered good. The intended audience of a stable branch is broader than the development branch. The stable branch should be used by those seeking cutting edge source who have projects that need good quality code. The stable repository exists to promote testing in a broader community with broader applications.

Release

Release branches are snapshots in time of stable branches. Release branches represent Xilinx's best effort to provide high quality software. Release branches have the largest possible audience and are the place where most people should seek source from.

Purpose

These branches belong to teams or individuals and are not managed explicitly in this system. While the main branches will march from development to release, purpose branches are not required to. In order for code developed in a purpose repository to be released it must be integrated into a development repository and go through the testing process. This work is left to the owner of the purpose branch.

Xilinx Git Trees

Xilinx's Git trees can be browsed at https://github.com/Xilinx. The two primary projects covered on this wiki are Linux and U-boot. Those projects contain two branches each.

master Branch

The master branch is the name for the development branch. This branch is updated on a continuous basis. For stability reasons the software version in master may not be the "latest and greatest" in the upstream projects. If you want to use the stable version please checkout appropriate tag.

PetaLinux Branches

PetaLinux is Xilinx's commercial Linux distribution. If all of this talk about Git has made your head hurt, it's best you take a look at PetaLinux. PetaLinux makes it easy to use Linux on Xilinx technology and can be found on the web here. The PetaLinux branches are release branches. There is one PetaLinux branch for each release of PetaLinux.

Tags

Git tags are a way to name a branch at a particular place in time. At Xilinx we tag the master branch each time a CAD software release is done. The tags correspond to the name of the CAD release. This is helpful for recreating instructions that came with the Xilinx software you are using. Say, for example, you are using an older version of the tools and you want to get the kernel that was released alongside that version; you would get the kernel with a tag that matched your release version.

Fetching Source via HTTP

You don't need to have Git installed to get the source. If you would like the source of a snapshot as a zip file you can find direct download links on https://github.com/Xilinx

Fetching Source with Git

Fetching the whole source repository transfers the entire state of the project to your computer. Once complete you have all the source and complete history of the project. This requires much more bandwidth than a snapshot but is crucial for developers to be able to work. In most cases you will be able to get our Linux kernel by simply doing this:
You may run into issues if (like many of us) you're behind a corporate firewall. In that case you can try to fetch the sources using the http:// protocol.
If neither git:// nor http:// works, you may have to use a proxy to access an external Git server (see next section).

Using Git through a Proxy

Corporate firewalls typically block the port that Git uses. Since many open source software developers work for a corporation Git has been designed to be easily proxied.

System level or git application level http_proxy can be used to fetch repositories on the remote server. This is an example of setting git application level http proxy which overides system http_proxy environment variable:
For more info about Git proxy, please refer to the git-config document.

Alternatively, when the Git git program sees that the environment variable GIT_PROXY_COMMAND is set it will make no attempt to communicate with the remote server. Instead it will launch the command in that variable and use that program's STDIN and STDOUT instead of a network socket. Programs like Netcat and Corkscrew can help Git with your proxy.

Example:

Place the following code into a script (be sure to make the script executable).
Now set the GIT_PROXY_COMMAND to point to your script:

Creating and Submitting A Git Patch

Instructions on how to create and submit a patch are here.