Git | 查漏补缺

本贴最后更新于 1498 天前,其中的信息可能已经时移世改

Git 与其他的版本控制工具的差异

Git 和其他版本控制系统的主要差别在于,Git 只关心文件数据的整体是否发生变化,而大多数其他系统则只关心文件内容的具体差异。

Git 并不保存这些前后变化的差异数据。实际上,Git 更像是把变化的文件作快照后,记录在一个微型的文件系统中。每次提交更新时,它会纵览一遍所有文件的指纹信息并对文件作一快照,然后保存一个指向这次快照的索引。为提高性能,若文件没有变化,Git 不会再次保存,而只对上次保存的快照作一连接。Git 的工作方式就像图所示:
image.png

三种状态

对于任何一个文件,在 Git 内都只有三种状态:已提交(committed),已修改(modified)和已暂存(staged)。已提交表示该文件已经被安全地保存在本地数据库中了;已修改表示修改了某个文件,但还没有提交保存;已暂存表示把已修改的文件放在下次提交时要保存的清单中。

三个工作区域

Git 的本地数据目录,工作目录以及暂存区域。
image.png

工作流程

  1. 在工作目录中修改某些文件。

  2. 对这些修改了的文件作快照,并保存到暂存区域。

  3. 提交更新,将保存在暂存区域的文件快照转储到 git 目录中。

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

git diff

git diff 比较的是工作目录中当前文件和暂存区域快照之间的差异,而不是这次工作和上次提交之间的差异。所以有时候一下子暂存了所有更新过的文件后,运行 git diff 后却什么也没有,就是这个原因。

git commit -a -m "提交说明"

git commit 加上-a 参数可以使得被修改的文件(前提是该文件已经被追踪过)跳过暂存区直接提交。

移除文件

要从 Git 中移除某个文件,就必须要从已跟踪文件清单中移除(确切地说,是从暂存区域移除),然后提交。可以用 git rm 命令完成此项工作,并连带从工作目录中删除指定的文件,这样以后就不会出现在未跟踪文件清单中了。不要手工的去删除一个文件,这样删除后 git 会显示该文件未被暂存,此时还需一次 git add 或执行 git rm

如果删除之前修改过并且已经放到暂存区域的话,则必须要用强制删除选项 -f(译注:即 force 的首字母),以防误删除文件后丢失修改的内容。

另外一种情况是,我们想把文件从 Git 仓库中删除(亦即从暂存区域移除),但仍然希望保留在当前工作目录中。换句话说,仅是从跟踪清单中删除。比如一些大型日志文件或者一堆 .a 编译文件,不小心纳入仓库后,要移除跟踪但不删除文件,以便稍后在 .gitignore 文件中补上,用 --cached 选项即可:
git rm --cached 已暂存文件

移动文件

利用 git mv file filemv 命令去移动文件,它相当于这几步:

mv file filemv  //先移动文件
git rm file  //移除之前的文件
git add filemv   //追踪移动后的文件

git log

利用 git log 查看提交历史,没有任何参数的时候展示所有历史,最近的更新位于最上面。

  • -p :展开显示每次提交的内容差异
  • -n :仅显示最近的 n 次更新
  • --stat:仅显示简要的增改行数统计

git commit --amend

  • 如果某次 commit 以后发现提交的说明写错,那么就可以执行 git commit --amend 对该次提交的说明进行修改
  • 如果某次 commit 以后发现,此次提交漏了几个还没有追踪的文件(本来想要一起提交)那么:可以先用 git add 文件,再用 git commit --amend。这样三条命令(算上第一个 commit)最终得到一个提交,第二个提交命令修正了第一个的提交内容

git reset HEAD

利用 git reset HEAD 文件 可以取消已经暂存的文件为未暂存。

git checkout --

利用 git checkout -- 文件 可以取消已经修改的文件为未修改。(回到上一个提交的版本)

添加远程仓库

git remote add [shortname] [url]
为撒我以前一直以为[shortname] 是固定的 origin???!!!!

协议

Git 可以使用四种主要的协议来传输数据:本地传输,SSH 协议,Git 协议和 HTTP 协议。

  • 本地协议
    最基础的就是 本地协议(Local protocol) 了,远程仓库在该协议中就是硬盘上的另一个目录。这常见于团队每一个成员都对一个共享的文件系统(例如 NFS )拥有访问权,抑或比较少见的多人共用同一台电脑的时候。后者不是很理想,因为你所有的代码仓库实例都储存在同一台电脑里,增加了灾难性数据损失的可能性。如果你使用一个共享的文件系统,就可以在一个本地仓库里克隆,推送和获取。要从这样的仓库里克隆或者将其作为远程仓库添加现有工程里,可以用指向该仓库的路径作为 URL。
    image.png

  • SSH 协议
    Git 使用的传输协议中最常见的可能就是 SSH 了。这是因为大多数环境已经支持通过 SSH 对服务器的访问——即使还没有,也很容易架设。SSH 也是唯一一个同时便于读和写操作的网络协议。另外两个网络协议(HTTP 和 Git)通常都是只读的,所以虽然二者对大多数人都可用,但执行写操作时还是需要 SSH。SSH 同时也是一个验证授权的网络协议;而因为其普遍性,通常也很容易架设和使用。
    image.png

  • Git 协议
    这是一个包含在 Git 软件包中的特殊守护进程; 它会监听一个提供类似于 SSH 服务的特定端口(9418),而无需任何授权。用 Git 协议运营仓库,你需要创建 git-export-daemon-ok 文件——它是协议进程提供仓库服务的必要条件——但除此之外该服务没有什么安全措施。要么所有人都能克隆 Git 仓库,要么谁也不能。这也意味着该协议通常不能用来进行推送。你可以允许推送操作;然而由于没有授权机制,一旦允许该操作,网络上任何一个知道项目 URL 的人将都有推送权限。不用说,这是十分罕见的情况。

    • 优点
      Git 协议是现存最快的传输协议。如果你在提供一个有很大访问量的公共项目,或者一个不需要对读操作进行授权的庞大项目,架设一个 Git 守护进程来供应仓库是个不错的选择。它使用与 SSH 协议相同的数据传输机制,但省去了加密和授权的开销。
    • 缺点
      Git 协议消极的一面是缺少授权机制。用 Git 协议作为访问项目的唯一方法通常是不可取的。一般做法是,同时提供 SSH 接口,让几个开发者拥有推送(写)权限,其他人通过 git:// 拥有只读权限。 Git 协议可能也是最难架设的协议。它要求有单独的守护进程,需要定制,而这就没那么平易近人了。该协议还要求防火墙开放 9418 端口,而企业级防火墙一般不允许对这个非标准端口的访问。大型企业级防火墙通常会封锁这个少见的端口。
  • HTTP/S 协议
    HTTP 或 HTTPS 协议的优美之处在于架设的简便性。基本上, 只
    需要把 Git 的纯仓库文件放在 HTTP 的文件根目录下,配置一个特定的 post-update 挂钩(hook),就搞定了(Git 挂钩的细节见第七章)。从此,每个能访问 Git 仓库所在服务器上的 web 服务的人都可以进行克隆操作。

    • 优点
      使用 HTTP 协议的好处是易于架设
    • 缺点
      HTTP 协议的消极面在于,相对来说客户端效率更低。克隆或者下载仓库内容可能会花费更多时间,而且 HTTP 传输的体积和网络开销比其他任何一个协议都大。因为它没有按需供应的能力——传输过程中没有服务端的动态计算——因而 HTTP 协议经常会被称为 傻瓜(dumb) 协议。
  • Git

    Git 是 Linux Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。

    204 引用 • 357 回帖 • 1 关注

相关帖子

欢迎来到这里!

我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。

注册 关于
请输入回帖内容 ...