Git使用方法(整理)

1.1 起步 - 关于版本控制

本章为 Git 入门。 我们从介绍版本控制工具的背景知识开始,然后讲解如何在你的系统上运行 Git,最后是关于如何设置 Git 以便开始工作。 通过本章的学习,你应该能了解为什么 Git 这么流行,为什么你应该使用 Git 以及你应该如何设置以便使用 Git。

关于版本控制

什么是“版本控制”?我为什么要关心它呢? 版本控制是一种记录一个或若干文件内容变化,以便将来查阅特定版本修订情况的系统。 在本书所展示的例子中,我们对保存着软件源代码的文件作版本控制,但实际上,你可以对任何类型的文件进行版本控制。

如果你是位图形或网页设计师,可能会需要保存某一幅图片或页面布局文件的所有修订版本(这或许是你非常渴望拥有的功能),采用**版本控制系统(VCS)**是个明智的选择。 有了它你就可以将选定的文件回溯到之前的状态,甚至将整个项目都回退到过去某个时间点的状态,你可以比较文件的变化细节,查出最后是谁修改了哪个地方,从而找出导致怪异问题出现的原因,又是谁在何时报告了某个功能缺陷等等。 使用版本控制系统通常还意味着,就算你乱来一气把整个项目中的文件改的改删的删,你也照样可以轻松恢复到原先的样子。 但额外增加的工作量却微乎其微。

本地版本控制系统

许多人习惯用复制整个项目目录的方式来保存不同的版本,或许还会改名加上备份时间以示区别。 这么做唯一的好处就是简单,但是特别容易犯错。 有时候会混淆所在的工作目录,一不小心会写错文件或者覆盖意想外的文件。

为了解决这个问题,人们很久以前就开发了许多种本地版本控制系统,大多都是采用某种简单的数据库来记录文件的历次更新差异。

Git 简史

同生活中的许多伟大事物一样,Git 诞生于一个极富纷争大举创新的年代。

Linux 内核开源项目有着为数众多的参与者。 绝大多数的 Linux 内核维护工作都花在了提交补丁和保存归档的繁琐事务上(1991-2002年间)。 到 2002 年,整个项目组开始启用一个专有的分布式版本控制系统 BitKeeper 来管理和维护代码。

到了 2005 年,开发 BitKeeper 的商业公司同 Linux 内核开源社区的合作关系结束,他们收回了 Linux 内核社区免费使用 BitKeeper 的权力。 这就迫使 Linux 开源社区(特别是 Linux 的缔造者 Linus Torvalds)基于使用 BitKeeper 时的经验教训,开发出自己的版本系统。 他们对新的系统制订了若干目标:

  • 速度
  • 简单的设计
  • 对非线性开发模式的强力支持(允许成千上万个并行开发的分支)
  • 完全分布式
  • 有能力高效管理类似 Linux 内核一样的超大规模项目(速度和数据量)

自诞生于 2005 年以来,Git 日臻成熟完善,在高度易用的同时,仍然保留着初期设定的目标。 它的速度飞快,极其适合管理大项目,有着令人难以置信的非线性分支管理系统(参见 Git 分支)。

1.2 起步 - Git 是什么?

  • Git 是什么?

那么,简单地说,Git 究竟是怎样的一个系统呢? 请注意接下来的内容非常重要,若你理解了 Git 的思想和基本工作原理,用起来就会知其所以然,游刃有余。 在学习 Git 时,请尽量理清你对其它版本管理系统已有的认识,如 CVS、Subversion 或 Perforce, 这样能帮助你使用工具时避免发生混淆。尽管 Git 用起来与其它的版本控制系统非常相似, 但它在对信息的存储和认知方式上却有很大差异,理解这些差异将有助于避免使用中的困惑。

  • 直接记录快照,而非差异比较

Git 和其它版本控制系统(包括 Subversion 和近似工具)的主要差别在于 Git 对待数据的方式。 从概念上来说,其它大部分系统以文件变更列表的方式存储信息,这类系统(CVS、Subversion、Perforce、Bazaar 等等) 将它们存储的信息看作是一组基本文件和每个文件随时间逐步累积的差异 (它们通常称作 基于差异(delta-based) 的版本控制)。
存储每个文件与初始版本的差异
Figure 4. 存储每个文件与初始版本的差异.

Git 不按照以上方式对待或保存数据。反之,Git 更像是把数据看作是对小型文件系统的一系列快照。 在 Git 中,每当你提交更新保存项目状态时,它基本上就会对当时的全部文件创建一个快照并保存这个快照的索引。 为了效率,如果文件没有修改,Git 不再重新存储该文件,而是只保留一个链接指向之前存储的文件。 Git 对待数据更像是一个 快照流。
存储项目随时间改变的快照.
Figure 5. 存储项目随时间改变的快照.

这是 Git 与几乎所有其它版本控制系统的重要区别。 因此 Git 重新考虑了以前每一代版本控制系统延续下来的诸多方面。 Git 更像是一个小型的文件系统,提供了许多以此为基础构建的超强工具,而不只是一个简单的 VCS。 稍后我们在Git 分支讨论 Git 分支管理时,将探究这种方式对待数据所能获得的益处。

  • 近乎所有操作都是本地执行

在 Git 中的绝大多数操作都只需要访问本地文件和资源,一般不需要来自网络上其它计算机的信息。 如果你习惯于所有操作都有网络延时开销的集中式版本控制系统,Git 在这方面会让你感到速度之神赐给了 Git 超凡的能量。 因为你在本地磁盘上就有项目的完整历史,所以大部分操作看起来瞬间完成。

举个例子,要浏览项目的历史,Git 不需外连到服务器去获取历史,然后再显示出来——它只需直接从本地数据库中读取。 你能立即看到项目历史。如果你想查看当前版本与一个月前的版本之间引入的修改, Git 会查找到一个月前的文件做一次本地的差异计算,而不是由远程服务器处理或从远程服务器拉回旧版本文件再来本地处理。

这也意味着你在离线或者没有 VPN 时,几乎可以进行任何操作。 如你在飞机或火车上想做些工作,就能愉快地提交(到你的 本地 副本,还记得吗?), 直到有网络连接时再上传。如你回家后 VPN 客户端不正常,那么也仍能工作。 使用其它系统的话,做到这些是不可能或很费力的。 比如,用 Perforce 的话,没有连接服务器时几乎不能做什么事;而用 Subversion 和 CVS 的话, 你能修改文件,但不能向数据库提交修改(因为你的本地数据库离线了)。 这样似乎问题不大,但是你可能会惊喜地发现它带来的巨大的不同。

  • Git 保证完整性

Git 中所有的数据在存储前都计算校验和,然后以校验和来引用。 这意味着不可能在 Git 不知情时更改任何文件内容或目录内容。 这个功能建构在 Git 底层,是构成 Git 哲学不可或缺的部分。 若你在传送过程中丢失信息或损坏文件,Git 就能发现。

Git 用以计算校验和的机制叫做 SHA-1 散列(hash,哈希)。 这是一个由 40 个十六进制字符(0-9 和 a-f)组成的字符串,基于 Git 中文件的内容或目录结构计算出来。 SHA-1 哈希看起来是这样:

24b9da6552252987aa493b52f8696cd6d3b00373
Git 中使用这种哈希值的情况很多,你将经常看到这种哈希值。 实际上,Git 数据库中保存的信息都是以文件内容的哈希值来索引,而不是文件名。

  • Git 一般只添加数据

你执行的 Git 操作,几乎只往 Git 数据库中 添加 数据。 你很难使用 Git 从数据库中删除数据,也就是说 Git 几乎不会执行任何可能导致文件不可恢复的操作。 同别的 VCS 一样,未提交更新时有可能丢失或弄乱修改的内容。但是一旦你提交快照到 Git 中, 就难以再丢失数据,特别是如果你定期的推送数据库到其它仓库的话

这使得我们使用 Git 成为一个安心愉悦的过程,因为我们深知可以尽情做各种尝试,而没有把事情弄糟的危险。 更深度探讨 Git 如何保存数据及恢复丢失数据的话题,请参考撤消操作。

  • 三种状态

现在请注意,如果你希望后面的学习更顺利,请记住下面这些关于 Git 的概念。 Git 有三种状态,你的文件可能处于其中之一:

已提交(committed)、 已修改(modified)、 已暂存(staged)。

  1. 已修改表示修改了文件,但还没保存到数据库中。
  2. 已暂存表示对一个已修改文件的当前版本做了标记,使之包含在下次提交的快照中。
  3. 已提交表示数据已经安全地保存在本地数据库中。

这会让我们的 Git 项目拥有三个阶段:工作区、暂存区以及 Git 目录。
工作目录、暂存区域以及 Git 仓库
Figure 6. 工作目录、暂存区域以及 Git 仓库.

工作区是对项目的某个版本独立提取出来的内容。 这些从 Git 仓库的压缩数据库中提取出来的文件,放在磁盘上供你使用或修改。

暂存区是一个文件,保存了下次将要提交文件列表信息,一般在 Git 仓库目录中。 按照 Git 的术语叫做“索引”,不过一般说法还是叫“暂存区”。

Git 仓库目录是 Git 用来保存项目的元数据和对象数据库的地方。 这是 Git 中最重要的部分,从其它计算机克隆仓库时,复制的就是这里的数据。

  • 基本的 Git 工作流程如下:
  1. 在工作区中修改文件。

  2. 将你想要下次提交的更改选择性地暂存,这样只会将更改的部分添加到暂存区。

  3. 提交更新,找到暂存区的文件,将快照永久性存储到 Git 目录。

    如果 Git 目录中保存着特定版本的文件,就属于 已提交 状态。 如果文件已修改并放入暂存区,就属于 已暂存 状态。
    如果自上次检出后,作了修改但还没有放到暂存区域,就是 已修改 状态。 在 Git 基础 一章,你会进一步了解这些状态的细节,
    并学会如何根据文件状态实施后续操作,以及怎样跳过暂存直接提交。

1.3 下载-命令行

  • 命令行

Git 有多种使用方式。你可以在命令行模式使用,也可以使用 GUI 模式,这些 GUI 软件也能提供多种功能。在本书中,我们将使用命令行模式。在命令行模式下你能够执行 Git 的所有命令,而大多数的 GUI 软件实现了 Git 所有功能的一个子集以降低操作难度。如果你学会了在命令行下如何操作,那么你在操作 GUI软件时应该也不会遇到什么困难,但是,反之则不成立。此外,由于每个人的想法与侧重点不同,不同的人常常会安装不同的GUI软件,但所有人一定会有命令行工具。

发现你是 macOS 用户,我们希望你熟悉如何使用终端(终端);发现你是 Windows 用户,我们希望你学会如何使用命令窗口(Command Prompt)或 PowerShell。下来快速一下,这本书中的讲述和举例将这些技能。

1.4 起步 - 安装 Git

  • 在 Windows 上安装
    在 Windows 上安装 Git 也有几种安装方法。 官方版本可以在 Git 官方网站下载。 打开 https://git-scm.com/download/win,下载会自动开始。 要注意这是一个名为 Git for Windows 的项目(也叫做 msysGit),和 Git 是分别独立的项目;更多信息请访问 http://msysgit.github.io/。

要进行自动安装,你可以使用 Git Chocolatey 包。 注意 Chocolatey 包是由社区维护的。

另一个简单的方法是安装 GitHub Desktop。 该安装程序包含图形化和命令行版本的 Git。 它也能支持 Powershell,提供了稳定的凭证缓存和健全的换行设置。 稍后我们会对这方面有更多了解,现在只要一句话就够了,这些都是你所需要的。 你可以在 GitHub for Windows 网站下载,网址为 GitHub Desktop 网站。

  • 从源代码安装
    有人觉得从源码安装 Git 更实用,因为你能得到最新的版本。 二进制安装程序倾向于有一些滞后,当然近几年 Git 已经成熟,这个差异不再显著。

如果你想从源码安装 Git,需要安装 Git 依赖的库:autotools、curl、zlib、openssl、expat 和 libiconv。 如果你的系统上有 dnf (如 Fedora)或者 apt(如基于 Debian 的系统), 可以使用对应的命令来安装最少的依赖以便编译并安装 Git 的二进制版:

$ sudo dnf install dh-autoreconf curl-devel expat-devel gettext-devel
openssl-devel perl-devel zlib-devel
$ sudo apt-get install dh-autoreconf libcurl4-gnutls-dev libexpat1-dev
gettext libz-dev libssl-dev
为了添加文档的多种格式(doc、html、info),需要以下附加的依赖:

$ sudo dnf install asciidoc xmlto docbook2X
$ sudo apt-get install asciidoc xmlto docbook2x
Note
使用 RHEL 和 RHEL 衍生版,如 CentOS 和 Scientific Linux 的用户需要 开启 EPEL 库 以便下载 docbook2X 包。

如果你使用基于 Debian 的发行版(Debian/Ubuntu/Ubuntu-derivatives),你也需要 install-info 包:

$ sudo apt-get install install-info
如果你使用基于 RPM 的发行版(Fedora/RHEL/RHEL衍生版),你还需要 getopt 包 (它已经在基于 Debian 的发行版中预装了):

$ sudo dnf install getopt
此外,如果你使用 Fedora/RHEL/RHEL衍生版,那么你需要执行以下命令:

$ sudo ln -s /usr/bin/db2x_docbook2texi /usr/bin/docbook2x-texi
以此来解决二进制文件名的不同。

当你安装好所有的必要依赖,你可以继续从几个地方来取得最新发布版本的 tar 包。 你可以从 Kernel.org 网站获取,网址为 https://www.kernel.org/pub/software/scm/git, 或从 GitHub 网站上的镜像来获得,网址为 https://github.com/git/git/releases。 通常在 GitHub 上的是最新版本,但 kernel.org 上包含有文件下载签名,如果你想验证下载正确性的话会用到。

接着,编译并安装:

$ tar -zxf git-2.8.0.tar.gz
$ cd git-2.8.0
$ make configure
$ ./configure --prefix=/usr
$ make all doc info
$ sudo make install install-doc install-html install-info
完成后,你可以使用 Git 来获取 Git 的更新:

$ git clone git://git.kernel.org/pub/scm/git/git.git

1.5 起步 - 初次运行 Git 前的配置

  • 初次运行 Git 前的配置
    既然已经在系统上安装了 Git,你会想要做几件事来定制你的 Git 环境。 每台计算机上只需要配置一次,程序升级时会保留配置信息。 你可以在任何时候再次通过运行命令来修改它们。

Git 自带一个 git config 的工具来帮助设置控制 Git 外观和行为的配置变量。 这些变量存储在三个不同的位置

  • /etc/gitconfig 文件:
    包含系统上每一个用户及他们仓库的通用配置。 如果在执行 git config 时带上** --system 选项**,那么它就会读写该文件中的配置变量。 (由于它是系统配置文件,因此你需要管理员或超级用户权限来修改它。)

  • ~/.gitconfig 或 ~/.config/git/config 文件:

  • 只针对当前用户。 你可以传递** --global 选项**让 Git 读写此文件,这会对你系统上 所有 的仓库生效。

  • 当前使用仓库的 Git 目录中的 config 文件(即 .git/config):

  • 针对该仓库。 你可以传递** --local 选项**让 Git 强制读写此文件,虽然默认情况下用的就是它。。 (当然,你需要进入某个 Git 仓库中才能让该选项生效。)

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

在 Windows 系统中,Git 会查找 $HOME 目录下(一般情况下是 C:\Users$USER )的 .gitconfig 文件。 Git 同样也会寻找 /etc/gitconfig 文件,但只限于 MSys 的根目录下,即安装 Git 时所选的目标位置。 如果你在 Windows 上使用 Git 2.x 以后的版本,那么还有一个系统级的配置文件,Windows XP 上在 C:\Documents and Settings\All Users\Application Data\Git\config ,Windows Vista 及更新的版本在 C:\ProgramData\Git\config 。此文件只能以管理员权限通过 git config -f 来修改。

你可以通过以下命令查看所有的配置以及它们所在的文件:

$ git config --list --show-origin
用户信息
安装完 Git 之后,要做的第一件事就是设置你的用户名和邮件地址。 这一点很重要,因为每一个 Git 提交都会使用这些信息,它们会写入到你的每一次提交中,不可更改:

$ git config --global user.name “John Doe”
$ git config --global user.email johndoe@example.com
再次强调,如果使用了 --global 选项,那么该命令只需要运行一次,因为之后无论你在该系统上做任何事情, Git 都会使用那些信息。 当你想针对特定项目使用不同的用户名称与邮件地址时,可以在那个项目目录下运行没有 --global 选项的命令来配置。

很多 GUI 工具都会在第一次运行时帮助你配置这些信息。

文本编辑器

既然用户信息已经设置完毕,你可以配置默认文本编辑器了,当 Git 需要你输入信息时会调用它。 如果未配置,Git 会使用操作系统默认的文本编辑器。

如果你想使用不同的文本编辑器,例如 Emacs,可以这样做:

$ git config --global core.editor emacs
在 Windows 系统上,如果你想要使用别的文本编辑器,那么必须指定可执行文件的完整路径。 它可能随你的编辑器的打包方式而不同。

对于 Notepad++,一个流行的代码编辑器来说,你可能想要使用 32 位的版本, 因为在本书编写时 64 位的版本尚不支持所有的插件。 如果你在使用 32 位的 Windows 系统,或在 64 位系统上使用 64 位的编辑器,那么你需要输入如下命令:

$ git config --global core.editor “‘C:/Program Files/Notepad++/notepad++.exe’ -multiInst -notabbar -nosession -noPlugin”
Note
Vim、Emacs 和 Notepad++ 都是流行的文本编辑器,通常程序员们会在 Linux 和 macOS 这类基于 Unix 的系统或 Windows 系统上使用它们。 如果你在使用其他的或 32 位版本的编辑器,请在 core.editor 中查看设置为该编辑器的具体步骤。

Warning

如果你不这样设置编辑器,那么当 Git 试图启动它时你可能会被弄糊涂、不知所措。 例如,在 Windows 上 Git 在开始编辑时可能会过早地结束。

检查配置信息

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

$ git config --list
user.name=John Doe
user.email=johndoe@example.com
color.status=auto
color.branch=auto
color.interactive=auto
color.diff=auto

你可能会看到重复的变量名,因为 Git 会从不同的文件中读取同一个配置(例如:/etc/gitconfig 与 ~/.gitconfig)。 这种情况下,Git 会使用它找到的每一个变量的最后一个配置。

你可以通过输入 git config : 来检查 Git 的某一项配置

$ git config user.name
John Doe
Note
由于 Git 会从多个文件中读取同一配置变量的不同值,因此你可能会在其中看到意料之外的值而不知道为什么。 此时,你可以查询 Git 中该变量的 原始 值,它会告诉你哪一个配置文件最后设置了该值:

$ git config --show-origin rerere.autoUpdate
file:/home/johndoe/.gitconfig false

1.6 获取 - 获取帮助

获取帮助

若你使用 Git 时需要获取帮助,有等价的方法可以找到 Git 命令的综合手册(manpage):

$ git help
$ git --help
$ man git-
例如,想要获得git config命令的手册,执行

$ git help config
如果你觉得手册或者书籍的内容还用,你可以尝试在 Freenode IRC 服务器https://freenode.net上的#git或#github寻求帮助。频道经常有上百人在线,他们都精通 Git 并且乐于助人。

此外,如果你不需要全面的手册,只需要可用选项的快速参考,那么可以用-h选项获得更简明的“帮助”输出:

$ git add -h
usage: git add [] [–] …

-n, --dry-run         dry run  (排练,演戏)
-v, --verbose         be verbose(详细的)

-i, --interactive     interactive picking(交互式选择)
-p, --patch           select hunks interactively(选择大块交互)
-e, --edit            edit current diff and apply(编辑当前差异并应用)
-f, --force           allow adding otherwise ignored files(允许添加被忽略的文件)
-u, --update          update tracked files(更新跟踪文件)
--renormalize         renormalize EOL of tracked files (implies -u) (重新规范化被跟踪文件的EOL(暗示-u))
-N, --intent-to-add   record only the fact that the path will be added later(只记录稍后将添加路径的事实  )
-A, --all             add changes from all tracked and untracked files(从所有已跟踪和未跟踪的文件中添加更改  )
--ignore-removal      ignore paths removed in the working tree (same as --no-all)(忽略工作树中删除的路径(与——no-all相同)  )
--refresh             don't add, only refresh the index(不要添加,只刷新索引)
--ignore-errors       just skip files which cannot be added because of errors(跳过那些因为错误而不能添加的文件  )
--ignore-missing      check if - even missing - files are ignored in dry run(检查是否-甚至丢失-文件忽略演习  )
--chmod (+|-)x        override the executable bit of the listed files(覆盖列出的文件的可执行位  )

总结

你应该已经对 Git 是什么、Git 和你可能正在使用的集中式版本控制系统使用的等问题有了基本的了解。现在,在你的系统中应该也有一个能够工作的 Git 版本。时候开始学习有关 Git 的基础知识了。

Git官网:链接: Git官网.

1.7 Git用法详解

git客户端(本地仓库)的一些操作

  1. 设置账户(需要和github账户设置一致)
    git config --global user.name xxx
    git config --global user.email xxx@foxmail.com

  2. 查看设置
    git config --list
    user.name= xxx
    user.email= xxx@foxmail.com

  3. 创建git本地仓库
    git init
    此时会出现提示 : inialized empty Git repository in d://com/liu/.git

  4. 查看git状态
    git status
    一般来说会显示需要提交的文件(uncommited)和未追踪的文件(untracked)
    uncommited:已有的,刚被修改尚未提交的
    untracked:原先没有的,新建的

  5. 添加 git文件到暂存区(需要和版本库区分)
    git add

  6. git 提交文件
    git commit -m “add a function in test.java”
    -m表示注释,为提交时的说明,必须要有

  7. git 删除文件(夹)
    git rm test.txt //删除文件
    git rm -r filebook //删除文件夹
    git rm和直接删除的区别在于git rm会将此文件的操作记录删除,而直接删除仅仅是删除了物理文件,没有删除和此文件相关的记录。git rm后会在版本库产生区别(有操作日志),而直接删除没有。

可以用下面两种操作在版本库中删除文件:
git rm test.txt => git commit -m ‘delete a file’
rm test.txt => git commit -am ‘delete a file’
注意:命令git rm用于删除一个文件。如果一个文件已经被提交到版本库,那么你永远不用担心误删,但是要小心,你只能恢复文件到最新版本,你会 丢失最近一次提交后你修改的内容。

  1. git操作日志
    git log --decorate --graph --oneline --all #显示当前及之前的版本号
    git log --pretty=oneline #将版本历史显示为一行, 历史版本号全部显示
    git log --pretty=oneline --abbrev-commit #将版本历史显示为一行, 历史版本号部分显示
    git log --graph #查看分支合并图

  2. 版本回退
    执行版本退回后,本地工作区的内容会自动和回退到的版本库版本的内容保持同步
    git reset --hard HEAD^ // 回退到上一个版本
    git reset --hard HEAD^^ // 回退到上上个版本,以此类推,一次提交即为一个版本
    git reset --hard e9efa77 // 回退到 e9efa77 版本

  3. git还原操作
    丢弃工作区的操作,但不会丢失暂存区的操作(add操作能将更改添加到暂存区),实际上就是用版本库里的版本替换工作区的版本,无论工作区是修改还是删除,都可以“一键还原”
    git checkout – readme.txt

  4. git暂存区撤销操作
    工作区修改了文件,而且执行了add,但还没执行commit,暂存区还是可以撤销的
    git reset HEAD readme.txt
    备注:git reset命令既可以回退版本,也可以把暂存区的修改回退到工作区。当我们用HEAD时,表示最新的版本。

与github/gitee协同使用(git代码托管服务器)

和GitHub相比,码云(Gitee)也提供免费的Git仓库。此外,还集成了代码质量检测、项目演示等功能。对于团队协作开发,码云还提供了项目管理、代码托管、文档管理的服务,5人以下小团队免费。

  1. 配置远程仓库免密登陆
    (1)在用户主目录下,看看有没有.ssh目录,如果有,再看看这个目录下有没有 id_rsa和 id_rsa.pub这两个文件,如果已经有了,可直接跳到下一步。如果没有,打开Shell(Windows下打开Git Bash),创建SSH Key: ssh-keygen -t rsa -C " xxx@foxmail.com "
    备注:一路回车,执行生成 id_rsa 私钥 和 id_rsa.pub 公钥,Windows用户在git bash中输入上述指令

(2)获得key的内容,复制下来,添加到gitHub的SSH key中
windows位置:‪C:\Users\用户名.ssh\id_rsa.pub
Linux位置:cat ~/.ssh/id_rsa.pub

在这里插入图片描述

在这里插入图片描述

(3) ssh -T git@github.com #验证key,根据提示输入yes,添加为信任主机
或者 ssh -T git@git.oschina.net

  1. 添加远程仓库
    git remote add origin https://github.com/xxx/LearnGit.git(https方式)
    (ssh方式)
    此处可以为https地址也可以是ssh地址,orign为设置的远程仓库的别名,强烈建议使用ssh方式,因为https方式每次都要输入用户名和密码
    如果需要修改传输协议:
    (1) git remote rm <远程主机名>( 删除远程仓库)
    (2) 设置传输方式和目标远程仓库
    (3) git push -u <远程主机名> <本地分支名>

码云的添加远程仓库方法:
git remote add origin git@gitee.com:xxx/LearnGit.git(ssh方式)
如果git remote add失败,并报错:fatal: remote origin already exists.
说明本地库已经关联了一个名叫origin的远程库,此时,可以先用git remote -v查看远程库信息:
origin git@github.com: xxx/LearnGit.git (fetch)
origin git@github.com: xxx/LearnGit.git (push)
表示本地库已经关联了Github上的origin远程库,需要先删除已有的Github库:
git remote remove origin
再关联码云的远程库(注意路径中需要填写正确的用户名):
git remote add gitee git@gitee.com:xxx/LearnGit.git

因为git本身是分布式版本控制系统,可以同步到另外一个远程库,当然也可以同步到另外两个远程库,所以 一个本地库可以既关联GitHub,又关联码云!
使用多个远程库时,要注意git给远程库起的默认名称是origin,如果有多个远程库,我们需要用不同的名称来标识不同的远程库。仍然以learngit本地库为例,先删除已关联的名为origin的远程库:
git remote rm origin
然后,先关联GitHub的远程库:
git remote add github git@github.com:xxx/LearnGit.git
注意,远程库的名称叫github,不叫origin了。
接着,再关联码云的远程库:
git remote add gitee git@gitee.com:xxx/LearnGit.git
同样注意,远程库的名称叫gitee,不叫origin。
现在,我们用 git remote -v查看远程库信息,可以看到两个远程库:gitee git@gitee.com: xxx/LearnGit.git (fetch)
gitee git@gitee.com: xxx/LearnGit.git (push)
github git@github.com: xxx/LearnGit.git (fetch)
github git@github.com: xxx/LearnGit.git (push)
如果要推送到GitHub,使用命令:
git push github master
如果要推送到码云,使用命令:
git push gitee master
这样一来,本地库就可以同时与多个远程库互相同步:

在这里插入图片描述

  1. 查看远程仓库及传输协议
    git remote
    git remote -v 查看名称和详细地址

  2. 删除远程仓库
    git remote remove <远程主机名>

  3. 推送本地分支到远程仓库
    git push <远程主机名> <本地分支名>:<远程分支名>
    如果省略远程分支名,则表示将本地分支推送与之存在“追踪关系”的远程分支(通常两者同名), 如果该远程分支不存在,则会被新建 。
    git push origin <本地分支名>
    git push origin master
    如果当前分支与多个主机存在追踪关系,则可以使用-u选项指定一个默认主机,这样以后就可以不加任何参数使用git push。
    git push -u <远程主机名> <本地分支名> 例如:git push -u origin master

  4. 将远程仓库克隆为本地仓库
    git clone git@github.com: xxx/LearnGit.git
    注意:
    (1)不能使用别名
    (2)默认情况下, 从远程clone到本地的库只能看到master分支 ,如果要将远程的分支同步到本地:
    git checkout -b <本地分支名> <远程主机名>/<远程分支名>
    前提是远程<远程主机名>必须存在名为<远程分支名>的分支,而且<本地分支名>和<远程分支名>最好一致。

  5. 本地仓库更新
    将远程存储库中的更改合并到当前分支中。在默认模式下, git pull是 git fetch后跟 git merge FETCH_HEAD的缩写。更准确地说,git pull使用给定的参数运行git fetch,并调用git merge将检索到的分支头合并到当前分支中。 使用–rebase,它运行git rebase而不是git merge。
    以下是一些示例:
    git pull <远程主机名> <远程分支名>:<本地分支名>
    比如,要取回origin主机的next分支,与本地的master分支合并,需要写成下面这样 -
    git pull origin next:master
    如果远程分支(next)要与当前分支合并,则冒号后面的部分可以省略。上面命令可以简写为:
    git pull origin next
    上面命令表示,取回origin/next分支,再与当前分支合并。实质上,这等同于先做git fetch,再执行git merge。
    git fetch origin => git merge origin/next
    在某些场合,Git会自动在本地分支与远程分支之间,建立一种追踪关系(tracking)。比如,在git clone的时候,所有本地分支默认与远程主机的同名分支,建立追踪关系,也就是说,本地的master分支自动“追踪”origin/master分支。Git也允许手动建立追踪关系:
    git branch --set-upstream-to=远程主机名/<远程分支名> <本地分支名>
    比如git branch --set-upstream-to=origin/next master,指定master分支追踪origin/next分支。
    git pull origin
    上面命令表示,本地当前分支自动与对应的origin主机”追踪分支”(remote-tracking branch)进行合并。
    如果当前分支只有一个追踪分支,连远程主机名都可以省略。
    git pull
    上面命令表示,当前分支自动与唯一一个追踪分支进行合并。
    如果合并需要采用rebase模式,可以使用–rebase选项。
    git pull --rebase <远程主机名> <远程分支名>:<本地分支名>

  • git fetch和git pull的区别
    (1) git fetch:相当于是从远程获取最新版本到本地,不会自动合并。
    git fetch origin mastergit log -p master…origin/mastergit merge origin/master
    以上命令的含义:
    首先从远程的origin的master主分支下载最新的版本到origin/master分支上
    然后比较本地的master分支和origin/master分支的差别
    最后进行合并
    上述过程其实可以用以下更清晰的方式来进行:
    git fetch origin master:tmpgit diff tmp git merge tmp
    (2) git pull:相当于是从远程获取最新版本并merge到本地
    git pull origin master
    上述命令其实相当于git fetch 和 git merge
    在实际使用中,git fetch更安全一些,因为在merge前,可以查看更新情况,然后再决定是否合并。
  1. 查看分支
    git branch

  2. 创建分支
    git branch

  3. 创建并切换到分支
    git checkout -b
    备注:git checkout命令加上-b参数表示创建并切换,相当于以下两条命令
    git branch git checkout

  4. 切换分支
    git checkout
    切换分支后,在git bash中显示为绿色

  5. 删除分支
    git branch -d
    如果分支没有合并,删除分支就表示会丢失修改,此时git无法使用-d删除,可使用-D强行删除
    git branch -D

  6. 合并分支
    git合并默认使用Fast forward模式,一旦删除分支,会丢掉分支信息 ,也就看不出来曾经做过合并
    git merge #基于当前分支,合并另外一个分支,前提需要保证分支之间不冲突
    如果强制禁用Fast forward模式,即普通模式,Git就会在merge时生成一个新的commit
    git merge --no-ff -m “there is a comment”
    因为本次合并要创建一个新的commit,所以加上-m参数,把commit描述写进去。
    工作中,肯定需要不管有没有分支被删除,都要从分支历史上就查看所有的历史分支信息,所以要使用普通模式合并。

  7. 创建tag
    (1) git tag #默认在HEAD版本
    (2) 对指定的commit版本创建tag
    需要先找到历史commit的id
    git log --pretty=oneline --abbrev-commit
    然后对指定的commit创建tag:
    git tag
    (3)创建 带有说明的tag,用-a指定标签名,-m指定说明文字
    git tag -a -m “there is a tag description” []
    (4)通过-s 用私钥签名一个标签,签名采用PGP签名
    git tag -s -m “there is a tag description” []
    必须首先安装gpg(GnuPG),如果没有找到gpg,或者没有gpg密钥对,就会报错,参考GnuPG帮助文档配置Key。

  8. 查看tag
    git tag #显示的tag不是按时间顺序排列,而是按字母顺序排列
    如果想查看tag和commit的对应关系,可以用
    git log --pretty=oneline --abbrev-commit
    如果想查看tag的的详细情况,可以用
    git show

  9. 删除tag
    创建的标签都只存储在本地,不会自动推送到远程。所以,打错的标签可以在 本地安全删除:
    git tag -d
    如果标签已经推送到远程,要 删除远程标签就麻烦一点:
    (1)先本地删除: git tag -d
    (2)再远程删除: git push origin :refs/tags/

  10. 推送标签至远程
    git push origin
    或者,一次性推送全部尚未推送到远程的本地标签:
    git push origin --tags

  11. 现场的保存与恢复
    git stash #将目前的工作现场保存
    git stash list #查看所有保存的工作现场
    工作现场还在,Git把stash内容存在某个地方了,但是需要恢复一下,有两个办法:
    一是用 git stash apply stash@{0}恢复,但是恢复后,stash内容并不删除,你需要用 git stash drop stash@{0}来删除;
    另一种方式是用 git stash pop,恢复的同时把stash内容也删了,这种方式省时省力
    注意点:
    (1)如果在分支下新建文件,而尚未执行add操作,stash无法将新文件纳入保存的现场,因为stash只对 被修改的被追踪的文件和 暂存的变更有效, 对于新文件必须先执行add。
    (2)如果修改分支下的已被追踪的文件,不管有没有对修改的文件进行add操作,如果执行stash,所有修改会被纳入保存的现场,而文件会恢复成修改前的状态。恢复现场后,文件又呈现被修改后的状态。 特别的是,如果修改的文件在stash前已经被add了,恢复现场后,暂存区的内容就会清空,相当于这个文件从未被add一样。

  12. 设置Git UI颜色
    让Git显示颜色,会让命令输出看起来更醒目
    git config --global color.ui true

  13. 忽略特殊文件
    (1) 在Git工作区的根目录下创建一个特殊的 .gitignore 文件,然后把要忽略的文件名填进去,Git就会自动忽略这些文件。不需要从头写.gitignore文件,GitHub已经为我们准备了各种配置文件,只需要组合一下就可以使用了。所有配置文件可以直接在线浏览: https://github.com/github/gitignore
    忽略文件的原则是:
    忽略操作系统自动生成的文件,比如缩略图等;
    忽略编译生成的中间文件、可执行文件等,也就是如果一个文件是通过另一个文件自动生成的,那自动生成的文件就没必要放进版本库,比如Java编译产生的.class文件;
    忽略你自己的带有敏感信息的配置文件,比如存放口令的配置文件。
    比如一个完成的 .gitignore文件,内容如下:

 Windows:Thumbs.dbehthumbs.dbDesktop.ini
 Python:*.py[cod]*.so*.egg*.egg-infodistbuild

(2) 把.gitignore也提交到Git
git add .gitignore
git commit -m “there is a description”
就完成了!当然检验.gitignore的标准是git status命令是不是显示working tree clean。
使用Windows的注意:如果在资源管理器里新建一个.gitignore文件,系统会非常弱智地提示必须输入文件名,但是在文本编辑器里“保存”或者“另存为”就可以把文件保存为.gitignore了。

(3)如果确实想要 添加已经被.gitignore忽略的文件,可以用-f强制添加到Git
git add -f test.class

(4)怀疑 .gitignore写的有问题,需要查找哪个规则写错了,可以用git check-ignore命令检查:
git check-ignore -v App.class.gitignore:3:*.class App.class
表示.gitignore的第3行规则忽略了App.class这个文件,于是我们就可以知道应该修订哪个规则。

  1. 为命令配置别名
    (1)命令可以简写,用git st表示git status,再比如用co表示checkout、ci表示commit、br表示branch:
    git config --global alias.co checkoutgit config --global alias.ci commitgit config --global alias.br branch
    以后提交就可以简写成:
    git ci -m “there is a description”
    –global参数是全局参数,也就是这些命令在这台电脑的所有Git仓库下都有用。

(2)命令git reset HEAD 可以 撤销暂存区的修改(unstage),重新放回工作区。既然是一个unstage操作,就可以配置一个unstage别名:
git config --global alias.unstage ‘reset HEAD’
就可以简化命令:
git unstage test.py = git reset HEAD test.py

(3)配置一个git last,让其 显示最后一次提交信息:
git config --global alias.last ‘log -1’
这样,用git last就能显示最近一次的提交:
git lastcommit 015851cbe2902bf01fbba198af5d6705dc0e03ac (HEAD -> dev)
Author: xxx < xxx@foxmail.com>
Date: Mon Apr 23 13:52:44 2018 +0800
add git ignore list

(4)还有把lg配置成了:
git config --global alias.lg “log --color --graph --pretty=format:’%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset’ --abbrev-commit”
来看看 git lg的效果:
在这里插入图片描述

  1. 修改配置文件
    配置Git的时候,加上–global是针对当前用户起作用的,如果不加,那只针对当前的仓库起作用。
    每个仓库的Git配置文件都放在.git/config文件中:
    cat .git/config
[core]
repositoryformatversion = 0
filemode = false
bare = false
logallrefupdates = true
symlinks = false
ignorecase = true
[branch "master"]
[branch "dev"]
[remote "github"]
url = git@github.com: xxx/LearnGit.git
fetch = +refs/heads/*:refs/remotes/github/*
[remote "gitee"]
url = git@gitee.com: xxx/LearnGit.git
fetch = +refs/heads/*:refs/remotes/gitee/*

而当前用户的Git配置文件放在 用户主目录下的一个隐藏文件.gitconfig中:

[user]
name = xxx
email = xxx@foxmail.com
[gpg]
program = C:\\Program Files (x86)\\gnupg\\bin\\gpg.exe
[color]
ui = true
[alias]
co = checkout
ci = commit
br = branch
last = log -1
lg = log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit

别名就在[alias]后面,要删除别名,直接把对应的行删掉即可。配置别名也可以直接修改这个文件,如果改错了,可以删掉文件重新通过命令配置。

1.8 多人协作的工作模式通常如下:

  1. 首先 将远程仓库克隆为本地仓库
    git clone git@github.com: xxx /LearnGit.git
  2. 在本地创建和远程分支对应的分支
    git checkout -b <本地分支名> origin/<远程分支名>
    本地和远程分支的名称最好一致;
  3. 在本地分支完成任务后,可以试图用 git push <远程主机名> <本地分支名>推送自己的修改;
    如果推送失败,则表明远程分支比本地更新(new),需要先用 git pull试图合并;
    如果pull失败并提示“no tracking information”,则说明本地分支和远程分支的链接关系没有创建,用命令 git branch --set-upstream-to=<远程主机名>/<远程分支名> <本地分支名>创建链接;
    如果合并有冲突,则解决冲突,并在本地提交(add => commit);
    没有冲突或者解决掉冲突后,再用 git push <远程主机名> <本地分支名>推送就能成功。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值