Git 使用简明手册

Git是一款免费、开源的分布式版本控制系统,用于敏捷高效地处理任何或小或大的项目。版本控制(Revision control)是一种软件工程技巧,籍以在开发的过程中,确保由不同人所编辑的同一档案都得到更新。

Git 基本原理简介

数据索引

用户在将工作保存到 Git 之前,所有数据都要进行内容的校验和(checksum)计算,并将此结果作为数据的唯一标识和索引。换句话说,不可能在你修改了文件或目录之后,Git 一无所知。这项特性作为 Git 的设计哲学,建在整体架构的最底层。所以如果文件在传输时变得不完整,或者磁盘损坏导致文件数据缺失,Git 都能立即察觉。

Git 使用 SHA-1 算法计算数据的校验和,通过对文件的内容或目录的结构计算出一个 SHA-1 哈希值,作为指纹字符串。该字串由 40 个十六进制字符(0-9 及 a-f)组成,看起来就像是:

24b9da6552252987aa493b52f8696cd6d3b00373

Git 的工作完全依赖于这类指纹字串,所以你会经常看到这样的哈希值。实际上,所有保存在 Git 数据库中的东西都是用此哈希值来作索引的,而不是靠文件名。

三种状态

对于任何一个文件,在 Git 内都只有三种状态:已修改(modified),已暂存(staged)和已提交(committed)。

  • 已修改表示修改了某个文件,但还没有提交保存;
  • 已暂存表示把已修改的文件放在下次提交时要保存的清单中。
  • 已提交表示该文件已经被安全地保存在本地数据库中了;

由此我们看到 Git 管理项目时,文件流转的三个工作区域:工作目录,暂存区域以及 Git 的本地数据目录(.git目录)。

每个项目都有一个 git 目录,它是 Git 用来保存元数据和对象数据库的地方。该目录非常重要,每次克隆镜像仓库的时候,实际拷贝的就是这个目录里面的数据。从项目中取出某个版本的所有文件和目录,用以开始后续工作的叫做工作目录。这些文件实际上都是从 git 目录中的压缩对象数据库中提取出来的,接下来就可以在工作目录中对这些文件进行编辑。所谓的暂存区域只不过是个简单的文件,一般都放在 git 目录中。有时候人们会把这个文件叫做索引文件,不过标准说法还是叫暂存区域。

一个基本的 Git 工作流程如下所示:

  • 1、在工作目录中修改某些文件。
  • 2、对这些修改了的文件作快照,并保存到暂存区域。
  • 3、提交更新,将保存在暂存区域的文件快照转储到 git 目录中。

所以,我们可以从文件所处的位置来判断状态:如果是 git 目录中保存着的特定版本文件,就属于已提交状态;如果作了修改并已放入暂存区域,就属于已暂存状态;如果自上次取出后,作了修改但还没有放到暂存区域,就是已修改状态。

基本使用方法

初次使用前的配置

在首次安装完 git 并使用时,需要对其做一些配置,亦即定制自己的 Git 环境。每台计算机上只需要配置一次,程序升级时会保留配置信息。Git 自带一个 git config 的工具来帮助设置控制 Git 外观和行为的配置变量。 这些变量存储在三个不同的位置:

  • 1、/etc/gitconfig 文件: 包含系统上每一个用户及他们仓库的通用配置。 如果使用带有 --system 选项的 git config 时,它会从此文件读写配置变量。

  • 2、~/.gitconfig~/.config/git/config 文件:只针对当前用户。 可以传递 --global 选项让 Git 读写此文件。

  • 3、当前使用仓库的 Git 目录中的 config 文件(就是 .git/config):针对该仓库。

每一个级别覆盖上一级别的配置,所以 .git/config 的配置变量会覆盖 /etc/gitconfig 中的配置变量。

配置用户信息

在初次使用 git 时,需要先配置用户信息,即告诉 git 你的名字和邮箱地址。否则在之后的使用过程中,git 也会提示你进行配置。配置方法如下:

$ git config --global user.name “Your Name”

$ git config --global user.email “you@example.com”

配置文本编辑器

当 Git 需要用户输入信息时会调用文本编辑器。如果没有自己配置,则会使用操作系统默认的文本编辑器,通常是 Nano 或者 Vim。如果不想使用默认的文本编辑器,则可以重新配置:

git config --global core.editor vim

检查配置信息

如果想要检查你的配置,可以使用 git config --list 命令来列出所有 Git 能找到的配置:

git config --list

当然,还可以通过输入 git config <key> 来检查 Git 的某一项配置:

git config user.name

获取帮助

大部分人的记忆力应该都不是太好的,很多东西即使记住了,长时间不用也会忘记。如果不清楚或者忘记的 git 的用法,在 Linux 下可以通过命令来获取帮助。有三种方法可以找到 Git 命令的使用手册:

git help <verb>

git <verb> --help

man git-<verb>

例如,要想获得 config 命令的手册,执行

git help config

创建项目仓库

要用 git 来管理项目,首先需要在项目目录中初始化一个仓库:

git init

以上命令需要进入项目目录,不进入项目目录也可以初始化:

git init <项目目录>

这样,如果项目目录存在则会在项目目录中会创建一个 .git 的隐藏目录,如果不存在则会先创建。该目录的结构如下所示:

.git
├── branches
├── config
├── description
├── HEAD
├── hooks
│   ├── applypatch-msg.sample
│   ├── commit-msg.sample
│   ├── post-update.sample
│   ├── pre-applypatch.sample
│   ├── pre-commit.sample
│   ├── prepare-commit-msg.sample
│   ├── pre-push.sample
│   ├── pre-rebase.sample
│   └── update.sample
├── info
│   └── exclude
├── objects
│   ├── info
│   └── pack
└── refs
    ├── heads
    └── tags
  • 一个叫 HEAD 的文件,可以查看一下它的内容:

cat .git/HEAD

HEAD 文件中的内容其实只是包含了一个索引信息,并且,这个索引将总是指向你的项目中的当前开发分支。

  • 一个叫 objects 的子目录,它包含了你的项目中的所有对象,我们不必直接地了解到这些对象内容,我 们应该关心是存放在这些对象中的项目的数据。

  • 一个叫 refs 的子目录,它用来保存指向对象的索引。

具体地说,子目录 refs 包含着两个子目录叫 heads 和 tags,就像他们的名字所表达的意味一样:他们存放了不同的开发分支的头的索引, 或者是你用来标定版本的标签的索引。

请注意:master 是默认的分支,这也是为什么 .git/HEAD 创建的时候就指向 master 的原因,尽管目前它其实并不存在。 git 将假设你会在 master 上开始并展开你以后的工作,除非你自己创建你自己的分支。另外,这只是一个约定俗成的习惯而已,实际上你可以将你的工作分支叫任何名字,而不必在版本库中一定要有一个叫 master 的分支,尽管很多 git 工具都认为 master 分支是存在的。

提交修改

提交到暂存区

我们在项目目录中对文件做了修改(包括文件的添加、删除和修改),需要先将更改提交到暂存区:

git add .

这个命令要求 git 给我目前的这个项目制作一个快照 snapshot(快照只是登记留名,快照不等于记录在案,git管快照叫做索引 index)。快照一般会暂时存储在一个临时存储区域中,即暂存区。

其实,add 命令往往是用在有新文件加入时。在 git 中, 只要是文件有改动,无论是这个文件被修改的还是被新加入的,都可以使用 add 来进行登记。

提交到版本库

暂存区中的记录需要提交到版本库中才能够进行永久的保存:

git commit

该命令用于将快照里登记的内容永久写入 git 仓库中,也就是开发者已经想好了要提交自己的开发成果了。每次提交都会生成一个的 commit ID,即版本号,它用来唯一的标识每一个版本,这个值实际上是一个 SHA1 值。可以加上 -m 参数来对提交的版本进行描述:

git commit -m "描述信息"

如果不加 -m 参数,则会打开一个文本编辑器让你填写描述信息。

如果只是对文件的内容进行了修改,没有添加或者删除文件,则可以将提交到暂存区和提交到版本库合并为一步,即加 -a 参数:

git commit -am "描述信息"

切记,如果添加或者删除了文件,则必须使用 add 命令来提交到索引中,否则对文件的添加和删除将无法保存。

一般仓库中的文件可能存在于这三种状态:

  • Untracked files(文件未被跟踪)

  • Changes to be committed(文件已暂存,这是下次提交的内容)

  • Changes bu not updated(文件被修改,但并没有添加到暂存区)

git commit 提交的是暂存区里面的内容,也就是 Changes to be committed 中的文件。git commit -a 除了将暂存区里的文件提交外,还提交 Changes bu not updated 中的文件。如果 commit 时没有带 -a 选项,Changes bu not updated 状态下的文件不会被提交。

如果你想修改最后一次提交,可以用 git commit --amend 命令。也就是说,如果你对最后一次提交不满意,例如写错了提交注释信息,忘记添加某个文件,忘记修改某个文件等等,那么你可以重新对工作目录进行修改,然后重新 add 到暂存区,最后再 commit --amend,git 会用这次的提交去覆盖到最后一次提交,那么最后一次提交就不存在了,被替换了。该命令也可以用 -m 参数指定提交信息:

git commit --amend -m "YOUR-NEW-COMMIT-MESSAGE"

如果要修改更早的提交,可以使用 git rebase 工具。

提交到服务器

以上的操作都是在本地进行,最后我们需要将本地所有的提交推送到服务器,这样才能完成合作开发和版本控制。为了便于管理,Git要求每个远程服务器都必须指定一个主机名。git remote 命令就用于管理主机名。不带选项的时候,git remote 命令列出所有远程服务器。

git remote (列出所有远程服务器)

使用-v选项,可以参看远程主机的网址:

git remote -v

git remote show 命令加上主机名,可以查看该主机的详细信息:

git remote show <主机名>

如果本地工作目录中还没有添加远程服务器,则要先添加才能进行推送。git remote add命令用于添加远程服务器:

git remote add <主机名> <网址>

git remote rm 命令用于删除远程主机:

git remote rm <主机名>

git remote rename 命令用于远程主机的改名:

git remote rename <原主机名> <新主机名>

添加完之后,就可以将代码提交到远程服务器:

git push <主机名> <分支名>

远程操作

采用版本控制工具的目的就是为了便于远程协作以及对项目进行统一管理。一个项目的开发,可能不只你一个人在向远程服务器推送更改,所以我们还需要获取远程代码来与本地合并,或者直接克隆一个远程仓库。这就涉及到 git 的远程操作。

克隆项目

克隆项目就是不用在本地创建初始化一个版本库,而是从远程服务器上克隆一个已经存在的项目到本地。克隆一个版本库用 git clone 命令:

git clone <版本库的网址>

例如,克隆jQuery的版本库:

$ git clone https://github.com/jquery/jquery.git

该命令会在本地主机生成一个目录,与远程主机的版本库同名。如果要指定不同的目录名,可以将目录名作为git clone命令的第二个参数。

$ git clone <版本库的网址> <本地目录名>

Pull 远程分支

一旦远程主机的版本库有了更新(Git术语叫做commit),就需要将这些更新取回本地。Pull 远程分支是指,取回远程服务器上某个分支的更新,再与本地的指定分支合并。其格式为:

$ git pull <远程主机名> <远程分支名>:<本地分支名>

比如,取回 origin 主机的 dev 分支,与本地的 master 分支合并:

$ git pull origin dev:master

如果远程分支是与当前分支合并,则冒号后面的部分可以省略:

$ git pull origin dev

如果远程主机删除了某个分支,默认情况下,git pull 不会在拉取远程分支的时候,删除对应的本地分支。这是为了防止,由于其他人操作了远程主机,导致git pull不知不觉删除了本地分支。但是,你可以改变这个行为,加上参数 -p 就会在本地删除远程已经删除的分支。

$ git pull -p

Fetch 远程分支

Fetch 与 Pull 的区别是,Pull 拉取远程分支到本地,同时与本地分支合并,而 Fetch 则只负责拉取远程分支到本地不负责合并。如果项目由很多开发者协作开发,且分工复杂,则强烈建议采用 Fetch 来获取远程分支,否则采用 Pull 会更加方便些。

Fetch 命令格式为:

$ git fetch <远程主机名>

上面命令将某个远程主机的更新,全部取回本地。默认情况下,git fetch 取回所有分支(branch)的更新。如果只想取回特定分支的更新,可以指定分支名。

$ git fetch <远程主机名> <分支名>

比如,取回 origin 主机的 master 分支。

$ git fetch origin master

取回远程分支后,可以直接与本地分支合并。但是,在协作开发中,为了避免灾难发生,建议将获取的远程分支放在本地的一个新的分支上,然后与本地分支比较,没有问题后再进行合并。具体流程如下:

# 从远程的origin仓库的master分支下载到本地并新建一个分支temp
$ git fetch origin master:temp

# 比较 master 分支和 temp 分支的不同
$ git diff temp

#合并 temp 分支到 master 分支
$ git merge temp

# 如果不想要 temp 分支了,可以删除此分支
$ git branch -d temp

高级应用技巧

其实,本节所要将的内容并不高级,在掌握前边的内容后,就已经可以用 git 进行简单的版本控制和合作开发了。但有时候只掌握这些还远远不够,还需要掌握另外的技巧来完成工作,有的技巧甚至能提高工作效率和避免错误发生。所以我称之为高级应用技巧。

状态查看

之前提到过仓库中文件的三种状态,即:

  • Untracked files(文件未被跟踪)

  • Changes to be committed(文件已暂存,这是下次提交的内容)

  • Changes bu not updated(文件被修改,但并没有添加到暂存区)

使用如下命令可以查看文件的这三种状态:

git status

工作目录中文件的这三种状态都需要进行处理,否则在 push 时将无法达到你想要的结果。例如在 push 时漏掉了未跟踪的文件,那么在远程服务器上将无法看到该文件。git status能够让你随时掌握工作区的状态,强烈建议在每次 commitpush 之前都执行一次 git status,这样便于察觉是否漏掉了什么东西。

日志查看

git log

在项目开发不断向前推进的过程中,有时候需要回顾一下之前的提交历史,甚至有可能我们需要回退到曾经的版本上。那么我们可以采用如下命令进行日志查看:

git log

该命令列出每个提交的 SHA-1 校验和、作者的名字和电子邮件地址、提交时间以及提交说明,提交时间列出所有的更新,最近的更新排在最上面。当然 git log 有许多选项可以帮助你搜寻你所要找的提交, 并使得输出更加友好。例如:

git log -p -2

该命令列出每次提交所做的更改,-2 参数表示只显示最近两次提交,如果没有该参数则显示所有历史提交。还可以加上 --stat 参数,这样可以列出每次提交所变更的文件:

git log --stat

另外一个常用的选项是 --pretty。 这个选项可以指定使用不同于默认格式的方式展示提交历史。 这个选项有一些内建的子选项供你使用。 比如用 oneline 将每个提交放在一行显示,查看的提交数很大时非常有用。 另外还有 shortfullfuller 可以用,展示的信息或多或少有些不同。但最有意思的是 format,可以定制要显示的记录格式。 例如:

git log --pretty=format:"%h - %an, %ar : %s"

该命令表示在一行中显示一次提交的 ID、作者、时间和描述信息。该参数具体的格式控制符详见官方文档。在这里,你可能会遇到 作者提交者 的概念。其实作者指的是实际作出修改的人,提交者指的是最后将此工作成果提交到仓库的人。 所以,当你为某个项目发布补丁,然后某个核心成员将你的补丁并入项目时,你就是作者,而那个核心成员就是提交者。

当 oneline 或 format 与参数 --graph 结合使用时输入更为友好。这个选项添加了一些 ASCII 字符串来形象地展示你的分支、合并历史:

git log --pretty=format:"%h %s" --graph

还可以在 git log 命令后边加上文件路径,这样就可以只查看该文件的修改历史。

git show

git show 几乎与 git log 完全一样,甚至 git log 大部分的参数都能用于 git show。它们之间唯一的区别就是 git show 仅用于查看某一提交的详细信息,而 git log 可以一次查看所有提交。git showgit show HEAD 都默认显示最后一次提交的版本的信息,可以在 HEAD 后加上 ^ 来表示上一个版本。例如:

git show HEAD^

该命令显示 HEAD 的父(上一个版本)的提交日志,同样 ^^ 为上两个版本,^5 为上5个版本。同样也可以指定某一次提交的 ID,通常只需要 ID 的前几位即可。例如:

git show 8f962ad4 (8f962ad4a882f7e1da7247bb24427a6c3840a832)

git whatchanged

git-whatchanged 也可以用于查看提交日志,该命名显示提交历史及每次提交的改动,也可以用于查看具体的某个文件:

git whatchanged filename

git blame

git blame 可以单独查看某个文件的修改历史,它会显示指定文件是什么人在什么时间修改过:

git blame [file]

恢复与回退

这里的恢复是指恢复对工作区的修改,而回退是指版本的回退。主要涉及两个命令的使用,即 git-restt(重置)和 git-checkout(检出)。重置和检出有着很大的区别:重置的默认值是HEAD(版本库中的最后一次提交),而检出的默认值是暂存区。因此重置一般用于重置暂存区(除非使用 --hard 参数,否则不会重置工作区),而检出命令主要是覆盖工作区(如果<commit>不省略,也会替换暂存区中相应的文件)。

git-checkout 使用格式:

git checkout [-q] [<commit>] [--] <paths>...

在这里,git checkout 的作用主要用于恢复文件内容,下面是一些应用示例:

git checkout .

把暂存区内容拉下来,存到工作区。

git checkout -- <单一文件名>

把暂存区的某一个文件恢复下来到工作区。

git checkout HEAD .

把版本库最后一个版本同时恢复到暂存区和工作区

git checkout HEAD <单一文件名>

把版本库最后一个版本某一个文件同时恢复到暂存区和工作区

git checkout 版本ID .

把版本库中指定的提交的所有文件恢复到暂存区和工作区,但是版本库中该版本之后的其他版本内容都继续保留。但是要注意这与 git reset --hard 版本ID 不同,它是把版本库回退到指定版本,该版本之后的其他版本都没了。当然,如果在再次提交之前你还记得以后版本的 ID,同样还可以用 git reset --hard 命令恢复回去。

git-reset 使用格式:

git reset [-q] [<commit>] [--] <paths>...

git-reset [--mixed | --soft | --hard] [ <commit>]

第一种方法的应用与 checkout 类似,区别在于 reset 是将版本库中的内容恢复到暂存区。第二种用法的参数说明如下:

  • --mixed

仅是重置索引的位置,而不改变工作树中的任何东西(即,文件中的所有变化都会被保留,也不 标记他们为待提交状态),并且提示什么内容还没有被更新了。这个是默认的选项。

  • --soft

既不触动索引的位置,也不改变工作树中的任何内容,我们只是要求这些内容成为一份好的内容(之 后才成为真正的提交内容)。这个选项使你可以将已经提交的东西重新逆转至 “已更新但未提交 (Updated but not Check in)” 的状态。就像已经执行过 git-update-index 命令,但是还没有执行 git- commit 命令一样。

  • --hard

将工作树中的内容和头索引都切换至指定的版本位置中,也就是说自 <commit-ish> 之后的所有的跟踪 内容和工作树中的内容都会全部丢失。因此,这个选项要慎用,除非你已经非常确定你的确不想再看 到那些东西了。

对于 git reset 命令,我们可以简单的这样理解:

  • 1、git reset --soft 只撤销 commit,保留 working tree 和 index file。
  • 2、 git reset --hard 撤销 commit、index file 和 working tree,即彻底回退到以前的版本。
  • 3、 git reset --mixed 撤销 commit 和 index file,保留 working tree。该选项为默认选项,可以省略。

分支管理

对于分支的概念,用短短几句话无法下一个准确的定义,例如有人试图用一句话来定义 git 分支:

  • 准确而言,分支的概念不是一条线,而类似于开发中的有向无环图

  • 分支类似于一个重量级的大对象集合

  • 分支是用来标记特定的代码提交,每一个分支通过SHA1sum值来标识

感觉这样的定义都是顾此失彼,要详细的理解 git 分支,可以查看官方帮助文档。可以简单的将分支理解为就像是分身一样,用不同的分身去做不同的事,在必要的时候再将它们合并在一起。这个比喻也不能完全体现分支的概念,这里只是为了分支的概念变得容易理解。

Git 的分支管理是一门艺术。应对不同的项目,或者对于不同的管理者,更或者对于不同的开发者,对分支管理的策略可能都会有所不同。首先,代码库应该有一个、且仅有一个主分支。所有最终的正式版本,都在这个主分支上发布。然后,我们可以有一个开发分支,来完成整个的开发过程。当然,也可以有一个临时分支,用于应对一些特定目的的版本开发。另外,还可以有功能分支、预发布分支等等。这里只是列举,应根据实际的需要来创建分支。

对于本地分支(local branches)来说 ,可以用如下命令查看、:

git branch

这条命令能够显示本地所有的分支,前边带 * 的分支为当前所在的分支。如果要查看远程跟踪分支(Remote-tracking branches),可以用如下命令:

git branch -r

同时查看本地和远程分支:

git branch -a

创建一个新分支:

git branch branch-name

该命令以当前最后一个版本为模板创建新的分支,就好像一棵树,从这一点起,开始分为两根枝干。

在之前,我们了解到 git-checkout 用于恢复文件,其实 git-checkout 还可以用于分支的切换。要切换当前分支到别的分支,可以用如下命令:

git checkout branch-name

可以同时创建并切换到该分支:

git checkout -b branch-name

合并某分支到当前分支:

git merge name

删除本地分支,强制删除用-D:

git branch -d branch-name

删除远程分支:

git push origin :branch-name

检查改动

之前,我们了解到使用 git log -p 可查看文件的改动,但这只能查看最近两次提交的差异。Git 还有另外一个命令来查看文件的变动,即git diffgit diff 的具体使用如下:

  • 显示工作区与暂存区之间的差异:

git diff

  • 显示暂存区与版本库之间的差异:

git diff --cached

  • 显示工作区与版本库之间的差异:

git diff HEAD (与最后一次提交比较)

git diff HEAD^ (与上次提交比较)

git diff HEAD~2 (与上上次提交比较)

git diff commit_id (与指定的版本比较)

  • 版本库与版本库之间的比较:

git diff commit1 commit2

  • 显示指定状态的文件

git diff --diff-filter=[ACDMRTUXB*]

参数值说明:Added (A), Copied (C), Deleted (D), Modified (M), Renamed (R), changed (T), are Unmerged (U), are Unknown (X)

  • 列出工作区改动的文件:

git diff --stat

  • 仅对比指定的文件(比较工作区与最后一次提交):

git diff -- filename

添加多个远程仓库

为项目添加多个远程仓库大致有两种形式,一种是用不同的仓库名来标识不同的远程仓库,另一种是在一个仓库名下添加多个远程仓库地址。

先说一下在同一仓库名下添加多个地址。假如我们有两个远程仓库:

https://git.oschina.net/kuanghy/test.git
https://github.com/kuanghy/test.git

首先添加第一个 remote,并将仓库命名为 origin:

git remote add origin https://git.oschina.net/kuanghy/test.git

然后再添加另一个:

git remote set-url --add origin https://github.com/kuanghy/test.git

如果还有多个地址,按照上面命令继续添加即可。在提交时,用如下命令则可以将更改提交到所有仓库:

git push origin --all

其实,当添加完多个远程仓库后,查看配置文件,会发现有如下内容:

[remote "origin"]
    url = https://git.oschina.net/kuanghy/test.git/
    fetch = +refs/heads/*:refs/remotes/origin/*
    url = https://github.com/kuanghy/test.git

所以,我们可以直接修改配置文件来添加多个远程仓库,即在 remote 配置项中添加多个 url 即可。

这种配置的好处是,一次提交就能把更改提交到多个仓库,不用麻烦。但这种方式也有弊端,用于合作开发中时有些问题解决起来比较麻烦。如果有人对两个仓库分别进行了更改,而你在本地 pull 的时候, git 默认只拉取最新添加的 remote,其他 remote 的更改则无法 pull,于是无法合并这多个更改。所以用这种方式必须保证多个仓库的更改是完全同步的。

那么,再来说说另一种添加多个远程仓库的方式,即为不同的远程仓库标识不同的仓库名:

git remote add gitosc https://git.oschina.net/kuanghy/test.git/

git remote add github https://github.com/kuanghy/test.git

这样就添加了多个远程仓库。把托管在 Git@OSC 上的仓库命令为 gitosc, 把托管在 GitHub 上的仓库命令为 github,在 push 和 pull 的时候指定不同的仓库名即可:

git push gitosc master

git push github master

git pull gitosc master

git pull github master

这种方式的好处是可以保证多个仓库间的 push 与 pull 互补干扰,当然缺点就是要一个一个去 push 和 pull, 比较麻烦。

免密码提交

如果不想每次 push 和 pull 都输入用户名和密码,则可以做一些配置,实现免密码提交。配置的方式有两种,一种是添加 ssh 密钥进行验证,这里不做详述;另一种是创建 .git-credentials 文件保存用户名和密码,当然这种方式是不安全的。下面说一下步骤:

  • 1、创建文件存储 git 用户名和密码

在主目录下创建 .git-credentials 文件,并写入如下格式的内容:

https://{username}:{password}@github.com
  • 2、添加 Git Config 内容

添加配置项:

git config --global credential.helper store

查看 ~/.gitconfig 文件中多了如下内容则表示添加成功:

[credential]
    helper = store

应用示例

在 git 代码托管服务器上使用示例

1、Git 全局设置:

git config --global user.name "username"
git config --global user.email "useremail"

2、创建 git 仓库:

mkdir prodir (工程目录)
cd prodir
git init
touch README.md
git add README.md
git commit -m "first commit"
git remote add origin https://git.oschina.net/username/prodir.git
git push -u origin master

3、添加已有项目

cd existing_git_repo
git remote add origin https://git.oschina.net/username/prodir.git
git push -u origin master

项目开发的基本使用流程

这里介绍两种 Git 的开发工作流程,这里实际上是在介绍git的两种合并分支的方法,其主要目的都是将最终的工作合并到主分支master上。

工作流程一:

1、去自己的工作分支

$ git checkout work

2、工作

....

3、提交工作分支的修改

$ git commit -a

4、回到主分支

$ git checkout master

5、获取远程最新的修改,此时不会产生冲突

$ git pull

6、回到工作分支

$ git checkout work

7、用rebase合并主干的修改,如果有冲突在此时解决

$ git rebase master

8、回到主分支

$ git checkout master

9、合并工作分支的修改,此时不会产生冲突。

$ git merge work

10、提交到远程主干

$ git push

工作流程二:

1、创建一个开发分支dev

$ git branch dev (以当前最后一个版本为模板,创建一个新分支)

$ git checkout --orphan dev (以当前分支创建一个裸分支,没有任何提交历史,但保留当前分支的内容)

2、在dev分支上进行工作

....

3、提交对dev分支的修改并push到远程仓库

$ git commit -a

$ git push origin dev

4、回到主分支

$ git checkout master

5、将远程dev分支拉取到本地并与住分支合并

$ git pull origin dev

6、修改冲突并提交到远程master分支

$ git commit -a

$ git push origin master

在 github 上创建 gh-pages 分支

1、创建 gh-pages 分支

$ git checkout --orphan gh-pages

2、删除原有内容

$ git rm -rf .

3、添加更改到暂存区

$ git add .

4、提交到版本库

$ git commit -a -m "First pages commit"

5、提交到远程仓库

$ git push origin gh-pages

参考资料

参考资料

编者申明

编者申明

本文档是根据一些网络资料以及我学习和工作中的经验总结提炼而得。文中肯定存在大量的错误,如阅者发现错误,还望批评指正,联系方式: sudohuoty@163.com。由于本文档大部分内容参考引用自网络,并非本人原创,故本文档仅可用作学习和工作的参考,不可用于其他用途。

再次声明,本文档仅供学习参考,禁止用于其他用途,!