1.1 GIT教程笔记之基本概念和管理修改

最新推荐文章于 2023-09-23 23:47:31 发布

剑雨巍巍

最新推荐文章于 2023-09-23 23:47:31 发布

阅读量177

点赞数

分类专栏： GIT 文章标签： git

原文链接：https://www.liaoxuefeng.com/wiki/896043488029600/900785521032192

版权

GIT 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

文章目录

概述
- 集中式与分布式版本控制系统
安装
基本概念
工作区和暂存区
管理修改

概述

参考链接：https://www.liaoxuefeng.com/wiki/896043488029600
廖雪峰博客教程
分布式版本控制系统
来源：Linux（服务器系统软件）的编写
SVN等版本控制系统速度慢，且要联网才能使用
Linus两周用C写了分布式版本控制系统，即GIT，牛的

集中式与分布式版本控制系统

集中式版本控制系统
- 版本库集中存放在中央服务器中
- 从远程拿，本地改完再推送给远程
分布式版本控制系统
- 每个人电脑都是完整的版本库，不需要联网了，且谁的版本库坏了不要紧，从其他人那里复制就好了
- 也有中央服务器，不过中央服务器的电脑仅仅是方便大家的修改，互相看得见

安装

Linux系统：sudo apt-get install git
Mac安装：从App Store安装Xcode，然后安装GIT或者homebrew安装，推荐的
window：下载安装程序安装
设置账号密码

$ git config --global user.name "Your Name"
$ git config --global user.email "email@example.com"

git config命令的–global参数表示机器上所有的Git仓库都使用这个配置
也可以对某个仓库指定不同的用户名和Email地址

基本概念

版本库：即仓库，repository，简化理解为目录，目录下所有文件可被管理到
创建版本库

$ mkdir learngit
$ cd learngit
$ pwd
/Users/michael/learngit
 git init     # 把目录变成Git可以管理的仓库

多了.git的目录，这个目录是Git来跟踪管理版本库的
目录默认是隐藏的，用ls -ah命令就可以看见

非必要说明

可跟踪文本文件的改动，而图片，视频等二进制文件只能知道图片大小变了，具体怎么变不知道，而文本文件可知道修改了第几行
Word也是二进制文件，所以没法追踪改动
window自带的记事本有个问题：当保存UTF-8编码的文件，他们自作聪明地在每个文件开头添加了0xefbbbf（十六进制）的字符，会遇到很多不可思议的问题，比如，网页第一行可能会显示一个“?”，明明正确的程序一编译就报语法错误，等等，都是由记事本的弱智行为带来的

add

git add readme.txt
git add file2.txt file3.txt

git commit告诉Git，把文件提交到仓库

git commit -m “wrote a readme file”

时光穿梭

修改readme,运行git status

git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   readme.txt

no changes added to commit (use "git add" and/or "git commit -a")

git status命令可以让我们时刻掌握仓库当前的状态
告诉我们，readme.txt被修改过了，但还没有准备提交的修改
若记不清上次怎么修改的readme.txt，用git diff这个命令看看

$ git diff readme.txt 
diff --git a/readme.txt b/readme.txt
index 46d49bf..9247db6 100644
--- a/readme.txt
+++ b/readme.txt
@@ -1,2 +1,2 @@
-Git is a version control system.
+Git is a distributed version control system.
 Git is free software.

git diff顾名思义就是查看difference，显示的格式正是Unix通用的diff格式，可以从上面的命令输出看到，我们在第一行添加了一个distributed单词
执行以下命令

git add readme.txt
在执行第二步git commit之前，我们再运行git status看看当前仓库的状态：

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	modified:   readme.txt

git status告诉我们，将要被提交的修改包括readme.txt，下一步，就可以放心地提交了：

$ git commit -m "add distributed"
[master e475afc] add distributed
 1 file changed, 1 insertion(+), 1 deletion(-)

提交后，我们再用git status命令看看仓库的当前状态：

$ git status
On branch master
nothing to commit, working tree clean

Git告诉我们当前没有需要提交的修改，而且，工作目录是干净（working tree clean）的

commit和log

每当你觉得文件修改到一定程度的时候，就可以“保存一个快照”，这个快照在Git中被称为commit。一旦你把文件改乱了，或者误删了文件，还可以从最近的一个commit恢复，然后继续工作，而不是把几个月的工作成果全部丢失
git log命令显示从最近到最远的提交日志
嫌输出信息太多,可以加上–pretty=oneline参数

$ git log --pretty=oneline
1094adb7b9b3807259d8cb349e7df1d4d6477073 (HEAD -> master) append GPL
e475afc93c209a690c39c13a46716e8fa000c366 add distributed
eaadf4e385e865d25c48e7ca9c8395c3f7dfaef0 wrote a readme file

类似1094adb的是commit id（版本号）
和SVN不一样，Git的commit id不是递增数字，而是SHA1计算出来的一个非常大的数字，用十六进制表示。
为什么commit id需要用这么一大串数字表示呢？因为Git是分布式的版本控制系统，后面我们还要研究多人在同一个版本库里工作，如果大家都用1，2，3……作为版本号，那肯定就冲突了
启动时光穿梭机，准备把readme.txt回退到上一个版本
首先，Git必须知道当前版本是哪个版本，在Git中，用HEAD表示当前版本，也就是最新的提交1094adb…
上一个版本就是HEAD^{，上上一个版本就是HEAD}^{，当然往上100个版本写100个}比较容易数不过来，所以写成HEAD~100。
现在，我们要把当前版本append GPL回退到上一个版本add distributed，就可以使用git reset命令：

$ git reset --hard HEAD^
HEAD is now at e475afc add distributed

还可以继续回退到上一个版本wrote a readme file，不过且慢，让我们用git log再看看现在版本库的状态
最新的那个版本append GPL已经看不到了！好比你从21世纪坐时光穿梭机来到了19世纪，想再回去已经回不去了，肿么办？
办法其实还是有的，只要上面的命令行窗口还没有被关掉，你就可以顺着往上找啊找啊，找到那个append GPL的commit id是1094adb…，于是就可以指定回到未来的某个版本

$ git reset --hard 1094a
HEAD is now at 83b0afe append GPL

版本号没必要写全，前几位就可以了
Git的版本回退速度非常快，因为Git在内部有个指向当前版本的HEAD指针，当你回退版本的时候，Git仅仅是把HEAD从指向append GPL
- 你回退到了某个版本，关掉了电脑，第二天早上就后悔了，想恢复到新版本怎么办？找不到新版本的commit id怎么办？
在Git中，总是有后悔药可以吃的。当你用$ git reset --hard HEAD^回退到add distributed版本时，再想恢复到append GPL，就必须找到append GPL的commit id。Git提供了一个命令git reflog用来记录你的每一次命令

总结

HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使用命令git reset --hard commit_id。
穿梭前，用git log可以查看提交历史，以便确定要回退到哪个版本。
要重返未来，用git reflog查看命令历史，以便确定要回到未来的哪个版本

工作区和暂存区

工作区就是能看到的目录
工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库。
Git的版本库里最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD
用git add把文件添加进去，实际上就是把文件修改添加到暂存区；
用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。
因为我们创建Git版本库时，Git自动为我们创建了唯一一个master分支，所以，现在，git commit就是往master分支上提交更改。
可以简单理解为，需要提交的文件修改通通放到暂存区，然后，一次性提交暂存区的所有修改
修改readme，然后添加license文件，输入git status，则

$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   readme.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)

	LICENSE

no changes added to commit (use "git add" and/or "git commit -a")

Git非常清楚地告诉我们，readme.txt被修改了，而LICENSE还从来没有被添加过，所以它的状态是Untracked
提交两个文件，则
- git add命令实际上就是把要提交的所有修改放到暂存区（Stage），然后，执行git commit就可以一次性把暂存区的所有修改提交到分支
提交，则

管理修改

修改readme
添加read
再修改readme
直接提交
结果是第二次修改没有被提交
证明Git管理的是修改
当你用git add命令后，在工作区的第一次修改被放入暂存区，准备提交，但是，在工作区的第二次修改并没有放入暂存区，所以，git commit只负责把暂存区的修改提交了，也就是第一次的修改被提交了，第二次的修改不会被提交
提交后，用git diff HEAD – readme.txt命令可以查看工作区和版本库里面最新版本的区别
总结：每次修改，如果不用git add到暂存区，那就不会加入到commit中

撤销修改

没有add

Changes not staged for commit:修改了但未add
修改了未提交时，git checkout – file可以丢弃工作区的修改
git checkout – readme.txt意思就是，把readme.txt文件在工作区的修改全部撤销，这里有两种情况：
- 一种是readme.txt自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态；
  - 一种是readme.txt已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态。
总之，就是让这个文件回到最近一次git commit或git add时的状态
git checkout – file命令中的–很重要，没有–，就变成了“切换到另一个分支”的命令

add了但没有commit

命令git reset HEAD 可以把暂存区的修改撤销掉（unstage），重新放回工作区
git reset命令既可以回退版本，也可以把暂存区的修改回退到工作区。当我们用HEAD时，表示最新的版本,然后再checkout
git checkout – readme.txt
假设你不但改错了东西，还从暂存区提交到了版本库，怎么办呢？还记得版本回退一节吗？可以回退到上一个版本。不过，这是有条件的，就是你还没有把自己的本地版本库推送到远程。还记得Git是分布式版本控制系统吗？我们后面会讲到远程版本库，一旦你把stupid boss提交推送到远程版本库，你就真的惨了

总结

场景1：当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git checkout – file。
场景2：当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令git reset HEAD ，就回到了场景1，第二步按场景1操作。
场景3：已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回退一节，不过前提是没有推送到远程库。

删除文件

删除某文件，这个时候，Git知道你删除了文件，因此，工作区和版本库就不一致了，git status命令会立刻告诉你哪些文件被删除了
你有两个选择，一是确实要从版本库中删除该文件，那就用命令git rm删掉，并且git commit

$ git rm test.txt
rm 'test.txt'

$ git commit -m "remove test.txt"
[master d46f35e] remove test.txt
 1 file changed, 1 deletion(-)
 delete mode 100644 test.txt

现在，文件就从版本库中被删除了
另一种情况是删错了，因为版本库里还有呢，所以可以很轻松地把误删的文件恢复到最新版本：

$ git checkout -- test.txt

git checkout其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”
命令git rm用于删除一个文件。如果一个文件已经被提交到版本库，那么你永远不用担心误删，但是要小心，你只能恢复文件到最新版本，你会丢失最近一次提交后你修改的内容

剑雨巍巍

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
1.1 GIT教程笔记之基本概念和管理修改

文章目录概述集中式与分布式版本控制系统安装基本概念非必要说明add时光穿梭commit和log总结工作区和暂存区管理修改撤销修改没有addadd了但没有commit总结删除文件概述参考链接：https://www.liaoxuefeng.com/wiki/896043488029600廖雪峰博客教程分布式版本控制系统来源：Linux（服务器系统软件）的编写SVN等版本控制系统速度慢，且要联网才能使用Linus两周用C写了分布式版本控制系统，即GIT，牛的集中式与分布式版本控制系统集中
复制链接

扫一扫