Git学习笔记_致命错误:该操作必须在一个工作区中运行

Git简介

Git是一个用C语言编写的开源的分布式版本控制系统，可以有效、高速地处理从很小到非常大的项目版本管理。百度百科
集中式和分布式的区别：
集中式版本控制系统，版本库集中存放在中央服务器，必须要联网才能工作,没有历史版本库。
分布式版本控制系统，没有“中央服务器”，每个开发人员电脑上都有一个完整的版本库。
分布式优势：安全性更高，无需联网，若“中央服务器”故障，任何一个其他开发者本地都有最新的带历史记录的版本库。主要区别在于历史版本库的存放，集中式历史版本只存在于中央服务器，而分布式中每个本地库都有历史记录存放。

Git可以在Linux、Unix、Mac和Windows几大平台上运行

原Git教程网址：https://www.liaoxuefeng.com/wiki/896043488029600

Git官网：https://git-scm.com/book/zh/v2

以下为个人学习笔记

安装git

apt-get install git

因为Git是分布式版本控制系统，安装完成后再设置，名字和Email地址

git config --global user.name “Your Name”
git config --global user.email “email@example.com”

创建版本库

版本库又名仓库，英文名repository，可以简单理解成一个目录，这个目录里面的所有文件都可以被Git管理起来，每个文件的修改、删除，Git都能跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻可以“还原”。

mkdir learngit
cd learngit
git init

初始化后有一个.git目录，这个目录是Git来跟踪管理版本库用的

所有的版本控制系统，其实只能跟踪文本文件的改动，比如TXT文件，网页，所有的程序代码等等，Git也不例外。版本控制系统可以告诉你每次的改动，比如在第5行加了一个单词“Linux”，在第8行删了一个单词“Windows”。而图片、视频这些二进制文件，虽然也能由版本控制系统管理，但没法跟踪文件的变化，只能把二进制文件每次改动串起来，也就是只知道图片从100KB改成了120KB，但到底改了啥，版本控制系统不知道，也没法知道。

添加文件到仓库

第一步

git add filename.xxx

注：一定要在Git初始化后的目录下执行，否则会报fatal: Not a git repository (or any of the parent directories): .git错误

第二步

git commit -m “本次提交说明”

-m后面输入的是本次提交的说明

注：可添加多个文件，而后一起提交

修改文件

修改readme.txt后

查看修改状态

git status

git status命令可以让我们时刻掌握仓库当前的状态，

查看修改详情

git diff filename

提交修改

提交文件

git commit -m “add distributed”

版本回溯

查看历史版本

git log --pretty=oneline 注：–pretty=oneline，只会显示版本号和提交时的备注信息

回溯上一版本版本

在Git中，用HEAD表示当前版本，HEAD^是上一个版本
HEAD^^是上上一个版本，HEAD~n是上n版本

git reset --hard HEAD^

git reset --hard~“版本号” 注：版本号只写几位也可

Git的版本回退速度非常快，因为Git在内部有个指向当前版本的HEAD指针，当你回退版本的时候，Git仅仅是把HEAD从指向append GPL：

改为指向add distributed：

然后顺便把工作区的文件更新了。所以你让HEAD指向哪个版本号，你就把当前版本定位在哪

查看所有操作记录

git reflog

然后可用git reset --hard commit id 回到git log已删除不显示的步骤了

工作区和暂存区

工作区（Working Directory）

就是你在电脑里能看到的目录，比如learngit文件夹就是一个工作区

版本库（Repository）

工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库。
Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。

用git add把文件添加进去时，实际上就是把文件修改添加到暂存区；
用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。
因为我们创建Git版本库时，Git自动为我们创建了唯一一个master分支，所以，现在，git commit就是往master分支上提交更改。注意Git管理的是修改，而不是文件

撤销修改

第一种情况：工作区错误回滚

git checkout – filename

撤销在工作区的修改
命令git checkout – readme.txt意思就是，把readme.txt文件在工作区的修改全部撤销，让这个文件回到最近一次git commit或git add时的状态。
第二种情况：暂存区错误回滚

git reset HEAD

可以把暂存区的修改撤销掉，重新放回工作区
第三种情况：版本库错误回滚
git reset --hard HEAD~n
即版本回溯

删除文件

git rm filename

在Git中，删除也是一个修改操作。命令git rm用于删除一个文件。如果一个文件已经被提交到版本库，那么你永远不用担心误删，但是要小心，你只能恢复文件到最新版本，你会丢失最近一次提交后你修改的内容。

远程仓库

第一步：
由于本地Git仓库和GitHub仓库之间的传输是通过SSH加密的,所以在用户主目录下需要一点设置

ssh-keygen -t rsa -C “youremail@example.com”

然后一路回车

第二步
登陆GitHub，打开“Account settings”，“SSH Keys”页面

因为GitHub需要识别出你推送的提交确实是你推送的，所以需要SSH key，并且GitHub允许你添加多个Key

添加到远程仓库

第一步：创建一个远程仓库

GitHub告诉我们，可以从这个仓库克隆出新的仓库，也可以把一个已有的本地仓库与之关联，然后，把本地仓库的内容推送到GitHub仓库。

git remote add origin git@github.com:yourname/learngit.git

把上面的yourname改成你的git帐号
注意：一定要在本地的Git仓库(目录)中执行，否则会报**fatal: not a git repository (or any of the parent directories): .git
**错误

添加后，远程库的名字就是origin，这是Git默认的叫法，也可以改成别的，但是origin这个名字一看就知道是远程库。

第二步：推送到远程库

git push -u origin master

把本地库的内容推送到远程，用git push命令，实际上是把当前分支master推送到远程。由于远程库是空的，我们第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令。

注：因为Git使用SSH连接，而SSH连接在第一次验证GitHub服务器的Key时，需要你确认GitHub的Key的指纹信息是否真的来自GitHub的服务器，输入yes回车即可。
推送成功后，可以立刻在GitHub页面中看到远程库的内容已经和本地一模一样

从现在起，只要本地作了提交，就可以通过命令提交

git push origin master

克隆一个本地库

git clone git@github.com:yourname/yourwarehouse.git

注意，把yourname换成你的名称，把yourwarehouse换成你要克隆的仓库

这就克隆成功了，要克隆一个仓库，首先必须知道仓库的地址，然后使用git clone命令克隆。Git支持多种协议，包括https，但通过ssh支持的原生git协议速度最快。

分支管理

创建与合并分支

在Git里，主分支即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支（master分支或其它分支）。

git branch branchname //创建分支

git branch //查看分支

注：*为指针所在位置

git checkout branchname //切换分支

git merge branchname //合并分支

git branch -d branchname //删除分支

git branch -D branchname //强行删除分支

rebase操作可以把本地未push的分叉提交历史整理成直线；
rebase的目的是使得我们在查看历史提交的变化时更容易，因为分叉的提交需要三方对比。

直接在master支线上改代码是很不明智的决定，容易改出很多意想不到的错误，甚至容易线上用户体验。加之创建、合并和删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果是一样的，但过程更安全。

解决冲突

当两个分支的文件出现冲突时，必须手动解决冲突后才能再提交，不能自动合并

可用git status显示冲突文件

这时可以直接查看冲突文件

Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，如图上半部分为HEAD指向的master分支，下半部分是需要合并的featurel，合并时会出现冲突的情况，此时合并将会把两个文件合并，我们需要手动修改，再次提交以解决冲突。用用下命令可以看到

当Git无法自动合并分支时，就必须首先解决冲突。
master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上。
每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。

Bug分支

保存工作现场

git stash

git stash list

git stash pop

修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；
当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场；
在master分支上修复的bug，想要合并到当前dev分支，可以用git cherry-pick 命令，把bug提交的修改“复制”到当前分支，避免重复劳动。
总的来说，就是，在分支下进行的工作，如果不commit的话，回到master，就会显示出你在分支下你添加的工作。这个时候，你在master下修改完bug提交后，正在分支进行的工作也会提交了。为了避免这个情况，你就在分支下，git stash将工作隐藏，这个时候，切换到master时候，修改了bug，提交。分支的内容不会被提交上去。

变基

可以提取在 C4 中引入的补丁和修改，然后在 C3 的基础上应用一次。 在 Git 中，这种操作就叫做 变基。 你可以使用 rebase 命令将提交到某一分支上的所有修改都移至另一分支上，就好像“重新播放”一样。

git checkout experiment
git rebase master

它的原理是首先找到这两个分支（即当前分支 experiment、变基操作的目标基底分支 master）的最近共同祖先 C2，然后对比当前分支相对于该祖先的历次提交，提取相应的修改并存为临时文件，然后将当前分支指向目标基底 C3, 最后以此将之前另存为临时文件的修改依序应用。

git checkout master
git merge experiment

最终变成下图

尽管实际的开发工作是并行的，但它们看上去就像是串行的一样
请注意，无论是通过变基，还是通过三方合并，整合的最终结果所指向的快照始终是一样的，只不过提交历史不同罢了。

• 变基法则一：不要对在你的仓库外有副本的分支执行变基
• 变基法则二：只对尚未推送或分享给别人的本地修改执行变基操作清理历史，从不对已推送至别处的提交执行变基操作，这样，你才能享受到“变基”和“合并”带来的便利。

标签

git标签是版本库的快照，实际就是某个commit的指针，如果要找到某次版本的commit号，数字复杂不好找，使用tag取一个易于记住和理解的名字就方便许多，它跟某个commit绑在一起。（类似于域名和IP地址的关系）

新建标签

git tag tagname

默认为HEAD，也可以指定一个commit id

查看标签信息

git show tagname

查看标签所有信息

git tag

推送某个标签到远程

git push origin tagname

一次性推送全部本地标签

git push origin --tags

删除一个本地标签

git tag -d tagname

删除一个远程标签

git push origh :refs/tags/tagname

忽略特殊文件

有些时候，你必须把某些文件放到Git工作目录中，但又不能提交它们，比如保存了数据库密码的配置文件等等，每次git status都会显示Untracked files …在Git工作区的根目录下创建一个特殊的.gitignore文件，然后把要忽略的文件名填进去，Git就会自动忽略这些文件不需要从头写.gitignore文件，GitHub已经为我们准备了各种配置文件，只需要组合一下就可以使用了。

配置别名

注：（global参数是全局参数，也就是这些命令在这台电脑的所有Git仓库下都有用,针对当前用户。如果不加，那只针对当前的仓库起作用。）

git config --global alias.st status （为查看状态配置别名）
git config --global alias.last ‘log -1’ （为显示最后一次提交信息配置别名）
git config --global alias.unstage ‘reset HEAD’ (为暂存区的修改撤销回工作区配置别名)
git config --global alias.lg “log --color --graph --pretty=format:’%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset’ --abbrev-commit”
那么配置文件放在哪里呢：
(1) 每个仓库的Git配置文件都放在.git/config文件中
(2) 当前用户的Git配置文件放在用户主目录下的一个隐藏文件.gitconfig中
(3) 我们可以直接在配置文件中进行配置

常用快捷键

Git Cheat Sheet