Git实战 | "东北热"创业史 | 02

第一阶段: 单枪匹马开始干

  1. 现在小明要创建一个 dbhot 的网站,那么就需要考虑版本控制了

  2. 版本控制 =====> 使用git管理文件夹
    (1) 进入要管理的文件夹 (win是鼠标右键 git here)
    (2) 初始化 git init
    (3) 管理
    git status: 检测管理的文件夹的文件状态 (需要不断的使用 git status 来查看当前文件夹的状态)
    git add ./文件名: 添加进入暂存区
    (4) 生成版本 git commit -m "描述信息"

  3. 可以通过使用 git log 查看提交的记录

  4. 命令小结
    (1) 执行初始化命令: git init
    (2) 管理目录下的文件状态: git static
    注意: 新增的文件和修改过后的文件都是红色的
    (3) 管理指定文件(红 => 绿)
    git add 文件名
    git add . (把所有红色文件管理了)
    (4) 个人信息配置: 用户名,邮箱(一次即可)
    git config --global user.email "xxx@xx.com"
    git config --global user.name "xxx"
    (5) 生成版本
    git commit -m "描述信息"
    (6) 查看版本记录
    git log

补充: 给git配置个人信息(仅需配置一次即可)

git config --global user.name "用户名"
git config --global user.email "邮箱地址"
git config --list 查看配置信息

第二阶段: 拓展新功能

上线"约饭"功能

git add . # 将修改文件提交到暂存区
giit commit -m "约饭" # 将文件从暂存区提交到版本库

第三阶段: "约饭"被迫下线&重新上线

现在这个"约饭"功能是擦边球,所以有关部门要求下线
后面经过和有关部门商量,"约饭"功能又可以上线了

上面就涉及到了回滚到之前,和回滚到之后

  1. 回滚之前的版本
    git log # 查看提交的记录
    git reset --hard 版本号

  2. 回滚之后的版本
    git reflog # reflog是可以查看所有的记录(包括已经被删除的commit记录和reset的操作)
    git reset --hard 版本号

三大区域

使用的几个git命令就是在控制文件在三个区域中来回切换

第四阶段: 商城&紧急修复bug

分支

分支可以给使用者提供多个环境的可能,意味着你可以把你的工作开发主线上分离开来,以免影响开发主线
A <= B <= C
A就是原来的文件,然后B只保存了和A不同的东西(例如新增的,删除的,修改的),总之不是把A重新复制一份,而是指保留修改的部分
C对于B和对于A也是同理, 这样可以更加的节省存储空间

紧急修复bug方案

如果现在 A <= B <= C <= D, 现在D大概需要两个月的开发工期,现在已经开发了一个月了,如果这时候C出现了Bug,
那么就需要回滚到C的版本去修复CBug
<= E
C <= D

E就是用来修复bug的,而且是专门新开的一个分支,只要对于Cbug修复好了就可以把 EC进行合并(然后bug分支可以删除可以不删除)
至于D,已经再开发了,那就接着往下开发,只是最后进行merge的时候会有冲突,因为现在 master 已经是 A<=B<=C<=E ,原本D是依赖于C的,
如果现在进行合并的话就只能手动处理这些冲突

  1. 命令总结
    (1) 查看分支: git branch
    (2) 创建分支: git branch 分支名称
    (3) 切换分支: git checkout 分支名称
    (4) 分支合并(可能产生冲突): git merge 要合并的分支
    注意: 切换分支再合并
    (5) 删除分支: git branch -d 分支名称

git branch # 查看所在分支
git branch dev # 创建dev分支开发
git branch # 查看所在分支
git checkout dev # 切换到dev分支
===编写商城功能代码50%...===
git status # 查看状态
git add . # 添加到暂存区
git commit -m "v4.1 新增了商城功能"
git log # 查看提交记录
===这时候v3.0出现了bug,需要紧急修复===
git checkout master # 注意,先切换回master在新建分支
git branch bug # 创建一个bug分支用来修复bug
git checkout bug # 切换到bug分支
===进行bug的修改===
git add .
git commit -m "v3.1 修复了约饭功能的bug"
git checkout master # 切换为master然后进行分支合并
git merge bug
git branch -d bug # bug分支已经没有用了,可以进行删除了
===回去接着开发商城功能===
git checkout dev
===编写商城功能代码100%===
git add .
git commit -m "v4.2 完成了商城功能的开发"
===开始合并,手动修改冲突===
git checkout master
git merge dev
===手动修改冲突===
git status 
git add .
git commit -m "v4.3 新增商城功能,并修复了之前v3.0的bug"
git log

工作流

  1. 一般规定 master 分支就是"线上版本",一般是不会轻易修改的
  2. dev是开发版本,然后可以有多个dev
  3. bugbug修复版本

要多条分支进行,类似于"多进程",不影响master的同时,最后完成再merge

第五阶段: 进军三里屯

第一天上班前在家上传代码到远程仓库

  1. 如果是在家里和公司进行办公的话,那么一个远程的代码仓库就很有必要到了
  2. 现在这种云端的代码仓库有几个出名的 (1) Github (2) Gitlab (3) Gitee
  3. 命令
    (1) 给远程仓库起别名: (当然不起也行,那就每次需要写一个网址)
    git remote add origin(这个是别名) 远程仓库地址
    (2) 向远程推送代码: (向远程推送代码是推送的分支代码)
    git push -u origin 分支

初次在公司新电脑下载代码

克隆远程创库代码
git clone 远程创库地址

克隆有有几个细节:

​ 1) 首先别名origin也会复制下来

​ 2) 还有就是clone下来会把所有的分支都下载下来,但是本地只会显示一个master分支,但是依然可以使用git checkout 分支名进行分支的切换. 切换了分支后在本地就会显示出分支信息了

在公司继续开发

clone完代码后需要继续开发,那么开发肯定是在dev的分之上进行的.

  1. 切换dev分支上进行开发

git checkout dev

  1. master分支合并到dev,确保dev是在最新的master基础上进行开发

git merge master

  1. 修改代码

git add .

git commit -m "xxx"

git push origin dev

下班回到家继续写代码

  1. 切换到dev分支进行开发

git checkout dev

  1. 拉代码

git pull origin dev

  1. 继续开发

git add .

git commit -m "xxx"

git push origin dev

...

开发完毕,要上线

  1. dev分支合并到master,进行上线

git checkout master

git merge dev

git push origin master

  1. dev分支也推送到远程

git checkout dev

git merge master

git push origin dev

如果开发一个功能忘记push,如何处理?

  1. 自己可以想一想后面如何写后面的功能,尽量不要做重复的代码工作,然后推送到仓库

  2. 回到公司,git pull一下昨天在家写的,会有冲突产生,手动解决冲突即可.

注意:

git pull origin dev等价于git fetch origin devgit merge origin/dev

所以pull的时候其实就包含了merge的过程.

远程仓库和三大区域联系

rebase的作用(很重要)

rebase可以保持提交记录的简介,不分叉.

注意: 已经提交了远程仓库的建议不要使用rebase.

合并提交记录

现在有这样的一个情况,就是给一个功能,这个功能可能会开发5天,那么这期间自己可能会提交好几次.

C是初始的版本代码,然后可能会产生C1,C2,C3,C4,C5

C<=C1<=C2<=C3<=C4<=C5,假设一天提交一次

但是C1,C2,C3,C4,C5,其实这些只有对自己有用的,对于其他人是没有用的,所有进行代码的合并.

  1. 从当前的HEAD到下面的n条记录进行合并

git rebase -i HEAD~n

  1. 从当前记录到最末尾的记录进行合并

git rebase -i 版本号

pull下来代码不产生分叉

git fetch origin dev

git rebase origin/dev

快速解决冲突

Beyond Compare

git最烦的就是修改冲突,就是需要手动一个一个修改文件.

现在借助一个软件beyond compare,可以非常方便的帮助处理冲突.

git中配置

git config --global merge.tool bc4 
git config --global mergetool.path "C:\Program Files\Beyond Compare\bcomp"
git config --global mergetool.keepBackup false # 不要产生备份

应用beyond compare解决冲突

但是需要说的是这个软件其实应用的不是很好,所以建议使用IDE的集成环境来拉取项目.

vimdiff

当然也可以使用vimdiff来进行文件的修改

git config merge.tool vimdiff
git config merge.conflictstyle diff3
git config mergetool.prompt false

产生冲突使用git mergetool

posted @ 2020-11-19 15:57  RowryCho  阅读(276)  评论(0编辑  收藏  举报