|
작성일 : 13-04-19 23:21
|
git install 하기(xilinx 에서 퍼옴)
|
 |
|
글쓴이 :
이로직…
 조회 : 6,418
|
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. 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
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
apt-get install git git-email
Or, on Fedora run
yum install git git-email
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 http://git.xilinx.com. 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 stable branch. The master branch is updated at the same time as the Xilinx CAD tools, four times per year. There may be exceptions when a bug is found that needs to be fixed outside of the normal release window.
master-next Branch
The master-next branch is the name for the development branch. This branch is updated on a continuous basis. The version of software in the master-next branch is usually newer than the one in master. Though, for stability reasons the software version in master-next may not be the "latest and greatest" in the upstream projects.
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 http://git.xilinx.com
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:
git clone git://git.xilinx.com/linux-xlnx.git
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.
git clone http://git.xilinx.com/linux-xlnx.git
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. 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).
#! /bin/bash
exec nc -5 -S : $*
Now set the GIT_PROXY_COMMAND to point to your script:
$ export GIT_PROXY_COMMAND=
$ git clone git://git.xilinx.com/linux-xlnx.git
Creating A Git Patch
1. Make a branch in the repository for the change you desire which is based on one of the original branches in the repository you cloned. This command creates the branch and makes it the active branch. Unless you plan to provide a hot-fix for a current release or stable version you should use the development branch (master-next) as base for your patch.
git checkout –b
Make the changes to any files or add new files and do your testing.
2. Set your email and your name for commit messages. Git creates a .gitconfig file in the directory specified by the HOME environment variable such that this only has to be done once.
git config --global user.email johndoe@example.com
git config --global user.name 'John Doe'
3. Add any modified files to your patch.
git add
4. Review the changes that will be committed on the next commit command. In case something is wrong, like adding a wrong file, git status also provides hints on how to resolve issues.
git status
5. Commit the files that were changed and added into your local branch of your local repository. A commit should be done when a change is ready to be put in the repository. Keep the granularity of each commit small (a single functional change) as each commit will become a separate patch.
git commit --signoff
You will be put into an editor to enter your commit message. There is a specific format that should be followed and illustrated below.
In the following text, “[ ]” denotes a required field and “< >” is an optional field.
[system]: [subsystem]: : [short summary]
blank line
Several lines: describing the specifics of the change
blank line
Signed-off-by: [your name] [<youremail@somewhere.com>]
Where:
system = powerpc, microblaze, arm
subsystem = zynq
descriptor = the driver name, BSP, etc…
short summary = a short text summary of the change
Signed-off-by is the person making change (commit). This line is created automatically if the --signoff option is passed to 'git commit' and uses the identity configured in your .gitconfig.
Examine other commit messages to get an idea what may be appropriate values for the commit message fields of your patch.
git log
6. Review the last commit.
git show
7. Generate patches for each commit in your branch. A patch file, named *.patch, is generated in the current directory. The following command generates a patch for each commit your commits.
git format-patch
8. Send the email patch to git@xilinx.com for review and incorporation back into the Git tree. Using Git to send the email will ensure that it’s format is not altered by email clients such as Outlook.
git send-email --to git@xilinx.com *.patch
|
|
|
|
