熟练使用git以及gitflow流程

沃德斌
112 阅读16分钟

版本库和文件操作

Unix/Linux 命令中，- 后一般跟短命令选项（通常是单字母，如-m），-- 后一般跟长命令选项。如果只有一个单独的--，后面不紧跟任何选项，则表示命令选项结束，后续的都作为命令的参数而不是选项。

Git仓库初始化

进入某一目录，在终端输入下述指令创建本地git仓库

git init

设置本地仓库的基本信息

在命令行或终端中使用下面的命令可以设置git自己的名字和电子邮件

git config --global user.name "binhao"
git config --global user.email "<2732990098@qq.com>"

暂存和提交文件

git add将文件保存到暂存区 git commit -m message提交文件到仓库,message表示备注信息

git add
git commit -m message

查看配置

git config -l

必须把不需要提交的后缀或者文件添加到和.git同目录的 .gitignore文件中

查看当前仓库状态

git status

查看修改内容

如果git staus发现内容有修改过，可用git diff查看修改内容

git diff

查看历史提交记录

git log

版本回退

使用git log查看历史提交记录 在git中，HEAD表示当前版本(commit id版本号)

git reset --hard HEAD^ //回退1个版本
git reset --hard HEAD^^//回退2个版本
git reset --hard HEAD~100//回退100个版本

返回某一个过去或者未来的某个版本：git reset --hard 新版本的commit id。其中“新版本的commit id”可以只写id号的前几位，Git会自动去找。比如

git reset --hard version_1

查看历史的每一次命令

git reflog

git log可以查看每一次提交时的commit id

工作区和暂存区相关命令

通过commit提交后，用git diff HEAD -- readme.txt命令可以查看工作区和版本库里面最新版本的区别 。 此外还需要知道以下两个命令的区别：

git diff
git diff --cathed
  • git diff #是工作区(work dict)和暂存区(stage)的比较，比较的是工作区文件与暂存区文件的区别（上次git add后的内容）的区别。
  • git diff --cached #是暂存区(stage)和分支(master)的比较，比较的是暂存区的文件与仓库分支里（上次git commit后的内容）的区别。

撤销修改

  • 当改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令
git checkout -- file名

若文件还没被加到暂存区，则回到修改之前的版本，若文件是加到暂存区后进行修改，则回到和暂存区一致的版本

  • 当改乱了工作区某个文件的内容并且将改乱的文件加到暂存区，此时想放弃修改，需要两步:先将暂存区的提交撤销，然后使用git checkout
git reset HEAD file名
git checkout -- file名

注：git reset可以回退版本，也可以将暂存区的提交撤销，HEAD表示当前版本

  • 已经将错误的内容提交到版本库，此时需要使用git reset回退版本
git reset --hard commit id

删除文件

git rm file名

远程仓库

本地建立SSH Key

  ssh-keygen -t rsa -C "youremail@example.com"    # 一路回车即可

进入.ssh目录找到id_rsa.pub文件，复制其中内容到远程仓库SSH

查看远程仓库

git remote

展示当前关联的其他仓库列表

git remote -v

本地仓库和远程仓库关联

git remote add origin 远程仓库链接地址 
例如：git remote add origin git@github.com:bin6221808/test.git

把本地库的所有内容推送到远程库上 ，实际上是把当前分支main推送到远程。 由于远程库是空的，第一次推送main分支时，加上了-u参数，Git不但会把本地的master分支内容推送到远程新的main分支，还会把本地的main分支和远程的main分支关联起来，在以后的推送或者拉取时就可以简化命令。 （去掉-u）

git push -u origin main    # 第一次推送，推送到远程仓库的main分支
git push origin main      # 后面的推送可删除-u

删除远程分支

git push origin :name//name表示远程分支名字

删除本地分支在远程不存在的分支

git remote prune origin

获取远程仓库的url

git remote get-url origin

删除与远程仓库之间的联系

git remote rm origin

修改与远程仓库之间的关联

1.  git remote rm <name>
2.  git remote add <name> <url>
或者
git remote set-url <name> <url>

克隆仓库

git clone SSH地址

分支

查看本地分支

git branch

查看本地和远程所有分支

 git branch -a

获取本地分支和远程分支之间的关系

git remote show origin

查看本地分支和远程分支的关联情况

    git branch -vv

创建分支

git branch name

切换分支

git checkout name

创建并切换分支

git checkout -b name

从远程获取分支到本地(不会合并)

git fetch

从远程获取分支到本地(自动合并)常用

git pull
git pull --rebase(推荐) 执行过程中会将本地当前分支里的每个提交(commit)取消掉，
然后把将本地当前分支更新为最新的"origin"分支

合并指定分支到当前分支

git merge name
git rebase name（推荐）

git pull = git fetch + git merge

本地分支和远程分支关联

  • 本地已经创建了分支dev（以dev为例，下同），而远程没有： 
    git push -u origin dev 自动关联远程dev分支
或者
git push --set-upstream origin dev 建立与远程dev分支的关联
  • 远程已经创建了分支dev,而本地没有： 
    1. git pull -u origin dev 先将远程分支拉取到本地
2. git checkout -b dev --track origin/dev 然后本地创建分支并与远程分支关联
    或者可以在pull远程分支的同时，创建本地分支并与之进行关联 
    git pull origin dev:dev-------两个dev分别表示远程分支名：本地分支名
  • 本地分支和远程分支都已经建立，但是没有关联： 
    git branch --set-upstream-to=origin/dev

删除本地分支

git branch -d name

删除远程分支

git push origin --delete branchname

远程分支

远程分支实际上是上次和主分支交互更新得到的最新版本

git push origin branch-name//推送本地分支到远程分支
git checkout -b branch-name origin/branch-name//本地创建和远程分支对应的分支，分支名最好相同
git pull origin dev//拉取远程分支到本地分支

使用分支流程

1. git checkout -b branch1 //创建分支
2. 在分支上操作
3. 合并分支，先git checkout main切换到主分支，然后执行git merge branch1进行合并。然后可以再执行git branch -d dev删除分支

解决冲突

不同的分支修改了代码相同的部分，从而导致合并分支时出现冲突（虽然冲突，但还是会合并，会自动标注出冲突的地方）。所以解决冲突就需要我们把Git合并失败的文件进行手动修复，改为我们想要的内容再提交（add + commit）即可。
可以用带参数的git log查看分支的合并情况（分支合并图）：

git log --graph --pretty=oneline --abbrev-commit

分支管理策略

默认采用Fast forward模式，看不到合并历史，删除分支会丢掉分支信息。
禁用该模式时，合并分支会产生新的commit，可以看到分支历史，命令为：

git merge --no-ff -m "merge with no-ff" dev

其中，--no-ff参数，表示禁用Fast forward模式。 因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去。

stash指令

git stash//暂存工作区修改的内容
git stash pop//恢最新暂存的工作区

如果想恢复最近某一次暂存内容，则先查看暂存列表，再恢复指定的暂存内容

git stash list
git stash apply stash@{2}//使用标号为2的暂存内容

清空Stash

git stash clear

bug分支

若main分支出现了bug，而自己的分支还没开发完成未能提交，则执行以下步骤。

  • 先使用git stash隐藏分支
  • 切换到main分支，并新建bug修复分支
  • 在bug修复分支上修复bug后提交，然后切换到main分支合并bug修复分支
  • 切换回自己的分支，git stash list命令看看stash内容，然后git stash pop，恢复的同时把stash内容也删了继续工作
  • 如果要在别的分支修复相同的bug，git cherry-pick <commit>命令能复制一个特定的提交到当前分支

强制删除分支

git branch -D name

多人协作(重点)

当从远程仓库克隆时，实际上Git自动把本地的master分支（或指定的某分支）和远程的master分支（或指定的某分支）对应起来了，并且，远程仓库的默认名称是origin，用git remote或git remote -v可查看远程库的信息

推送分支

main主分支和dev开发分支，都要时刻与远程库保持同步，所以需要推送。其他分支，比如bug分支和feature分支等，是否需要推动到远程可依具体情况而定。

# 推送时，要指定本地分支，这样，Git就会把该分支（的所有提交）推送到远程库对应的远程分支上
git push origin master  
git push origin dev

抓取分支

  • git clone默认克隆master分支，用git branch查看。若别人也要在dev分支上开发，则必须创建远程origin的dev分支到本地，用git checkout -b dev origin/dev。完成相关工作后，时不时地把dev分支push到远程，用git push origin dev。
  • 如果别人对dev分支的文件作出了修改，并且push了，而我也要对这文件进行了修改，如果直接push则会报错，此时需要将最新的提交pull下来合并，解决冲突后提交。
  • 这时若直接用git pull会失败（其实这里直接git pull origin dev就行了，其实只需要git clone一次后，就建立了本地仓库和远程仓库的链接，以后只需要指定origin就行了），因为到目前为止还没有指定本地dev分支与远程origin/dev分支的链接，应设置dev和origin/dev的链接： git branch --set-upstream-to=origin/dev dev，然后再git pull就成功了（git pull是把远程库某分支最新的提交抓下来，然后与本地某分支自动合并）。但这时合并会有冲突，需要手动解决，解决后提交，再git push origin dev即可。

多人合作模式

  • 首先，可以试图用git push origin 推送自己的修改；
  • 如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；
  • 如果合并有冲突，则解决冲突，并在本地提交；
  • 没有冲突或者解决掉冲突后，再用git push origin 推送就能成功

要点

  • 从本地推送分支，使用git push origin branch-name，如果推送失败，先用git pull抓取远程的新提交；
  • 在本地创建和远程分支对应的分支，使用git checkout -b branch-name origin/branch-name，本地和远程分支的名称最好一致；
  • 建立本地分支和远程分支的关联，使用git branch --set-upstream branch-name origin/branch-name；
  • 从远程抓取分支，使用git pull --rebase，如果有冲突，要先处理冲突

标签

标签用来标记某个commit

  • git tag查看所有标签
  • git tag name commit id 给指定commit创建标签，若未指定，则默认是最新提交
  • git push origin name 推送tag到远程仓库

合并远程子分支

  • git checkout -b B origin/B //本地创建一个和远程分支对应的分支
  • git pull //将远程代码拉取到本地
  • git checkout A //切换到我的分支
  • git merge B //合并分支A和B
  • 解决冲突：1：git add 冲突文件路径（git status 可查看路径）2：git commit -m'解决冲突'
  • git push orgin A //同步本地分支到远程分支

合并远程子分支到远程主分支

#进入本地版本库 将远程develop分支合并到远程master分支

  1. 切换到与远程子分支对应的本地子分支（若没有则创建）
  2. 同步远程子分支和本地子分支
  3. 切换到本地主分支
  4. 同步远程主分支到本地主分支
  5. 合并本地子分支到本地主分支
  6. 同步本地主分支到远程主分支
git checkout develop
git pull origin develop:develop
git checkout master
git pull origin master
git merge develop
git push origin master:master

推送代码流水线

git init 
git add filename
git commit -m bin
git remote add origin git@github.com:bin6221808/test.git
git pull --rebase origin main
git push -u origin main //第一次提交
git push origin master

多人协作流水线

git的正常用法是每人建一个分支，上传前拉取主分支上的代码，在自己的分支上合并主分支上的代码，处理完冲突后再上传.
对于A~E五个小小伙伴而言，此时应该有一个共同的初始代码，这份代码目前只有master分支。第一件事，就是拉取master分支到本地，然后在本地新建自己的个人分支(A_devel)，再将个人分支推送到远程仓库。

  1. 拉取代码到本地（默认的就是master分支）
    git clone

2. 在本地新建一个新个人分支A_devel，并且保证远程仓库也有这个分支

 git checkout -b A_devel 
 git push origin A_devel:A_devel
# A_devel是新建的本地分支名，origin/A_devel是同名的远程分支名。

3. 经过一系列开发后，你在本地分支A_devel有了一些改动，此时你可以将这些改动push到你自己的远程分支A_devel

    git push origin A_devel

4. 在本地切换到master分支

    git checkout master

5. 确保在多人协作下不会错过别人推送到master分支上的改动，要先pull一下master分支.

    git pull origin master

6. 将你自己的分支A_devel与master分支合并

    git merge A_level

7.最后同步到远程master

    git push origin master

代码冲突处理流程

  1. git stash 先将本地修改保存起来

  2. git pull --rebase 拉取远程仓库

  3. 此时发生冲突，可以用git status查看未合并成功的文件，修改冲突文件即解决冲突

  4. git add提交修改冲突后的文件

  5. 处理完冲突后使用git rebase --continue合并冲突，如果rebase不成功，则继续解决冲突

  6. 所有冲突处理完后，git commit以及git push即可提交到远程仓库

  7. git stash pop stash@{0} 还原暂存内容
    注意：git pull 和 git pull --rebase 命令都是从远端拉取代码，更新我们的仓库，区别在于git merge和git rebase的区别。两者都有合并节点功能，但是gie merge会产生新节点，而git rebase不会。

gitflow

可以理解为一套为企业级项目服务的git代码管理规范

流程图

image.png

介绍

在Git Flow是典型的双主干分支结构，其中master作为发布的主干分支，develop作为开发的主干分支。

项目刚开始时，从master分支检出develop分支，在后续的开发过程中不能用develop分支去合并master分支。

开发新功能时，要用develop分支检出feature分支来开发新功能，每当要开发一个新功能，就从develop分支检出feature分支来开发新功能。

Gitflow的主分支

  • master分支

    只存线上的代码，只有确定可以上线时的才合并到master上，并且在master的基础上打Tag，比如，上线了1.0版本，那就将代码提交到master上，并打Tag命名为1.0。

image.png

  • develop分支

初次创建develop时，需要从master分支拉取，保持开发时代码和线上最新的代码相同。develop分支是在开发时的最终分支，具有所有当前版本需要上线的所有功能。

Gitflow辅助主分支

包括三种分支：

  • 用于开发新功能时所使用的feature分支：

    • 用于开发功能的分支，必须从最新的develop分支代码拉取。分支命名基本上是feature/xxxxx（和功能相关的名字）.

    • 不强制提交到远程仓库，可以本地创建。比如，开发登录功能，从develop分支的最新代码创建新分支命名为feature/login，然后切换到这个新分支开始开发。开发完成后，测试差不多完成，合并到develop分支.

      git branch feature/login 创建分支
git checkout feature/login 切换到该分支

  • 用于辅助版本发布的release分支；

    • 当develop分支已经有了本次上线的所有代码的时候，并且以通过全部测试的时候，可以从develop分支创建release分支了，release分支是为发布新的产品版本而设计的
    • 通过在release分支上进行这些工作可以让develop分支空闲出来以接受新的feature分支上的代码提交，进入新的软件开发迭代周期。
    • 在这个分支上的代码允许做小的缺陷修正、准备发布版本所需的各项说明信息（版本号、发布时间、编译时间等等

比如，此次1.0版本所有的功能版本都已经合并到了develop上，并且所有测试都已经通过了测试，那我就创建新的release分支release/v1.0。切换到新分支，修改最新的版本号等，不允许大的更改

    git merge feature/login 合并功能代码
    git checkout -b release/v1.0 创建并切换到release/v1.0

  • 用于修正生产代码中的bug-hotfix分支

    • 当线上出现bug需要紧急修复时，从当前master分支派生hotfix分支

    • 修改线上bug，修改完成后合并回develop和master分支

    也就是先在线上修复，后面再合并到开发分支，加快效率。

    在线上v1.0登录功能出现问题，从master拉取代码创建新的分支hotfix/v1.0_login，修改完成后合并到master和develop上

        git checkout -b hotfix/v1.0_login 创建并切换到hotfix分支
    git checkout master 切换到主分支
    git merge hotfix/v1.0_login 合并hotfix分支到线上分支
    git checkout develop
    git merge hotfix/v1.0_login 合并hotfix到开发分支

踩坑

git pull --rebase origin main //如果在关联远程仓库之前将已经commit了，如果直接push，则会因为本地仓库和远程仓库不一致而报错，此时需要输入该指令取消本地仓库的commit

参考资料

https://juejin.cn/post/6844903517811900424#heading-16
avatar
文章
阅读
粉丝