目录
我们在软件开发过程中,可能会出现以下这些场景:
1.代码可能被别人或自己不小心覆盖或遗失、也不知道是谁因为什么原因改了这段代码、也没办法可以复原回前几天的修改 2.团队间的协同作业,代码如何同步?
版本控制是指对软件开发过程中各种程序代码、配置文件及说明文档等文件变更的管理
版本控制最主要的功能就是追踪文件的变更:它将什么时间、什么人更改了文件的什么内容等信息忠实地了记录下来。每一次文件的改变,文件的版本号都将增加。
版本控制的另一个重要功能是并行开发。软件开发往往是多人协同作业,版本控制可以有效地解决版本的同步以及不同开发者之间的开发通信问题,提高协同开发的效率。
并行开发中不同版本软件的错误(Bug)修正问题也可以通过版本控制中分支与合并的方法有效地解决。
以上软件也是版本控制系统的发展趋势,其中CVS及SVN都是集中式的版本控制系统;
集中式的版本控制系统: 核心是服务器。所有开发者在开始新一天的工作之前必须从服务器获取代码,然后开发,解决冲突,最后提交。所有的版本信息都放在服务器上。如果脱离了服务器,开发者基本上可以说是无法工作的。
最大的缺点:所有的数据都经过中央服务器进行交换同步。如果不能连接到服务器上,基本上不可以工作,不能提交,还原,对比等等。
分布式版本控制系统:
分布式版本控制系统(Distributed Version Control System,简称 DVCS)。 在这类系统中,像 Git、Mercurial、Bazaar 以及 Darcs 等,客户端并不只提取最新版本的文件快照, 而是把代码仓库完整地镜像下来,包括完整的历史记录。 这么一来,任何一处协同工作用的服务器发生故障,事后都可以用任何一个镜像出来的本地仓库恢复。 因为每一次的克隆操作,实际上都是一次对代码仓库的完整备份。
Git是一个开源的分布式版本控制系统,可以有效、高速的处理从很小到非常大的项目版本管理。 Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。
官网 api:https://git-scm.com/book/zh/v2 (很重要)
国内git服务器地址:https://gitee.com/ 码云 国外git服务器地址:https://github.com/
工作区: 项目或文件所在目录 本地仓库(版本库):工作区有一个隐藏目录.git,这个不算工作区,而是Git的版本库,版本库里存了很多东西,其中最重要的就是称为stage(或者叫index)的暂存区,还有Git为我们自动创建的第一个分支master,以及指向master的一个指针叫HEAD。 远程仓库:如gitee或github
第一步是用git add把文件添加进去,即把文件添加到暂存区;
第二步是用git commit提交更改,即把暂存区的所有内容提交到当前分支。
因为我们创建Git版本库时,Git自动为我们创建了唯一一个master分支,所以,现在,git commit就是往master分支上提交更改。
第三步:把本地版本库的文件推送到远程仓库
官方版本可以在 Git 官方网站下载。 打开 https://git-scm.com/download/win,下载会自动开始
双击安装即可
安装完 Git 之后,要做的第一件事就是设置你的用户名和邮件地址。 这一点很重要,因为每一个 Git 提交都会使用这些信息,它们会写入到你的每一次提交中
git config --global user.name xxx
git config --global user.email "xxxx@qq.com"
使用纯命令的方式使用git
通常有两种获取 Git 项目仓库的方式:
将尚未进行版本控制的本地目录转换为 Git 仓库 从其它服务器 克隆 一个已存在的 Git 仓库 两种方式都会在你的本地机器上得到一个工作就绪的 Git 仓库
方式1:
方式2:
现在我们的机器上有了一个 真实项目 的 Git 仓库,并从这个仓库中检出了所有文件的 工作副本。 通常,你会对这些文件做些修改,每当完成了一个阶段的目标,想要将记录下它时,就将它提交到仓库。
工作目录下的每一个文件都不外乎这两种状态:已跟踪 或 未跟踪。
已跟踪:工作目录的文件是已经被纳入了版本控制
未跟踪:工作目录中除已跟踪文件外的其它所有文件都属于未跟踪文件
编辑过某些文件之后,由于自上次提交后你对它们做了修改,Git 将它们标记为已修改文件。 在工作时,你可以选择性地将这些修改过的文件放入暂存区,然后提交所有已暂存的修改,如此反复。
git status
git add readme.text
如果文件已经提交到暂存或版本库,又修改了文件。可通过命令查看差异
git diff readme.txt
有些文件无需纳入 Git 的管理,比如日志文件,或者编译过程中创建的临时文件
我们可以创建一个名为 .gitignore 的文件,列出要忽略的文件的模式。 来看一个实际的 .gitignore 例子
touch .gitignore # 创建忽略文件
# 忽略所有的 .log 文件
*.log
# 忽略所有的 .class 文件
*.class
# 忽略所有的 .bak 文件
*.bak
# 忽略任何目录下名为 build 的文件夹
build/
# 忽略 doc/ 目录及其所有子目录下的 .pdf 文件
doc/**/*.pdf
tip:
GitHub 有一个十分详细的针对数十种项目及语言的 .gitignore 文件列表, 你可以在 https://github.com/github/gitignore 找到它。
git commit -m "提交说明"
要从 Git 中移除某个文件,就必须要从已跟踪文件清单中移除(确切地说,是从暂存区域移除),然后提交
git rm 要删除的文件
git log
其中一个比较有用的选项是 -p 或 --patch ,它会显示每次提交所引入的差异(按 补丁 的格式输出)。 你也可以限制显示的日志条目数量,例如使用 -2 选项来只显示最近的两次提交:
用来查看你每次的操作历史记录.这样即使误操作,也可以恢复你想要的版本了
场景1:当你改乱了工作区某个文件的内容,想直接丢弃工作区的修改时,用命令git checkout file。
场景2:当你不但改乱了工作区某个文件的内容,还添加到了暂存区时,想丢弃修改,分两步,第一步用命令git reset HEAD ,就回到了场景1,第二步按场景1操作。
场景3:已经提交了不合适的修改到版本库时,想要撤销本次提交
git reset --hard 版本号
本地创建了一个Git仓库后,我们可以在Gitee上创建一个远程t仓库,并且让这两个仓库进行同步,这样,Gitee上的仓库既可以作为备份,又可以让其他人通过该仓库来协作
登录成功后,可以创建自己的远程仓库
A)-本地仓库和远程仓库关联
git remote add pb https://gitee.com/bobo201811/my_project.git
B)本地仓库推送到远程的主分支
git push -u pb master
tip:
第一次推送需要输入gitee的账户和密码 C)克隆远程仓库到本地
git clone https://gitee.com/bobo201811/my_project.git
D)更新远程仓库到本地
git pull origin master
更新远程仓库内容并和本地仓库合并
E)更新远程仓库到本地**
git fetch origin master
更新远程仓库内容,不和合并分支,需要手工合并
使用分支意味着你可以把你的工作从开发主线上分离开来,以免影响主线的开发.
分支在实际中有什么用呢?假设你准备开发一个新功能,但是需要两周才能完成,第一周你写了50%的代码,如果立刻提交,由于代码还没写完,不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交,又存在丢失每天进度的巨大风险。
现在有了分支,就不用怕了。你创建了一个属于你自己的分支,别人看不到,还继续在原来的分支上正常工作,而你在自己的分支上干活,想提交就提交,直到开发完毕后,再一次性合并到原来的分支上,这样,既安全,又不影响别人工作。
但Git的分支是与众不同的,无论创建、切换和删除分支,Git在1秒钟之内就能完成!无论你的版本库是1个文件还是1万个文件
一开始的时候,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
首先,我们创建dev分支,然后切换到dev分支
$ git branch dev
$ git checkout dev
上面两行命令也可以使用下边一行命令:
git checkout -b dev
git checkout命令加上-b参数表示创建并切换
git branch
git branch命令会列出所有分支,当前分支前面会标一个*号。
然后,我们就可以在dev分支上正常提交,比如对readme.txt做个修改,加上一行:
create new branch dev..
$ git add readme.txt
$ git commit -m "create new branch...."
$ git checkout master
切换回master分支后,再查看一个readme.txt文件,刚才添加的内容不见了!因为那个提交是在dev分支上,而master分支此刻的提交点并没有变:
我们把dev分支的工作成果合并到master分支上
git merge dev
git merge命令用于合并指定分支到当前分支。合并后,再查看readme.txt的内容,就可以看到,和dev分支的最新提交是完全一样的。
注意到上面的Fast-forward信息,Git告诉我们,这次合并是“快进模式”,也就是直接把master指向dev的当前提交,所以合并速度非常快。
git branch -d dev
在查看分支,只剩下 master
git branch
小结:
查看分支:git branch
创建分支:git branch <name>
切换分支:git checkout <name>
创建+切换分支:git checkout -b <name>
合并某分支到当前分支:git merge <name>
删除分支:git branch -d <name>
有时候合并操作不会如此顺利。 如果你在两个不同的分支中,对同一个文件的同一个部分进行了不同的修改,Git 就没法干净的合并它们
案例:
git init
git commit -m "master提交"
创建并切换到分支 :
$ git checkout -b fenzhi1
在 readme.txt 中添加一句话
提交
git add .
git commit -m “分支一”
切换到master分支
$ git checkout master
改变readme.txt.
添加一句话 , 主分支改变了
git add .
git commit -m “主分支操作了”
这时,如果在合并fenzhi1,就会冲突
git merge fenzhi1
Git告诉我们,readme.txt文件存在冲突,必须手动解决冲突后再提交。git status也可以告诉我们冲突的文件
git status
查看冲突的文件
Git用<<<<<<<,=======,>>>>>>>标记出不同分支的内容.
我们改变文件如下:
这时再执行命令
Git add .
Git commit -m “解决冲突”
配置git位置
安装git插件
第一步
第一步
第二步
第三步:
如果是协作开发,远程仓库有更新,则可以
第一步
第二步
第三步
第四步
本文转载自:https://www.toutiao.com/article/7131987750303515167/
如图片失效等情况可参阅公众号文章:https://mp.weixin.qq.com/s/ewNBApOKL_1rzyENVEAptQ