[开发工具]Git版本控制系统

一、版本控制和Git

1、关于版本控制

版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。有了它你就可以将选定的文件回溯到之前的状态，甚至将整个项目都回退到过去某个时间点的状态，你可以比较文件的变化细节，查出最后是谁修改了哪个地方，从而找出导致怪异问题出现的原因，又是谁在何时报告了某个功能缺陷等等。 使用版本控制系统通常还意味着，就算你乱来一气把整个项目中的文件改的改删的删，你也照样可以轻松恢复到原先的样子。 但额外增加的工作量却微乎其微。

Git必看秘籍:https://git-scm.com/book/zh/v2

本地版本控制系统

采用某种简单的数据库来记录文件的历次更新差异。
其中最流行的一种叫做 RCS，现今许多计算机系统上都还看得到它的踪影。 RCS 的工作原理是在硬盘上保存补丁集（补丁是指文件修订前后的变化）；通过应用所有的补丁，可以重新计算出各个版本的文件内容。

集中化的版本控制系统
集中化的版本控制系统，诸如 CVS、Subversion 以及 Perforce 等，有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。

每个人都可以在一定程度上看到项目中的其他人正在做些什么。 而管理员也可以轻松掌控每个开发者的权限，并且管理一个 CVCS 要远比在各个客户端上维护本地数据库来得轻松容易。

事分两面，有好有坏。 这么做最显而易见的缺点是中央服务器的单点故障。 如果宕机一小时，那么在这一小时内，谁都无法提交更新，也就无法协同工作。 如果中心数据库所在的磁盘发生损坏，又没有做恰当备份，毫无疑问你将丢失所有数据——包括项目的整个变更历史，只剩下人们在各自机器上保留的单独快照。 本地版本控制系统也存在类似问题，只要整个项目的历史记录被保存在单一位置，就有丢失所有历史更新记录的风险。
分布式版本控制系统
客户端并不只提取最新版本的文件快照， 而是把代码仓库完整地镜像下来，包括完整的历史记录。 这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。 因为每一次的克隆操作，实际上都是一次对代码仓库的完整备份。

许多这类系统都可以指定和若干不同的远端代码仓库进行交互。借此，你就可以在同一个项目中，分别和不同工作小组的人相互协作。

2、什么是Git？

Git
有三种状态:已提交(committed)、已修改(modified) 和 已暂存(staged)。

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

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

直接记录快照，而非差异比较
Git 和其它版本控制系统的主要差别在于 Git 对待数据的方式。 从概念上来说，其它大部分系统以文件变更列表的方式存储信息，这类系统 将它们存储的信息看作是一组基本文件和每个文件随时间逐步累积的差异 （它们通常称作 基于差异（delta-based） 的版本控制）。

Git 不按照以上方式对待或保存数据。反之，Git 更像是把数据看作是对小型文件系统的一系列快照。 在 Git 中，每当你提交更新或保存项目状态时，它基本上就会对当时的全部文件创建一个快照并保存这个快照的索引。 为了效率，如果文件没有修改，Git 不再重新存储该文件，而是只保留一个链接指向之前存储的文件。== Git 对待数据更像是一个 快照流。==
近乎所有操作都是本地执行
在 Git 中的绝大多数操作都只需要访问本地文件和资源，一般不需要来自网络上其它计算机的信息。 如果你习惯于所有操作都有网络延时开销的集中式版本控制系统，Git 在这方面会让你感到速度之神赐给了 Git 超凡的能量。 因为你在本地磁盘上就有项目的完整历史，所以大部分操作看起来瞬间完成。

二、操作Git版本控制系统

安装git

yum install -y git
mkdir demo
cd demo
git --help

初始化git

cd demo
git init

初始化后将创建一个名为.git的子目录，这个子目录含有初始化的 Git 仓库中所有的必须文件，这些文件是 Git 仓库的骨干。 但这仅仅是做了初始化的操作，项目里的文件还没有被跟踪。

使用git

使用git命令提交更新时需要先注册用户信息

用户信息
git config --global user.name "bing"
git config --global user.email bing@westos.org

说明你现在的工作目录相当干净。所有已跟踪文件在上次提交后都未被更改过。还表明，当前目录下没有出现任何处于未跟踪状态的新文件，否则 Git 会在这里列出来。显示了当前所在分支，分支名是“master”,这是默认的分支名。

创建一个新的文件

检查文件当前状态

在状态报告中可以看到新建的 README 文件出现在 Untracked files 未跟踪文件下面。
未跟踪文件意味着 Git 在之前的快照（提交）中没有这些文件；Git 不会自动将之纳入跟踪范围

跟踪新文件
用命令 git add 开始跟踪一个文件。

此时提交，该文件会在你运行 git add 时的版本将被留存在后续的历史记录中。git add 命令使用文件或目录的路径作为参数；如果参数是目录的路径，该命令将递归地跟踪该目录下的所有文件。

暂存已修改的文件
修改一个已经被跟踪的文件

检查文件状态

已跟踪文件的内容发生了变化，但还没有放到暂存区。 要暂存这次更新，需要运行 git add 命令。 这是个多功能命令：可以用它开始跟踪新文件，或者把已跟踪的文件放到暂存区，还能用于合并时把有冲突的文件标记为已解决状态等。 将这个命令理解为“精确地将内容添加到下一次提交中”而不是“将一个文件添加到项目中”要更加合适。

运行 git add 将“README.md”放到暂存区，检查文件状态

现在两个文件都已暂存，下次提交时就会一并记录到仓库。

从中可以看到提交的是修改之前的文件。文件同时出现在暂存区和非暂存区，实际上 Git 只不过暂存了你运行 git add 命令时的版本。所以，运行了 git add 之后又作了修订的文件，需要重新运行 git add 把最新版本重新暂存起来。

提交给主机（注意：提交之前需要检查是否存在已修改未提交的文件，若有，需要执行git add命令将其添加）

提交更新

暂存区准备就绪就可以提交了。 在此之前，请务必确认还有什么已修改或新建的文件还没有 git add 过， 否则提交的时候不会记录这些尚未暂存的变化。 这些已修改但未暂存的文件只会保留在本地磁盘。 所以，每次准备提交前，先用 git status 看下，你所需要的文件是不是都已暂存起来了， 然后再运行提交命令 git commit。

可以看到，提交后它会告诉你，当前是在哪个分支（master）提交的，本次提交的完整 SHA-1 校验和是什么（463dc4f），以及在本次提交中，有多少文件修订过，多少行添加和删改过。

注意：提交时记录的是放在暂存区域的快照。 任何还未暂存文件的仍然保持已修改状态，可以在下次提交时纳入版本管理。 每一次运行提交操作，都是对你项目作一次快照，以后可以回到这个状态，或者进行比较。

方法一：

git commit -m "add 文件名"

方法二：

git commit 文件名

会出现以下界面。类似vim浏览模式。在最上部可以添加注释内容，标注这次修改的内容，便于下次需要的时候查看

退出编辑模式后，在提交提示中会显示自定义编辑过的修改信息

状态简览

输出中有两栏，左栏指明了暂存区的状态，右栏指明了工作区的状态。

M  lib/simplegit.rb		#已修改且已暂存
 M README		#在工作区已修改但尚未暂存
MM Rakefile		#文件已修，暂存后又作了修改，因此该文件的修改中既有已暂存的部分，又有未暂存的部分

跳过使用暂存区域

移除文件

要从 Git 中移除某个文件，就必须要从已跟踪文件清单中移除（确切地说，是从暂存区域移除），然后提交。 可以用 git rm 命令完成此项工作，并连带从工作目录中删除指定的文件，这样以后就不会出现在未跟踪文件清单中了。
简单的删除：

git rm 后

下一次提交时，该文件就不再纳入版本管理了。 如果要删除之前修改过或已经放到暂存区的文件，则必须使用强制删除选项 -f。 这是一种安全特性，用于防止误删尚未添加到快照的数据，这样的数据不能被 Git 恢复。

查看已暂存和未暂存的修改

git diff

分别修改两个文件

将readme.md添加到暂存区，检查文件状态


该命令查看的是已修改未暂存文件的修改内容，比较的是工作目录中当前文件和暂存区域快照之间的差异。

注意，git diff 本身只显示尚未暂存的改动，而不是自上次提交以来所做的所有改动。

git diff --staged

该命令查看的是已修改已暂存文件的修改内容，即已暂存的将要添加到下次提交里的内容，比对已暂存文件与最后一次提交的文件差异

git diff --staged=--cached

重命名文件

git mv README.md README
其实,运行 git mv 就相当于运行了下面三条命令:
mv README.md README
git rm README.md
git add README

查看提交历史

git log查看所有提交历史
git log -p -2查看前2条提交历史
git log --stat查看提交历史的详细信息

取消暂存的文件

git reset HEAD README.md

撤消对文件的修改

git checkout -- README.md

版本回退

git reflog
git reset --hard efa267a

三、gitlab代码仓库

gitlab安装

缺少依赖性，需要安装依赖性，使用yum命令

yum install -y gitlab-ce-14.4.0-ce.0.el7.x86_64.rpm

vim /etc/gitlab/gitlab.rb
---
external_url 'http://172.25.0.11'
#访问gitlab的地址
---

gitlab-ctl reconfigure #重载服务该过程需要一定的时间，需要耐心等待。（但其实挺快的了）

登录gitlab http://172.25.0.11 用户:root 第一次登录需要强制修改密码

gitlab使用
修改页面显示的语言

新建项目


添加SSH密匙

ssh-keygen
cat /root/.ssh/id_rsa.pub

使用git

cd demo/
推送本地仓库内容到github:
git remote add origin https://github.com/westos007/git.git		#关联远程仓库
git push -u origin master --all是推送所有		#第一次推送需要加 -u参数

克隆远程仓库
找到远程克隆仓库的链接并复制

git clone git@172.25.76.5:root/demo.git

删除项目
菜单–>管理员–>项目–>删除

四、今日报错

1、gitlab忘记密码，我真的天拉鲁，找到的可行修改密码方法：
在装有gitlab主机上

#进入控制台
su - git
输入su - git 切换到git用户下操作，切换之后默认的当前目录就可以ls查看到gitlab的命令文件，下一步会使用此文件进入控制台

#执行命令
root@d3b78b4b8d24:/# gitlab-rails console
Loading production environment (Rails 4.2.8)
 
#查找用户

irb(main):001:0> user = User.where(id:1).first	#修改root用户
=> #<User id:1 @root>
irb(main):001:0> user = User.where(username: 'bing').first	#修改普通用户
=> #<User id:5 @bing>
 
#修改密码
irb(main):002:0> user.password = 'westos'
=> "westos"
 
#保存修改
irb(main):003:0> user.save!
Enqueued ActionMailer::DeliveryJob (Job ID: 3add15ae-5e56-45ee-a081-564f397c9897) to Sidekiq(mailers) with arguments: "DeviseMailer", "password_change", "deliver_now", gid://gitlab/User/5
=> true
 
#ctrl+d退出
irb(main):004:0>
-sh-4.2$ logout

输入修改后的密码即可登陆

2、推送所有文件至gitlab失败
报错解读：远程主机包含本地没有的更新，即远端与本地文件不同步，导致推送失败

解决方案：删除本地的仓库目录，克隆远端仓库到本地，再次添加上传推送文件即可