版本控制

  • 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命令获得
  • git checkout – project.md
    • 把project.md文件在工作区的修改全部撤销,有两种情况
      • 一种project.md自修改后还没有被放到暂存区,现在,撤销修改就回到和版本库一模一样的状态;
      • 一种是project.md已经添加到暂存区后,又作了修改,现在,撤销修改就回到添加到暂存区后的状态
    • 总之就是让这个文件回到最近一次git commit或git add时的状态
  • 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参数,之后就不需要加了
  • 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

分支策略

在实际开发中,我们应该按照几个基本原则进行分支管理:

首先,master分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;

那在哪干活呢?干活都在dev分支上,也就是说,dev分支是不稳定的,到某个时候,比如1.0版本发布时,再把dev分支合并到master上,在master分支发布1.0版本;

你和你的小伙伴们每个人都在dev分支上干活,同时每个人都有自己的分支,时不时地往dev分支上合并就可以了。

所以,团队合作的分支看起来就像这样:

参考:

小鹿编程1

小鹿编程2

廖雪峰的git教程

评论