Git版本控制 备忘录
Posted 小作一个
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Git版本控制 备忘录相关的知识,希望对你有一定的参考价值。
安装Git:
在Linux上安装Git: sudo apt-get install git
在windows上安装Git: 从https://git-for-windows.github.io下载,然后按默认设置安装,安装完成有,在Windows桌面空出右键,找到“Git Bash Here”, 蹦出一个类似命令行窗口的东西,说明Git安装成功!
创建版本库(版本库名取: learngit)命令组合:
- mkdir learngit #创建一个普通文件夹
- cd learngit #进入到新创建的普通文件夹
- pwd #查看当前路径, 返回值/users/michael/learngit, 证明当前所在位置为新建文件夹下
- git init #git初始化所在文件夹/users/michael/learngit, 返回 Initialized empty Git repository in /users/michael/learngit/.git
Git就把仓库建好了,而且是一个空的仓库. 目录下多了一个.git
的目录(这个文件夹本来是隐藏起来的),这个目录是Git来跟踪管理版本库的,没事千万不要手动修改这个目录里面的文件,不然改乱了,就把Git仓库给破坏了。
添加文件到版本库步骤:
1. 把文件readme.txt拖入../learngit文件夹中。
2. 命令: git add readme.txt 用命令git add
告诉Git,把文件添加到仓库:
3. 命令:git commit -m "wrote a readme file " 用命令git commit
告诉Git,把文件提交到仓库:
查看版本库状态:
命令: git status
查看版本库的修改(在git status命令显示某个文件被修改过了,但还没有准备提交的修改时,可用以下命令查看文件修改的地方):
命令: git diff 文件名.后缀
版本控制系统历史记录:
命令: git log #返回commit id(版本回退需要这个值), 时间,修改者等参数
命令: git log --pretty=oneline 一个记录精简成一行
版本回退:
命令: git reset --hard xxxx #其中xxxx是commit id.
查看命令历史:
命令: git reflog
理解工作区、版本库、暂存区:
Git工作区: 就是已经被git初始化变成的仓库 : ../learngit
Git版本库: 工作区中的隐藏目录.git就是Git的版本库
Git版本库里面有很东西,其中最重要的就是stage(暂存区)和Git自动创建的master(分支),以及指向master的一个HEAD(指针).
把文件往Git版本库里添加的时候,是分两步执行的:
第一步是用git add
把文件添加进去,实际上就是把文件修改添加到暂存区;
第二步是用git commit
提交更改,实际上就是把暂存区的所有内容提交到当前分支。
因为创建Git版本库时,Git自动创建了唯一一个master
分支,所以,现在,git commit
就是往master
分支上提交更改。
撤销修改:
申明: readme.txt是一个文件
命令: git checkout -- readme.txt
命令: git reset HEAD readme.txt
撤销,这里有一下几种情况:
1. readme.txt
自修改后还没有被放到暂存区,现在,需要将工作区的readme.txt撤销修改,保持和分支一样;
用命令:
-
- git checkout -- readme.txt
- git status # 使用git status查看结果发现,工作区和版本库是没有需要提交的修改。
2. readme.txt修改后,提交到了暂存区,但还未提交到分支。现在,需要将工作区的readme.txt撤销,保持和分支一样;
用命令:
-
- git reset HEAD readme.txt #使暂存区里面的修改撤销,保持和分支一样。
- git status #使用git status查看结果,可以发现工作区的readme.txt修改了,但是暂存区的修改已经撤销了。 此时,就回到了情况1了。要撤销工作区的修改,情况1已经说过了。
3. readme.txt修改后,提交到了暂存区,后readme.txt又作了修改,现在,需要第二次撤销第二次readme.txt的修改,暂存区保存第一次readme.txt的修改。
用命令:
-
- git checkout -- readme.txt
- git status #使用git status查看结果,可以发现工作区的readme.txt第二次修改撤销了,保持了第一次的修改。暂存区也保存了第一次的修改。 此时,就回到了情况2了。要撤销工作区readme.txt第一次的修改,请回到情况2.
根据情况1和情况3,git checkout -- readme.txt,就是让这个文件回到最近一次git commit
或git add
时的状态。
删除文件: git rm
先做好删除文件的准备工作: 在Git工作区创建一个文件test.txt. 然后运行一下指令将文件提交到Git分支。
$ git add test.txt $ git commit -m "Add test.txt" [master 44ed136] Add test.txt 1 file changed, 1 insertion(+) create mode 100644 test.txt
现在将工作区的test.txt文件删除,并查看Git状态
$ rm test.txt $ git status On branch master Changes not staged for commit: (use "git add/rm <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) deleted: test.txt no changes added to commit (use "git add" and/or "git commit -a")
删除了工作区的test.txt文件,有两种情况。
情况1. 是真想删除。
情况2. 是误删。
情况1,需要将删除文件这个动作提交到暂存区,再提交到分支
$ git rm test.txt rm ‘test.txt‘$ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) deleted: test.txt $ git commit -m "remove test.txt" [master 857faa2] remove test.txt 1 file changed, 1 deletion(-) delete mode 100644 test.txt
情况2,需要撤销对工作区的删除动作
$ git checkout -- test.txt
$ git status
On branch master
nothing to commit, working tree clean
远程仓库:
GitHub这个神奇的网站,它提供Git仓库托管服务,只要注册一个GitHub账号,就可以免费获得Git远程仓库。
在看下去之前,请先注册GitHub账号。
由于你的本地Git仓库和GitHub仓库之间的传输是通过SSH加密的,所以,需要一点设置:
1. 创建SSH Key。 在用户主目录下,看看有没有.ssh目录,如果有,再看看这个目录下有没有id_rsa
和id_rsa.pub
这两个文件,如果已经有了,可直接跳到下一步。如果没有,打开Shell(Windows下打开Git Bash),创建SSH Key:
$ ssh-keygen -t rsa -C "[email protected]"
然后一路回车,使用默认值即可。
如果一切顺利的话,可以在用户主目录里找到.ssh
目录,里面有id_rsa
和id_rsa.pub
两个文件,这两个就是SSH Key的秘钥对,id_rsa
是私钥,不能泄露出去,id_rsa.pub
是公钥,可以放心地告诉任何人。
2. 登陆GitHub, 进入settings, 点“SSH and GPG keys”, 点“New SSH Key”
填上任意Title,在Key文本框里粘贴id_rsa.pub
文件的内容, 然后点“Add SSH key”. 这样SSH key就算添加成功了。
为什么GitHub需要SSH Key呢?因为GitHub需要识别出你推送的提交确实是你推送的,而不是别人冒充的,而Git支持SSH协议,所以,GitHub只要知道了你的公钥,就可以确认只有你自己才能推送。
当然,GitHub允许你添加多个Key。假定你有若干电脑,你一会儿在公司提交,一会儿在家里提交,只要把每台电脑的Key都添加到GitHub,就可以在每台电脑上往GitHub推送了。
最后友情提示,在GitHub上免费托管的Git仓库,任何人都可以看到喔(但只有你自己才能改)。所以,不要把敏感信息放进去。
如果你不想让别人看到Git库,有两个办法,一个是交点保护费,让GitHub把公开的仓库变成私有的,这样别人就看不见了(不可读更不可写)。另一个办法是自己动手,搭一个Git服务器,因为是你自己的Git服务器,所以别人也是看不见的。这个方法我们后面会讲到的,相当简单,公司内部开发必备。
添加远程库:
有两种方案:
1. 在GitHub创建一个仓库,然后把一个已有的本地仓库与之关联。这个方案是本地库建立在先。
2. 在GitHub创建一个仓库,然后克隆到本地。这个方案是一切从零开发。
方案1:
GitHub创建好空仓库时,会给你一个远程仓库的地址: [email protected]:xxxxx/learngit.git。然后回到本地的learngit
仓库下运行命令:
$ git remote add origin [email protected]:xxxxx/learngit.git
添加后,远程库的名字就是origin
,这是Git默认的叫法,也可以改成别的,但是origin
这个名字一看就知道是远程库。
下一步,就可以把本地库的所有内容推送到远程库上:
$ git push -u origin master Counting objects: 19, done. Delta compression using up to 4 threads. Compressing objects: 100% (19/19), done. Writing objects: 100% (19/19), 13.73 KiB, done. Total 23 (delta 6), reused 0 (delta 0) To [email protected]:michaelliao/learngit.git * [new branch] master -> master Branch master set up to track remote branch master from origin.
把本地库的内容推送到远程,用git push
命令,实际上是把当前分支master
推送到远程。
由于远程库是空的,我们第一次推送master
分支时,加上了-u
参数,Git不但会把本地的master
分支内容推送的远程新的master
分支,还会把本地的master
分支和远程的master
分支关联起来,在以后的推送或者拉取时就可以简化命令。
推送成功后,可以立刻在GitHub页面中看到远程库的内容已经和本地一模一样。
本地和远程的关联已经建立,以后本地提交到远程,只要通过命令:
$ git push origin master
方案2:
GitHub上创建新的仓库,勾选Initialize this repository with a README
,这样GitHub会自动为我们创建一个README.md
文件。创建完毕后,可以看到README.md
文件。
远程库已经准备好了,下一步是用命令git clone
克隆一个本地库:
$ git clone https://github.com/LouisU/learngit.git Cloning into ‘learngit‘... remote: Counting objects: 30, done. remote: Compressing objects: 100% (20/20), done. remote: Total 30 (delta 7), reused 30 (delta 7), pack-reused 0 Unpacking objects: 100% (30/30), done. Checking connectivity... done.
如果有多个人协作开发,那么每个人各自从远程克隆一份就可以了。
理解HEAD和分支:
在版本回退里,你已经知道,每次提交,Git都把它们串成一条时间线,这条时间线就是一个分支。截止到目前,只有一条时间线,在Git里,这个分支叫主分支,即master
分支。HEAD
严格来说不是指向提交,而是指向master
,master
才是指向提交的,所以,HEAD
指向的就是当前分支。
一开始的时候,master
分支是一条线,Git用master
指向最新的提交,再用HEAD
指向master
,就能确定当前分支,以及当前分支的提交点:
每次提交,master
分支都会向前移动一步,这样,随着你不断提交,master
分支的线也越来越长.
当我们创建新的分支,例如dev
时,Git新建了一个指针叫dev
,指向master
相同的提交,再把HEAD
指向dev
,就表示当前分支在dev
上:
你看,Git创建一个分支很快,因为除了增加一个dev
指针,改改HEAD
的指向,工作区的文件都没有任何变化!
不过,从现在开始,对工作区的修改和提交就是针对dev
分支了,比如新提交一次后,dev
指针往前移动一步,而master
指针不变:
假如我们在dev
上的工作完成了,就可以把dev
合并到master
上。Git怎么合并呢?最简单的方法,就是直接把master
指向dev
的当前提交,就完成了合并:
所以Git合并分支也很快!就改改指针,工作区内容也不变!
合并完分支后,甚至可以删除dev
分支。删除dev
分支就是把dev
指针给删掉,删掉后,我们就剩下了一条master
分支:
$ git branch dev #创建一个分支, 分支名叫dev $ git checkout dev #切换到分支dev,使分支dev为当前分支,即HEAD指向dev $ git checkout -b dev # 创建一个分支dev,并使HEAD指向dev $ git branch # 查询当前分支 * dev # git branch命令会列出所有分支,当前分支前面会标一个*号 master $ git merge dev # 把dev分支的工作成功合并到master分支上。 这是fast forward“快进模式”,直接把master指向dev的当前提交,合并速度非常快 $ git branch -d dev # 删除dev分支
$ git merge --no-ff -m "merge with no-ff" dev
#加上--no-ff
参数就可以用普通模式合并,合并后的历史有分支,能看出来曾经做过合并,而fast forward
合并就看不出来曾经做过合并。
分支策略:
在实际开发中,我们应该按照几个基本原则进行分支管理:
首先,master
分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;
那在哪干活呢?干活都在dev
分支上,也就是说,dev
分支是不稳定的,到某个时候,比如1.0版本发布时,再把dev
分支合并到master
上,在master
分支发布1.0版本;
你和你的小伙伴们每个人都在dev
分支上干活,每个人都有自己的分支,时不时地往dev
分支上合并就可以了。
所以,团队合作的分支看起来就像这样:
# 用以下命令查看分支变化和分支合并。
$ git log --graph --pretty=oneline --abbrev-commit * f95cd82 merged bug fix 001 || * 5e21af4 fix bug-001 |/ * 8f36a18 branch test * 66f3c2d change readme.txt again * d7f7ff8 modified readme.txt * a5ad9ad modified readme, git add, modified readme again, git commit * b470b5a append GPL * 397ea3f add distributed * 8cba8b1 Add file1.txt into git * 9ed2238 wrote a readme file
Windows特别注意:
千万不要使用Windows自带的记事本编辑任何文本文件。原因是Microsoft开发记事本的团队使用了一个非常弱智的行为来保存UTF-8编码的文件,他们自作聪明地在每个文件开头添加了0xefbbbf(十六进制)的字符,你会遇到很多不可思议的问题,比如,网页第一行可能会显示一个“?”,明明正确的程序一编译就报语法错误,等等,都是由记事本的弱智行为带来的。建议你下载Notepad++代替记事本,不但功能强大,而且免费!记得把Notepad++的默认编码设置为UTF-8 without BOM即可:
以上是关于Git版本控制 备忘录的主要内容,如果未能解决你的问题,请参考以下文章