版本控制的英文是 Version Control
是维护工程蓝图的标准作法,能追踪工程蓝图从诞生一直到定案的过程
版本控制也是一种软件工程技巧,借此能在软件开发的过程中,确保由不同人所编辑的同一程序文件都得到同步;
简单来说,版本控制在软件开发中,可以帮助程序员进行代码的追踪、维护、控制等等一系列的操作。
对于我们日常开发,我们常常面临如下一些问题,通过版本控制可以很好的解决:
1️⃣ 能够存储管理不同版本:
一个项目会不断进行版本的迭代,来修复之前的一些问题、增加新的功能、需求,甚至包括项目的重构;
如果我们通过手动来维护一系列的项目备份,简直是一场噩梦;
2️⃣ 能够备份维护重大版本:
3️⃣ 能够恢复之前的项目版本:
4️⃣ 能够记录项目的点点滴滴:
5️⃣ 能够合并多人开发的代码:
1️⃣ 版本控制的史前时代(没有版本控制):
diff
命令来对比两个文件的差异;2️⃣ CVS(Concurrent Versions System)
第一个被大规模使用的版本控制工具,诞生于 1985
年;
VU
大学的 Dick Grune
教授实现的,也算是 SVN
的前身( SVN
的出现就是为了取代 CVS
的)。3️⃣ SVN(Subversion)
因其命令行工具名为 SVN
因此通常被简称为 SVN
;
SVN
由 CollabNet
公司于 2000
年资助并发起开发,目的是取代 CVS
,对CVS
进行了很多的优化;
SVN
和 CVS
一样,也属于集中式版本控制工具;
SVN
在早期公司开发中使用率非常高,但是目前已经被 Git
取代;
4️⃣ Git(Linus的作品)
Linux
社区使用的是 BitKeeper
来进行版本控制;
但是因为一些原因,BitKeeper
想要收回对 Linux
社区的免费授权;Linus
用了大概一周的时间,开发了 Git
用来取代 BitKeeper
;Linus
完成了 Git
的核心设计,在之后 Linus
功成身退,将 Git
交由另外一个 Git
的主要贡献者 Junio C Hamano
来维护;CVS
和 SVN
都是属于集中式版本控制系统(Centralized Version Control Systems
,简称 CVCS
)
Git
是属于分布式版本控制系统(Distributed Version Control System
,简称 DVCS
)
客户端并不只提取最新版本的文件快照, 而是把代码仓库完整地镜像下来,包括完整的历史记录;
这么一来,任何一处协同工作用的服务器发生故障,事后都可以用任何 一个镜像出来的本地仓库恢复;
因为每一次的克隆操作,实际上都是一次对代码仓库的完整备份;
电脑上要想使用 Git
,需要先对 Git
进行安装,直接去Git的官网根据自己的操作系统下载 Git
即可;
Bash – CMD – GUI 区别?
在 Windows
中Git
的安装完成后,可以在开始菜单中看到 Git
的三个启动图标 Git Bash
、Git CMD(Deprecated)
、Git GUI
,那个这三个的区别分别是什么呢?
Bash
:Unix shell
的一种,Linux
与 Mac OS X
都将它作为默认 shell
。
Git Bash
就是一个 shell
,是 Windows
下的命令行工具,可以执行 Linux
命令;Git Bash
是基于 CMD
的,在 CMD
的基础上增添一些新的命令与功能;Bash
更加方便;Git CMD
CMD
)是 Windows
操作系统上的命令行解释程序;Windows
上安装 Git
并且习惯使用命令行时,可以使用 cmd
来运行 git
命令;Git GUI
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
中的配置变量。
安装完 Git
之后,要做的第一件事就是设置你的用户名和邮件地址。 这一点很重要,因为每一个 Git
提交都会使用这些信息,它们会写入到你的每一次提交中,不可更改:
sh$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com
强调:如果使用了
--global
选项,那么该命令只需要运行一次,因为之后无论你在该系统上做任何事情,Git
都会使用那些信息;
检测当前的配置信息: git config --list
sh$ 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
并不会在你输入部分命令时自动推断出你想要的命令
如果不想每次都输入完整的 Git
命令,可以通过 git config
文件来轻松地为每一个命令设置一个别名。
shellcoder@coder ~ % git config --global alias.co checkout coder@coder ~ % git config --global alias.br branch coder@coder ~ % git config --global alias.cm commit coder@coder ~ % git config --global alias.st status
例如,我在上面配置了 st
别名,那么我下次想检查 git
状态就可以直接执行 git st
了
shcoder@coder demo % git st
On branch dev
Your branch is ahead of 'origin/dev' by 1 commit.
(use "git push" to publish your local commits)
nothing to commit, working tree clean
如果我们要用 Git
来管理源代码,那么我们就需要有一个 Git
仓库。
通常有两种获取 Git 项目仓库的方式:
方式一:初始化一个Git仓库,并且可以将当前项目的文件都添加到Git仓库中(目前很多的脚手架在创建项目时都会默认创建一个Git仓库);
git init
该命令将创建一个名为 .git
的子目录,这个子目录含有你初始化的 Git
仓库中所有的必须文件,这些文件是 Git
仓库的核心。但是,在这个时候,我们仅仅是做了一个初始化的操作,你的项目里的文件还没有被跟踪;
方式二:从其它服务器 克隆 (clone)
一个已存在的 Git 仓库(第一天到公司通常我们需要做这个操作);
从 Git
远程仓库
shellgit clone https://github.com/coderyjw/jw-ui.git
Git
仓库 将文件状态划分为 未跟踪 和 已跟踪
Git仓库
管理的文件,默认情况下都是未跟踪文件,我们需要通过 add命令 来操作;Git仓库
管理的文件处于已跟踪状态,Git
可以对其进行各种跟踪管理;已跟踪的文件又可以进行细分状态划分:
commit
命令,可以将 staged
中文件提交到 Git
仓库Modified
状态;在工作时,你可以选择性地将这些修改过的文件放入暂存区,然后提交所有已暂存的修改,如此反复;
我们在有 Git
仓库的目录下新建一个文件,查看文件的状态:
git status
Untracked files
:未跟踪的文件
Git
在之前的提交中没有这些文件;Git
不会自动将之纳入跟踪范围,除非你明明白白地告诉它“我需要跟踪该文件”;我们也可以查看更加简洁的状态信息:
git status --short git status --s
左栏指明了暂存区的状态,右栏指明了工作区的状态;
跟踪新文件命令: git add aaa.js
使用命令 git add
开始跟踪一个文件。
跟踪修改的文件命令:
如果我们已经跟踪了某一个文件,这个时候修改了文件也需要重新添加到暂存区中;
此外,可以通过 git add .
将所有的文件添加到暂存区中:
Git
的管理,也不希望它们总出现在未跟踪文件列表。
.gitignore
的文件 ,列出要忽略的文件的模式;Vue
项目自动创建的忽略文件:
现在的暂存区已经准备就绪,可以提交了。
每次准备提交前,先用 git status
看下,你所需要的文件是不是都已暂存起来了;
再运行提交命令 git commit
;
可以在 commit
命令后添加 -m
选项,将提交信息与命令放在同一行;
git commit –m "提交信息"
**如果我们修改文件的 add
操作,加上 commit
的操作有点繁琐,那么可以将两个命令结合来使用: git commit -a -m "修改了bbb文件"**
Git
中所有的数据在存储前都计算校验和,然后以 校验和 来引用。
Git
用以计算校验和的机制叫做 SHA-1
散列(hash,哈希);提交了若干更新,又或者克隆了某个项目之后,有时候我们想要查看一下所有的历史提交记录。
这个时候我们可以使用 git log
命令:
git log
会按时间先后顺序列出所有的提交,最近的更新排在最上面;SHA-1
校验和、作者的名字和电子邮件地址、提交时间以及提交说明;git log
git log --pretty=oneline
git log --pretty=oneline --graph
Git
通过 HEAD指针
记录当前版本。
HEAD
是当前分支引用的指针,它总是指向该分支上的最后一次提交;
理解 HEAD
的最简方式,就是将它看做 该分支上的最后一次提交 的快照;
HEAD
来改变 Git
目前的版本指向:
HEAD^
,上上一个版本就是 HEAD^^
;1000
个版本,我们可以使用 HEAD~1000
;commit id
;shgit reset --hard HEAD^ git reset --hard HEAD~1000 git reset --hard 2d44982
像其他版本控制系统(VCS
)一样,Git
可以给仓库历史中的某一个提交打上标签,以示重要。 比较有代表性的是人们会使用这个功能来标记发布结点( v1.0
、 v2.0
等等)。
列出标签 git tag 可带上可选的 -l 选项 --list
$ git tag v1.0 v2.0
创建标签
Git
支持两种标签:轻量标签 (lightweight)
与附注标签(annotated)
;
附注标签:通过 -a
选项,并且通过 -m
添加额外信息;
git tag v1.0 git tag -a v.1.1 -m "附注标签"
默认情况下,git push
命令并不会传送标签到远程仓库服务器上。 在创建完标签后必须显式地推送标签到共享服务器上,当其他人从仓库中克隆或拉取,他们也能得到那些标签;
git push origin v1.0 git pish origin --tags
删除标签
要删除本地仓库上的标签,可以使用命令 git tag -d <tagname>
git tag -d v1.1 Deleted Tag 'v1.1' (was 9d76105)
要删除远程的 tag
可以通过git push <remote> –delete <tagname>
git push origin --delete v1.1
检出标签
如果想查看某个标签所指向的文件版本,可以使用 git checkout
命令;
通常在检出 tag
的时候还会创建一个对应的分支(分支后续了解);
git checkout v1.0 Note: switching to 'v1.0'
Remote Repository
)呢?
Git
服务器上搭建一个远程仓库;Git
服务器:
Git
服务器:比如 GitHub
、Gitee
、Gitlab
等等;Git
服务;目前比较流行的远程仓库:GitHub、Gitee、自己搭建Gitlab
对于私有的仓库我们想要进行操作,远程仓库会对我们的身份进行验证。如果没有验证,任何人都可以随意操作仓库是一件非常危险的事情;
目前 Git
服务器验证手段主要有 HTTP
和 SSH
两种
HTTP
的凭证存储(Credential Storage
)因为本身 HTTP
协议是无状态的连接,所以每一个连接都需要用户名和密码。如果每次都这样操作,那么会非常麻烦。幸运的是,Git
拥有一个凭证系统来处理这个事情。
下面有一些 Git Crediential
的选项:
cache
模式会将凭证存放在内存中一段时间。 密码永远不会被存储在磁盘中,并且在15分钟后从内存中清除;store
模式会将凭证用明文的形式存放在磁盘中,并且永不过期;Mac
,Git
还有一种 osxkeychain
模式,它会将凭证缓存到你系统用户的钥匙串中(加密的);Windows
,你可以安装一个叫做 Git Credential Manager for Windows
” 的辅助工具;如果你在
2.1
中按照默认的步骤安装 Git,那么这个工具是会默认有的。
SSH
的密钥Secure Shell(安全外壳协议,简称SSH)是一种加密的网络传输协议,可在不安全的网络中为网络服务提供安全的传输环境。
SSH以非对称加密实现身份验证。
其中一种方法是使用自动生成的公钥-私钥对来简单地加密网络连接,随后使用密码认证进行登录。
而更常见的方法是人工生成一对公钥和私钥,通过生成的密钥进行认证,公钥需要放在待访问的电脑之中,而对应的私钥需要由用户自行保管;这样就可以在不输入密码的情况下登录;
选择下面一条命令生成公钥和私钥
shellssh-keygen -t rsa -b 2048 -C “your email" ssh-keygen -t ed25519 -C "your email"
将生成的公钥复制到远程服务器的 SSH公钥
中
git clone https://github.com/coderyjw/jw-ui.git
将代码 push
到远程仓库:将本地仓库的代码推送到远程仓库中;
默认情况下是将当前分支(比如master)push
到 origin
远程仓库的;
git push git push origin master
从远程仓库 fetch
代码:从远程仓库获取最新的代码
origin
中获取代码;git fetch git fetch origin
merge
来合并;git merge
pull
代码:上面的两次操作有点繁琐,我们可以通过一个命令来操作
远程仓库的交互git pull git fetch + git merge(rebase)
Git
操作的流程图如下:
Remote Repo
, Alice
和 Bob
通过 git clone
命令将远程仓库克隆到他们各自本地的电脑仓库上。 (Alice‘s Local Repo 和 Bob‘s Local Repo)Alice
在本地文件夹 Working Directory
新建一份文件,此时文件处于未跟踪状态Alice
通过 git add
命令添加到 Index
索引中跟踪文件,此时文件处于已跟踪 staged
状态。Alice
修改文件,进入 Modified
状态, 再执行 git add
命令进入 staged
状态Alice
多次修改并且 git add
后,执行 git commit
命令,将 staged
中文件提交到 .git Directory
,此时进入 Unmodified
状态Alice
执行 git push
命令 将本地仓库代码提交到远程仓库Bob
执行 git pull
命令,拉取远程仓库最新的代码到本地Bob
也可以按照 1-6 的步骤修改文件提交代码这样持续开发下去
Git
创建一个新分支就只是创建了一个可以移动的新的指针
比如创建一个 testing
分支, 需要使用 git branch
命令
git branch testing
Git
通过一个名为 HEAD
的特殊指针知道当前在哪一个分支上,可以通过 git checkout
命令切换分支。
通常我们会想创建一个新分支后立即切换过去。这可以用 git checkout -b <newbranchname>
一条命令搞定;
实际场景:
master
上进行开发;tag v1.0.0
;tag v1.0.0
的版本,并且创建一个分支 hotfix
;bug
tag v1.0.1
;master
分支,但是这个时候 master
分支也需要修复刚刚的 bug
master
分支和 hotfix
分支进行合并;如果我们希望查看当前所有的分支,可以通过以下命令:
git branch # 查看当前所有的分支 git branch –v # 同时查看最后一次提交 git branch --merged # 查看所有合并到当前分支的分支 git branch --no-merged # 查看所有没有合并到当前分支的分支
如果某些已经合并的分支我们不再需要了,那么可以将其移除掉:
git branch –d hotfix # 删除当前分支 git branch –D hotfix # 强制删除某一个分支
推送分支到远程
git push <remote> <branch>
跟踪远程分支
克隆一个仓库时,它通常会自动地创建一个跟踪 origin/master
的 master
分支;
如果检出的分支(a)
不存在且(b)
刚好只有一个名字与之匹配的远程分支,那么 Git
就会创建一个跟踪分支;
git checkout --track <remote>/<branch> # 设置跟踪分支 git checkout <branch>
删除远程分支
如果某一个远程分支不再使用,我们想要删除掉,可以运行带有 --delete
选项的 git push
命令来删除一个远程分支。
git push origin --delete <branch>
在 Git 中整合来自不同分支的修改主要有两种方法:merge
以及 rebase
。
什么是 rebase
?
在上面的图例中,你可以提取在 C4
中引入的补丁和修改,然后在 C3
的基础上应用一次;
Git
中,这种操作就叫做 变基(rebase);rebase
命令将提交到某一分支上的所有修改都移至另一分支上,就好像“重新播放”一样;rebase
这个单词如何理解呢?
base
;experiment
上执行 rebase master
,那么可以改变 experiment
的 base
为 master
git checkout experiment git rebase master
rebase
的原理
rebase
的原理是首先找到这两个分支(即当前分支 experiment
、变基操作的目标基底分支 master
) 的最近共同祖先 C2
;C3
;再次执行 master
上的合并操作
git checkout master git merge experiment
rebase
和 merge
的选择
merge
用于记录 git
的所有历史,那么分支的历史错综复杂,也全部记录下来
rebase
用于简化历史记录,将两个分支的历史简化,整个历史更加简洁
了解了rebase的底层原理,就可以根据自己的特定场景选择merge或者rebase。
注意:
rebase
有一条黄金法则:永远不要在主分支上使用rebase
如果在
main
上面使用rebase
,会造成大量的提交历史在main
分支中不同;而多人开发时,其他人依然在原来的
main
中,对于提交历史来说会有很大的变化;
本文作者:叶继伟
本文链接:
版权声明:本博客所有文章除特别声明外,均采用 BY-NC-SA 许可协议。转载请注明出处!