标签：回退 自己 不同的 过程 拒绝 修复 空目录 比较 就是
GIT是目前世界上最先进的分布式版本控制系统(没有之一).
什么是版本控制系统(待补充)?
文件的多版本管理
集中式VS分布式
* 集中式版本控制系统:
(1)版本库集中存放在中央服务器.
(2)需要工作时,先从中央服务器获取最新版本;工作完,再推送给中央服务器.
(3)集中式最大毛病--必须联网才能工作.
* 分布式版本控制系统:
(1)没有中央服务器,每个人电脑上都有完整的版本库,安全性高.
(2)没必要联网工作.
(3)一般会有一台电脑充当做"中央服务器",方便大家交换"修改".
(4)强大的分支管理,多人协同操作.
GTI的诞生简史
GTI的特点是什么?
1. 创建版本库
(1)版本库(repository): 又名仓库,简单理解成一个目录,这个目录里面的所有文件都可以被Git管理起来,每个文件的修改/删除,Git都能跟踪,以便任何时刻都可以追踪历史,或者在将来某个时刻可以"还原".
(2)选择一个适合的地方,创建一个空目录,作为Git仓库
* 初始化一个仓库,使用 git init 命令
2. 添加文件到Git仓库
(1)分两步操作:
1)使用命令 git add <file> ,注意,可反复多次使用,添加多个文件
2)使用命令 git commit -m <message>,完成(其中message为提交时,对文件所做的说明,方便后期查找管理)
3. 查看文件及工作区状态
(1)随时掌握工作区状态,使用 git status 命令
(2)如果 git status 反馈信息有文件被修改过,用 git diff 可以查看修改内容
4. 时光穿梭,版本切换
(1)Git中,文件操作,每一份提交的文件都会有一个版本号(commit id),每一个版本都不同.每提交一个新版本,实际上Git就会把他们自动串成一条时间线,可以通过可视化工具查看Git历史.
(2)Git提供操作命令,方便在不同的文件版本间切换.Git在内部有个指向当前版本的HEAD指针,当版本回退时,Git将指针指向想回退的版本,顺便把工作区的文件更新.
* 操作流程
1)HEAD指向的版本就是当前版本,因此,Git允许我们在版本的历史之间穿梭.使用命令 git reset --hard commit_id .(Git中HEAD指向当前版本,HEAD^指上一个版本,HEAD^^指上上一个版本,当然往上100个版本写100个^比较数不过来,所以写成HEAD~100,比如 git reset --hard HEAD^,回到上一个版本;另外也可以使用 commit_id<填写地址首7位就行>,在版本间切换)
2)在穿梭前,用 git log 可以查看提交的历史,以便确定要回退到哪个版本.
3)回到历史后,若再想返回到未来,则需要用 git reflog 查看操作命令的历史,以便确定要回到未来的哪个版本.
5. 工作区/暂存区/仓库(待补充)
6. 文件修改/删除及恢复
1. 添加远程仓库
(1)在github上注册账号,免费的git仓库,可多台电脑连接,备份可恢复
* 要关联一个远程仓库,使用命令 git remote add origin git@server-name:path/repo-name.git与远程仓库建立连接
* 关联后,使用命令 git push -u origin master ,第一次推送master分支的所有内容,此后的每次本地提交,只要有必要,就可以使用命令 git push origin master 推送最新修改
(2)分布式版本系统的最大好处之一是在本地工作完全不需要考虑远程库的存在，也就是有没有联网都可以正常工作，而SVN在没有联网的时候是拒绝干活的！当有网络的时候，再把本地提交推送一下就完成了同步，很方便操作！
2. 从远程仓库克隆版本库
(1)要克隆一个仓库,必须首先知道仓库的地址,然后使用 git clone 命令克隆.
* 在GitHub上创建一个新的仓库,Git_Skills
(2)远程仓库准备好后,用命令 git clone 克隆一个本地库.
* 在用户主目录下,使用命令 git clone git@github.com:MarsTianxiong/Git_Skills.git,克隆成功.
* 多人协作开发,每个人各自从远程克隆一份就可以了.
(3)Git支持多种协议,包括https,可以用(https://github.com/MarsTianxiong/Git_Skills.git),但通过ssh支持的原生git协议速度最快.使用http除了速度慢以外,还有最大的麻烦是每次推送都必须输入口令(但若某些公司只开放http端口,就无法使用ssh协议,而只能使用https).
1.创建与合并分支
* 查看分支: git branch (当前所在分支,会用 "*" 在分支前标记)
* 创建分支: git branch <name>
* 切换分支: git checkout <name> (各分支切换(未合并),不会更新各自的工作状态)
* 创建 + 切换分支: git checkout -b <name> (创建+切换到新的分支)
* 合并某分支到当前分支: git merge <name> (将新分支dev提交的工作合并到主分支master)
* 删除分支: git branch -d <name>
*** 因为创建、合并和删除分支非常快,所以Git鼓励使用分支完成某个任务,合并后再删掉分支,这和直接在master分支上工作效果是一样的,但过程更安全.
2. 解决冲突
当小分支有修改提交,主分支master也有文件修改提交时,这种情况下,Git无法执行"快速合并",只能试图把各自的修改合并起来，但这种合并就可能会有冲突.
此时,Git无法自动合并分支时,就必须首先解决冲突.解决冲突后,再提交,合并完成.
* 解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容,再提交.
* 用 git log --graph 命令可以看到分支合并图.($ git log --graph --pretty=oneline --abbrev-commit)
3. 分支管理策略
Git合并分支,有"快速合并模式(Fast forward)",也有"普通模式".
Fast forward模式,合并分支时,直接把master的HEAD指向dev的当前提交.删除分支后,会丢掉分支信息.
普通模式(--no-ff,表示禁用Fast forward),合并分支时,创建一个新的commit,这样,从分支历史上就可以看出分支信息.
*** 分支策略
在实际开发中,应该按照几个基本原则进行分支管理:
首先,master分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活.那在哪干活呢?干活都在dev分支上,也就是说,dev分支是不稳定的,到某个时候,比如1.0版本发布时,再把dev分支合并master上,在master分支发布1.0版本.你和你的小伙伴们每个人都在dev分支上干活,每个人都有自己的分支,时不时地往master分支上合并就可以了.
Git分支十分强大,在团队开发中应该充分应用.合并分支时,加上--no-ff参数就可以用普通模式合并,合并后的历史有分支,能看出来曾经做过合并,而fast forward合并就看不出来曾经做过合并。
4. bug分支
* 修复bug,我们会通过创建新的bug分支进行修复,然后合并,最后删除.
* Git stash内容恢复有两个办法:
* 一是用git stash apply恢复,但是恢复后,stash内容并不删除,你需要用git stash drop来删除
* 另一种方式是用git stash pop,恢复的同时把stash内容也删了
* 当手头工作没有完成时,可以先把工作现场git stash一下,然后去修复bug,修复后,再git stash pop,回到工作现场.如若有多次stash,恢复的时候,先用git stash list查看,然后恢复指定的stash,用命令 git stash apply <stash@{0}>,以免将其他的stash误删,造成损失.
5. Feature分支
开发一个新feature,最好新建一个分支.
如果要丢弃一个没有被合并过的分支,会弹出友情提示,并可以通过git branch -D <name>强行删除(需要使用 -D 参数)。
标签：回退 自己 不同的 过程 拒绝 修复 空目录 比较 就是
原文地址：https://www.cnblogs.com/tianxiong/p/10569424.html
