2.Git docs学习笔记

1.1 起步-关于版本控制

  • 什么是版本控制系统(version control system.VCS)?
    版本控制是一种记录一个或者若干个文件内容的变化,以便将来查阅特定版本修改情况的系统。版本控制系统可以对任何类型的文件进行版本控制,但大多数情况下开发者是对源代码文件作版本控制。
  • 有哪些类型的版本控制系统?
    • 本地版本控制系统

      它的工作原理是在硬盘上保存补丁集,所谓补丁是指文件修订前后的变化;通过应用所有的补丁,可以重新计算出各个版本的内容。
    • 集中式版本控制系统
      本地版本控制系统只适用于单个开发者。
      遇到需要多个开发者协同工作的时候,本地版本控制系统就没用了。于是集中式的版本控制系统(centralized version control system,CVCS)应运而生。这类系统,诸如CVS,Subveision,Perforce等,都有一个单一的几种管理的服务器,保存所有文件的修订版本,而协同工作的人们都通过客户端连接到这一台服务器,取出最心底额文件或者提交更新,多年以来,这已经成为版本控制系统的标准做法。

      这种做法带来了很多好好粗,特别是相对于老式的本地CVS来说。每个人都可以在一定程度智商看到项目中其他人在做什么。而管理员也可以轻松掌握每个开发者的权限,并且管理一个cvcs要远比在各个客户端上维护本地数据库来的轻松容易。
      这种做法最显而易见的缺点是中央服务器的故障,如果宕机一小时,那么在这一小时内,谁都无法更新,也都无法协同工作。如果中心数据库磁盘发生损坏,又没有做恰当备份,毫无疑问,将丢失所有的数据-包括项目的真个变更历史,只剩下各自机器上保留的单独快照。本地版本控制也存在这样的问题,只要项目的历史记录都被保存在同一个位置,就会有丢失所有历史记录的风险。
    • 分布式版本控制系统
      于是分布式版本控制系统(distributed version control system,DVCS)面世了,在这类系统中,像Git,Mercurial,Bazar,darcs等,客户端并不只提取最新版本的文件快照,而是把整个代码仓库完整的镜像下来,这么一来,任何一处系统工作用的服务器发生故障,事后都可以 用任何一个镜像出来的本地仓库恢复,因为每一次克隆操作都是一次对代码仓库的完整备份。

1.2 起步-Git简史

同生活中很多伟大的事物一样,Git诞生于一个极富纷争大举创新的时代。
Linux内核开源项目有着为数众多的参与者,绝大多数Linux内核维护工作都花在提交补丁和保存归档的繁琐事务上(1991-2002年间)、到2002年,整个项目组开始启动一个专有的分布式版本控制系统Bitkeeper来管理和维护代码。
到了2005年,开发bitkeeper的商业公司同Linux内核开源社区的合作关系结束,他们收回了Linux内核社区免费试用bitkeepr的权力,这就迫使Linux开源社区特别是Linux的缔造者linus torvalds基于bitkeeper是的经验与教训,开发出自己的版本控制系统,他们对新的系统制定了若干目标:

  • 速度
  • 简单的设计
  • 对非线性开发模式的强力支持
  • 完全分布式
  • 有能力高效管理类似Linux内核一样的超大规模的项目

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

1.3 起步-Git基础

Git和其他版本控制系统的主要差别在于对待数据的方法。其他系统将他们保存的信息看作是一组基本文件和每个文件随时间逐步积累的差异。

而Git不按照以上方式对待或者保存数据,Git对待数据更像是一个快照流

  • 近乎所有操作都可以本地执行
  • Git保证完整性
    Git的所有数据在存储之前都计算校验和,然后以校验和来引用,这意味着不可以在Git不知情的情况下,更改任何文件或者目录内容,这个功能建构再给他底层,是构成Git哲学不可或缺的部分,若你在传送过程中,中丢失信息或损坏文件,Git就能发现。
    Git用以计算校验和的机制叫做SHA-1散列(hash,哈希)。这是一个由四十个十六进制字符组成的字符串,基于Git文件的内容或者目录计算出来。SHA-1看起来是这样:

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

  • Git一般只添加数据
    你执行的Git操作 ,几乎只往Git数据库中添加数据。很难让Git执行任何不可逆操作,或者让他以任何方式清除数据。同别的vcs一样,未提交更新时有可能丢失或弄乱修改的内容,但是一旦你提交快照到Git中,就难以再丢失数据,特别是,你定期的推送数据库到其他的数据库的话。
    这使得我们使用Git成为一个安心愉悦的过程,因为我们甚至可以尽情的做各种尝试,而没有把事情弄糟的风险。
  • 三种状态
    Git有三种状态,你的文件可以处于其中之一,已提交(commited),已修改(modified),和已暂存(staged)。

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

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

暂存区域是一个文件,保存了下次将提交的文件列表信息,一般在 Git 仓库目录中。 有时候也被称作`‘索引’’,不过一般说法还是叫暂存区域。

基本的 Git 工作流程如下:

  • 在工作目录中修改文件。

  • *暂存文件,将文件的快照放入暂存区域。

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

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

1.4 起步-命令行

1.5 起步-安装Git

1.6 初次运行Git前的配置

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

–system 此电脑
–global 此用户
–local 此仓库

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

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

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

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

  • 用户信息
    当安装完 Git 应该做的第一件事就是设置你的用户名称与邮件地址。 这样做很重要,因为每一个 Git 的提交都会使用这些信息,并且它会写入到你的每一次提交中,不可更改:

git config –global user.name “John Doe”
git config –global user.email johndoe@example.com

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

  • 文本编辑器
    既然用户信息已经设置完毕,你可以配置默认文本编辑器了,当 Git 需要你输入信息时会调用它。 如果未配置,Git 会使用操作系统默认的文本编辑器,通常是 Vim。 如果你想使用不同的文本编辑器,例如 Emacs,可以这样做:

git config –global core.editor emacs

  • 检查配置信息
    如果想要检查你的配置,可以使用 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

1.7 获取帮助

三种方式:

  • git help config

  • git config –help

  • man git-config

  • q quit

1.8 总结

2.1Git基础-获取Git仓库

  • 在现有的目录中初始化仓库

    git init
    仅仅完成初始化的操作,项目的文件还没有被追踪。
    如果是一个已经存在的非空文件夹中初始化Git仓库来进行版本控制的话,应该开始追踪(add)这些文件并提交(commit)。
    git init
    git add *.c
    git add LICENSE
    git commit -m “initial project version”

  • 克隆现有的仓库

    git clone url
    当前目录新建仓库名文件夹,初始化.git文件夹,从元车行仓库拉取下所有数据放入.git文件夹,然后从中读取最新版本的文件的拷贝。
    也可以自己自定义本地仓库的名字:
    git clone url myrepository

  • git支持多种数据传输协议,http://, git:// ssh传输协议

2.2 Git基础-记录每次更新到数据库


untracked(已创建,未追踪)
changes to be commited (已经暂存staged,未提交commited)
Changes not staged for commit (未暂存not staged)

Git add:可以用它开始跟踪新文件,或者把已跟踪的文件放到暂存区,还能用于合并时把有冲突的文件标记为已解决状态

2.3Git基础-查看提交历史

git log查看提交历史

2.4 Git基础 撤销操作

git commit –amend 重新提交 覆盖上次提交信息

git reset HEAD file_name 撤销暂存

git checkout file_name 撤销修改

2.5Git基础-远程仓库的使用

git remote
git remote -v
  • q 退出

  • git config –help

  • git help config

  • man git-config


转载请注明来源,欢迎对文章中的引用来源进行考证,欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论,也可以邮件至 rat_racer@qq.com

×

喜欢就点赞,疼爱就打赏