版本控制
- git init
- 创建本地仓库(版本库),当前目录下会有一个.git文件生成
- .git文件就是用来记录当前版本库里内容变化的。
- git add project.md
- 将我的project.md文件添加到暂存区
- git status
- 查看文件在工作区、暂存区的状态
- 如果git status告诉你有文件被修改过,用
git diff
可以查看修改内容。 - git status不显示已经commit的文件信息
- git commit -m ‘信息’
- 正式提交项目到本地仓库(版本库),备注上提交信息
- 实际上就是把暂存区的所有内容提交到当前分支 -
master
分支
- git log
- 查看正式提交(commit)项目的记录,以便确定要回退到哪个版本
- git reset –hard HEAD^
- 回退一次版本
- 上一个版本就是
HEAD^
,上上一个版本就是HEAD^^
,当然往上100个版本写100个^比较容易数不过来,所以写成HEAD~100
- git reflog
- 查看管理员执行命令记录
- 当我从20版本回滚到19版本后,又想回到20版本,就可以通过该命令查看命令历史,以便确定要回到未来的哪个版本
- git reset –hard commit_id
- 退回到某个历史执行命令id所对应的那个版本,id从
git reflog
命令获得
- 退回到某个历史执行命令id所对应的那个版本,id从
- git checkout – project.md
- 把project.md文件在工作区的修改全部撤销,有两种情况
- 一种project.md自修改后还没有被放到暂存区,现在,撤销修改就回到和版本库一模一样的状态;
- 一种是project.md已经添加到暂存区后,又作了修改,现在,撤销修改就回到添加到暂存区后的状态
- 总之就是让这个文件回到最近一次git commit或git add时的状态
- 把project.md文件在工作区的修改全部撤销,有两种情况
- git reset HEAD project.md
- 丢弃已添加到暂存区的项目project.md,把暂存区的修改回退到工作区
- 如果你删除了文件,导致工作区和版本库不一致,此时有两个选择:
- 一是确实要从版本库中删除该文件,那就用命令
git rm xxx.txt
删掉,并且git commit
- 另一种情况是删错了,因为版本库里还有呢,所以可以很轻松地把误删的文件恢复到最新版本 -
git checkout -- xxx.txt
- 一是确实要从版本库中删除该文件,那就用命令
远程仓库
- git remote add origin 远程仓库地址
- 关联远程仓库
- git push -u origin master
- 将本地仓库的主分支和远程的主分支关联,第一次推送master分支时,需要加上
-u
参数,之后就不需要加了
- 将本地仓库的主分支和远程的主分支关联,第一次推送master分支时,需要加上
- git clone 远程仓库地址
- 克隆远程仓库
分支管理
在团队合作中,为了不影响别人开发进度,同时保留自己的每天开发的进度,我可以创建一个分支 dev1,在这个分支 dev1 上,相当于一个独立的空间线。我想怎么玩就怎么玩,别人也看不到,也影响不到别人开发。当我的功能全部开发完成后,就把我的分支合并到项目总分支上。
- git branch dev
- 创建一个自己的独立分支dev
- git branch
- 查看HEAD指针指向哪个分支
- git checkout dev
- 为了能够在自己分支上提交代码,所以我们要切换分支到 dev 上
- 为了不影响master分支,必须切换到自己的分支上commit代码
- git merge dev
- git merge命令用于合并指定分支到当前分支
- 所以合并到master分支之前必须切换回master分支,然后用上面的命令将 dev 的改动合并到 master 分支上
- git branch -d dev
- 合并完成后,通过以上命令删除dev分支
- 当我们两个人同时去修改一个文件,进行提交时,当前 git 不知道你两个人以谁修改的为主,就导致了合并冲突
- 通过
git status
命令查看发生冲突的文件 - 然后我们手动修改冲突之后,再进行提交
- 通过
- 最新版本的Git提供了新的
git switch
命令来切换分支- 创建并切换到新的dev分支,可以使用:
git switch -c dev
- 直接切换到已有的master分支,可以使用:
git switch master
- 创建并切换到新的dev分支,可以使用:
分支策略
在实际开发中,我们应该按照几个基本原则进行分支管理:
首先,master
分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;
那在哪干活呢?干活都在dev
分支上,也就是说,dev
分支是不稳定的,到某个时候,比如1.0版本发布时,再把dev
分支合并到master
上,在master
分支发布1.0版本;
你和你的小伙伴们每个人都在dev
分支上干活,同时每个人都有自己的分支,时不时地往dev
分支上合并就可以了。
所以,团队合作的分支看起来就像这样:
参考: