The {{pkg|git}} package comes with a Bash completion file. This file also contains the necessary functions to provide Git information on your Bash or zsh shell prompt. To enable it add {{Ic|$(__git_ps1 " (%s)")}} to you PS1 variable.

The real power and convenience in Git (and other distributed version control systems) come from leveraging its local commits and fast branching.

+

A typical Git workflow looks like this:

+

+

# Create and check out a branch to add a feature.

+

# Make as many commits as you would like on that branch while developing that feature.

+

# Squash, rearrange, and edit your commits until you are satisfied with the commits enough to push them to the central server and make them public.

+

# Merge your branch back into the main branch.

+

# Delete your branch, if you desire.

+

# Push your changes to the central server.

+

+

===创建一个分支===

+

+

git branch <branch name>

+

+

can be used to create a branch that will branch off the current commit.

+

After it has been created, you should switch to it using

+

+

git checkout <branch name>

+

+

A simpler method is to do both in one step with

+

+

git checkout -b <branch name>

+

+

To see a list of branches, and which branch is currently checked out, use

+

+

git branch

+

+

===A word on commits===

+

+

Many of the following commands take commits as arguments. A commit can be identified by any of the following:

+

+

* Its 40-digit SHA-1 hash (the first 7 digits are usually sufficient to identify it uniquely)

+

* Any commit label such as a branch or tag name

+

* The label {{ic|HEAD}} always refers to the currently checked-out commit (usually the head of the branch, unless you used {{ic|git checkout}} to jump back in history to an old commit)

+

* Any of the above plus {{ic|~}} to refer to previous commits. For example, {{ic|HEAD~}} refers to one commit before {{ic|HEAD}} and {{ic|HEAD~5}} refers to five commits before {{ic|HEAD}}.

+

+

===提交为检查点===

+

+

In Subversion and other older, centralized version control systems, commits are permanent - once you make them,

+

they are there on the server for everyone to see.

+

In Git, your commits are local and you can combine, rearrange, and edit them before pushing them to the server.

+

This gives you more flexibility and lets you use commits as checkpoints. Commit early and commit often.

+

+

===编辑之前的提交===

+

+

git commit --amend

+

+

allows you to modify the previous commit. The contents of the index will be applied to it,

+

allowing you to add more files or changes you forgot to put in. You can also use it to edit the commit message,

+

if you would like.

+

+

===插入、重新排序和更改历史记录===

+

+

git rebase -i <commit>

+

+

will bring up a list of all commits between {{ic|<commit>}} and the present, including {{ic|HEAD}} but excluding {{ic|<commit>}}.

+

This command allows you rewrite history. To the left of each commit, a command is specified.

+

Your options are as follows:

+

+

* The "pick" command (the default) uses that commit in the rewritten history.

+

* The "reword" command lets you change a commit message without changing the commit's contents.

+

* The "edit" command will cause Git to pause during the history rewrite at this commit. You can then modify it with {{ic|git commit --amend}} or insert new commits.

+

* The "squash" command will cause a commit to be folded into the previous one. You will be prompted to enter a message for the combined commit.

+

* The "fixup" command works like squash, but discards the message of the commit being squashed instead of prompting for a new message.

+

* Commits can be erased from history by deleting them from the list of commits

+

* Commits can be re-ordered by re-ordering them in the list. When you are done modifying the list, Git will prompt you to resolve any resulting merge problems (after doing so, continue rebasing with {{ic|git rebase --continue}})

+

+

When you are done modifying the list, Git will perform the desired actions.

+

If Git stops at a commit (due to merge conflicts caused by re-ordering the commits or due to the "edit" command),

+

use {{ic|git rebase --continue}} to resume. You can always back out of the rebase operation with {{ic|git rebase --abort}}.

+

+

{{warning|Only use {{ic|git rebase -i}} on local commits that have not yet been pushed to anybody else.

+

Modifying commits that are on the central server will cause merge problems for obvious reasons.}}

+

+

{{note|Vim makes these rebase operations very simple since lines can be cut and pasted with few keystrokes.}}

+

+

==Git提示符==

+

The Git package comes with a prompt script. To enable the prompt addition you will need to source the git-prompt.sh script and add {{Ic|$(__git_ps1 " (%s)")}} to you PS1 variable.

The {{Ic|%s}} is replaced by the current branch name. The Git information is displayed only if you are navigating in a Git repository. You can enable extra information by setting and exporting certain variables to a non-empty value as shown in the following table:

+

The {{Ic|%s}} is replaced by the current branch name. The git information is displayed only if you are navigating in a git repository. You can enable extra information by setting and exporting certain variables to a non-empty value as shown in the following table:

{| border="1"

{| border="1"

Line 97:

Line 241:

|}

|}

−

In addition you can set the {{Ic|GIT_PS1_SHOWUPSTREAM}} variable to {{Ic|"auto"}} in order to see {{Ic|'''<'''}} if you are behind upstream, {{Ic|'''>'''}} if you are ahead and {{Ic|'''<>'''}} if you have diverged.

+

==传输协议==

−

+

===智能HTTP===

−

{{Note|If you do not use Bash completion consider sourcing {{ic|/usr/share/git/completion/git-completion.bash}} in your {{ic|~/.bashrc}}/{{ic|~/.zshrc}}.}}

+

Since version 1.6.6 git is able to use the HTTP(S) protocol as efficiently as SSH or Git by utilizing the git-http-backend. Furthermore it is not only possible to clone or pull from repositories, but also to push into repositories over HTTP(S).

−

−

==Transfer Protocols==

−

===Smart HTTP===

−

Since version 1.6.6 git is able to use the HTTP(S) protocol as efficiently as SSH or GIT by utilizing the git-http-backend. Furthermore it is not only possible to clone or pull from repositories, but also to push into repositories over HTTP(S).

−

The setup for this is rather simple as all you need to have installed is the Apache webserver (with mod_cgi, mod_alias, and mod_env enabled) and of course, git:

+

The setup for this is rather simple as all you need to have installed is the Apache web server (with mod_cgi, mod_alias, and mod_env enabled) and of course, git:

You first need to have a public SSH key. For that follow the guide at [[Using SSH Keys]]. To setup SSH itself you need to follow the [[SSH]] guide. I assume you have a public SSH key now and your SSH is working.

+

You first need to have a public SSH key. For that follow the guide at [[Using SSH Keys]]. To set up SSH itself, you need to follow the [[SSH]] guide. This assumes you have a public SSH key now and that your SSH is working.

−

Open your SSH key in your favorite editor (default public key name is id_rsa.pub and is located in {{ic|~/.ssh}}) and copy its content (CTRL + C).

+

Open your SSH key in your favorite editor (default public key name is {{ic|~/.ssh/id_rsa.pub}}), and copy its content ({{ic|Ctrl+c}}).

−

Now go to your user where you have made your git repository, since we now need to allow that SSH key to login on that user to access the GIT repository.

+

Now go to your user where you have made your Git repository, since we now need to allow that SSH key to log in on that user to access the Git repository.

−

Open this file in your favorite editor (i use nano)

+

Open {{ic|~/.ssh/authorized_keys}} in your favorite editor, and paste the contents of id_rsa.pub in it. Be sure it is all on one line! That is important! It should look somewhat like this:

−

nano ~/.ssh/authorized_keys

−

and paste the contents of id_rsa.pub in it. Be sure it is all on one line! That is important! It should look somewhat like this:

{{Warning|Do not copy the line below! It is an example! It will not work if you use that line!}}

{{Warning|Do not copy the line below! It is an example! It will not work if you use that line!}}

Now you can checkout your git repo this way (change where needed. Here it is using the git username and localhost):

+

Now you can checkout your Git repository this way (change where needed. Here it is using the git username and localhost):

git clone git@localhost:my_repository.git

git clone git@localhost:my_repository.git

−

You should now get an SSH yes/no question. Type yes followed by enter. Then you should have your repository checked out. Since this is with SSH you also do have commit rights now. For that look at [[Git]] and [[Super Quick Git Guide]].

+

You should now get an SSH yes/no question. Type {{ic|yes}} followed by {{ic|Enter}}. Then you should have your repository checked out. Because this is with SSH, you also do have commit rights now. For that look at [[Git]] and [[Super Quick Git Guide]].

−

====Specifying a non-standard port====

+

====特定非标准端口====

−

Connecting on a port other than 22 can be configured on a per-host basis in {{ic|/etc/ssh/ssh_config}} or {{ic|~/.ssh/config}}. To set up ports for a repository, specify the path in {{ic|.git/config}} using the port number ''N'' and the '''absolute path''' ''/PATH/TO/REPO'':

+

Connecting on a port other than 22 can be configured on a per-host basis in {{ic|/etc/ssh/ssh_config}} or {{ic|~/.ssh/config}}. To set up ports for a repository, specify the path in {{ic|.git/config}} using the port number {{ic|N}} and the ''absolute path'' {{ic|/PATH/TO/REPO}}:

ssh://user@example.org:N/PATH/TO/REPO

ssh://user@example.org:N/PATH/TO/REPO

Typically the repository resides in the home directory of the user which allows you to use tilde-expansion. Thus to connect on port N=443,

Typically the repository resides in the home directory of the user which allows you to use tilde-expansion. Thus to connect on port N=443,

使用分布式版本控制系统

The above commands only provide the basics.
The real power and convenience in Git (and other distributed version control systems) come from leveraging its local commits and fast branching.
A typical Git workflow looks like this:

Create and check out a branch to add a feature.

Make as many commits as you would like on that branch while developing that feature.

Squash, rearrange, and edit your commits until you are satisfied with the commits enough to push them to the central server and make them public.

Merge your branch back into the main branch.

Delete your branch, if you desire.

Push your changes to the central server.

创建一个分支

git branch <branch name>

can be used to create a branch that will branch off the current commit.
After it has been created, you should switch to it using

git checkout <branch name>

A simpler method is to do both in one step with

git checkout -b <branch name>

To see a list of branches, and which branch is currently checked out, use

git branch

A word on commits

Many of the following commands take commits as arguments. A commit can be identified by any of the following:

Its 40-digit SHA-1 hash (the first 7 digits are usually sufficient to identify it uniquely)

Any commit label such as a branch or tag name

The label HEAD always refers to the currently checked-out commit (usually the head of the branch, unless you used git checkout to jump back in history to an old commit)

Any of the above plus ~ to refer to previous commits. For example, HEAD~ refers to one commit before HEAD and HEAD~5 refers to five commits before HEAD.

提交为检查点

In Subversion and other older, centralized version control systems, commits are permanent - once you make them,
they are there on the server for everyone to see.
In Git, your commits are local and you can combine, rearrange, and edit them before pushing them to the server.
This gives you more flexibility and lets you use commits as checkpoints. Commit early and commit often.

编辑之前的提交

git commit --amend

allows you to modify the previous commit. The contents of the index will be applied to it,
allowing you to add more files or changes you forgot to put in. You can also use it to edit the commit message,
if you would like.

插入、重新排序和更改历史记录

git rebase -i <commit>

will bring up a list of all commits between <commit> and the present, including HEAD but excluding <commit>.
This command allows you rewrite history. To the left of each commit, a command is specified.
Your options are as follows:

The "pick" command (the default) uses that commit in the rewritten history.

The "reword" command lets you change a commit message without changing the commit's contents.

The "edit" command will cause Git to pause during the history rewrite at this commit. You can then modify it with git commit --amend or insert new commits.

The "squash" command will cause a commit to be folded into the previous one. You will be prompted to enter a message for the combined commit.

The "fixup" command works like squash, but discards the message of the commit being squashed instead of prompting for a new message.

Commits can be erased from history by deleting them from the list of commits

Commits can be re-ordered by re-ordering them in the list. When you are done modifying the list, Git will prompt you to resolve any resulting merge problems (after doing so, continue rebasing with git rebase --continue)

When you are done modifying the list, Git will perform the desired actions.
If Git stops at a commit (due to merge conflicts caused by re-ordering the commits or due to the "edit" command),
use git rebase --continue to resume. You can always back out of the rebase operation with git rebase --abort.

Warning: Only use git rebase -i on local commits that have not yet been pushed to anybody else.
Modifying commits that are on the central server will cause merge problems for obvious reasons.

Note: Vim makes these rebase operations very simple since lines can be cut and pasted with few keystrokes.

Git提示符

The Git package comes with a prompt script. To enable the prompt addition you will need to source the git-prompt.sh script and add $(__git_ps1 " (%s)") to you PS1 variable.

The %s is replaced by the current branch name. The git information is displayed only if you are navigating in a git repository. You can enable extra information by setting and exporting certain variables to a non-empty value as shown in the following table:

Variable

Information

GIT_PS1_SHOWDIRTYSTATE

* for unstaged and + for staged changes

GIT_PS1_SHOWSTASHSTATE

$ if something is stashed

GIT_PS1_SHOWUNTRACKEDFILES

% if there are untracked files

传输协议

智能HTTP

Since version 1.6.6 git is able to use the HTTP(S) protocol as efficiently as SSH or Git by utilizing the git-http-backend. Furthermore it is not only possible to clone or pull from repositories, but also to push into repositories over HTTP(S).

The setup for this is rather simple as all you need to have installed is the Apache web server (with mod_cgi, mod_alias, and mod_env enabled) and of course, git:

# pacman -S apache git

Once you have your basic setup up and running, add the following to your Apache's config usually located at /etc/httpd/conf/httpd.conf:

The above example config assumes that your git repositories are located at /srv/git and that you want to access them via something like http(s)://your_address.tld/git/your_repo.git. Feel free to customize this to your needs.

Note: Of course you have to make sure that your Apache can read and write (if you want to enable push access) on your git repositories.

Git SSH

You first need to have a public SSH key. For that follow the guide at Using SSH Keys. To set up SSH itself, you need to follow the SSH guide. This assumes you have a public SSH key now and that your SSH is working.
Open your SSH key in your favorite editor (default public key name is ~/.ssh/id_rsa.pub), and copy its content (Ctrl+c).
Now go to your user where you have made your Git repository, since we now need to allow that SSH key to log in on that user to access the Git repository.
Open ~/.ssh/authorized_keys in your favorite editor, and paste the contents of id_rsa.pub in it. Be sure it is all on one line! That is important! It should look somewhat like this:

Warning: Do not copy the line below! It is an example! It will not work if you use that line!

Now you can checkout your Git repository this way (change where needed. Here it is using the git username and localhost):

git clone git@localhost:my_repository.git

You should now get an SSH yes/no question. Type yes followed by Enter. Then you should have your repository checked out. Because this is with SSH, you also do have commit rights now. For that look at Git and Super Quick Git Guide.

特定非标准端口

Connecting on a port other than 22 can be configured on a per-host basis in /etc/ssh/ssh_config or ~/.ssh/config. To set up ports for a repository, specify the path in .git/config using the port number N and the absolute path/PATH/TO/REPO: