【Mac】git使用再学习

目录

前言

如何使用github建立自己的代码库

第一步：建立本地git与远程github的联系

生成密钥

将密钥加入github

第二步：创建github仓库并clone到本地

第三步：上传文件

常见的git命令

git commit

git branch

git merge/git rebase

git clone

git fetch

git pull

git push

​编辑

Git Flow工作流

什么是Git Flow

GitFlow分支介绍

主要分支（Master）

开发分支（Develop）

功能分支（Feature）

预发分支（Release）

热修复分支（Hotfix）

GitFlow代码实现

创建develop分支

开始新的Feature

编辑Feature分支

完成Feature分支

开始Release

完成Release

开始Hotfix

完成Hotfix

模拟GitFlow开发流程

创建develop分支

甲和乙开始开发新功能

甲把功能开发好了

甲开始准备一次发布

甲完成了发布

用户发现了一个bug

---

前言

由于笔者最近在准备合作完成第二个项目，在写项目的过程中，要用到git来更好地合作，而笔者之前学习有关git的知识比较浅显而且长时间不使用，已经忘得差不多了，现在重新学习一下git，这次学习git主要有三个方面：

1. 学会如何使用github建立自己的代码库

2. 学会一些常见的git命令，用来远程合作。

3. 学习git的工作流

（声明：本篇文章所有的工作都通过github和macOS操作系统进行，所有内容都以github为例）

如何使用github建立自己的代码库

第一步：建立本地git与远程github的联系

github有四种通信方式：SSH、HTTPS、GitHub CLI、GitHub API，四种方式各有其特点：

这里笔者主要尝试了前两种方式，使用SSH可以成功进行上传，而使用HTTPS时常常在输入个人访问令牌时出问题，笔者暂时不知道是什么问题。这里就以SSH为例来说明如何建立本地git与github的联系。

生成密钥

在终端中输入以下命令配置用户名和邮箱：

git config --global user.name "your_name"
git config --global user.email "[e-mail]"

接着输入以下命令生成密钥：

ssh-keygen -t rsa -C "[e-mail]"

然后会弹出以下提示：

这是在询问你密钥的存储路径

如果直接按Enter，密钥将被保存在 ~/.ssh/id_rsa（私钥）和 ~/.ssh/id_rsa.pub（公钥），也就是默认路径。

也可以使用自定义路径，输入一个自定义路径，例如：

/Users/huyongtai/.ssh/github_rsa

推荐使用默认路径，避免额外配置

如果使用默认路径，下一步会提示输入passphrase，可以留空（直接按Enter）

当出现以上提示时，就已经成功生成密钥了

输入以下命令浏览文件目录：

ls -lf

这里有一个.ssh文件，这个文件里存放着我们的密钥

接着我们打开这个文件：

cd .ssh
ls

会出现以下界面，这里第二个文件就是我们要找的密钥

我们来打开这个文件查看密钥：

cat id_rsa.pub

打开之后，我们把密钥复制下来（从ssh一直到你的邮箱全部都要复制）

将密钥加入github

点击头像后展开以上界面，选择Settings，

进入设置页面后，选择SSH and GPG keys

点击New SSH key，进入以下界面：

将刚刚复制的密钥输入就成功将本地git与github绑定了

第二步：创建github仓库并clone到本地

上图是创建github库的界面，可以输入名称描述信息，选择私有或公有，以及是否生成README文件。

创建好后，我们可以在该位置找到这个库的SSH地址

接下来使用刚刚找到的SSH地址进行clone：

这样就将库clone到本地了，接下来就可以在本地找到clone下来的这个库：

第三步：上传文件

接下来就可以上传文件了：首先将要上传的文件添加到这个文件夹中。添加完成后，使用命令将其添加至暂存区并查看分支状态：

git add .
git status

如果显示分支中的文件都为绿色，则没有问题，接下来就进行提交：

git commit -m "commit information"

然后提交：

git push

上传成功后，终端会进行提示，此时打开github的仓库，就可以看到自己本地的代码和文件了。

常见的git命令

笔者通过可视化git命令学习网站学习了一些git命令的用法和含义，在这里整理一下：

git commit

Git 仓库中的提交记录保存的是你的目录下所有文件的快照，就像是把整个目录复制，然后再粘贴一样，但比复制粘贴优雅许多！

Git 希望提交记录尽可能地轻量，因此在你每次进行提交时，它并不会盲目地复制整个目录。条件允许的情况下，它会将当前版本与仓库中的上一个版本进行对比，并把所有的差异打包到一起作为一个提交记录。

Git 还保存了提交的历史记录。这也是为什么大多数提交记录的上面都有 parent 节点的原因 —— 我们会在图示中用箭头来表示这种关系。对于项目组的成员来说，维护提交历史对大家都有好处。

使用git commit命令便可以提交记录:

git branch

git的分支也非常轻量，之后的git工作流会再详细介绍git分支的知识。现在可以暂时理解为按逻辑将工作分解到不同分支。

使用git branch可以创建一个新的分支：

git branch bugFix

 

在创建好分支后，可以使用git switch和git checkout来切换到当前分支再进行提交。

使用git checkout -b <your-branch-name> 可以在创建一个新分支的同时切换到该分支。

git merge/git rebase

这两条命令都是将分支合并的命令，先看git merge。

这条命令相当于将两个分支合并并产生一个新的记录：

git merge bugFix

 

接下来看看git rebase：

rebase其实是取出一系列的提交记录，复制它们后在另一个地方一个一个的放下去。

Rebase 的优势就是可以创造更线性的提交历史，这听上去有些难以理解。如果只允许使用 Rebase 的话，代码库的提交历史将会变得异常清晰。

git rebase main

 

git clone

使用该命令会在本地创建一个远程仓库的拷贝。

在这个网站中模拟的有所不同，网站中模拟成创建一个远程的拷贝本地的副本。

之前在github上传代码时已经用到过该命令了

这时本地多了一个o/main分支，我们称为远程分支，远程分支反映了远程仓库的状态。

远程分支有一个特别的属性，在你切换到远程分支时，自动进入分离 HEAD 状态。Git 这么做是出于不能直接在这些分支上进行操作的原因, 你必须在别的地方完成你的工作, （更新了远程分支之后）再用远程分享你的工作成果。

大多数的开发人员会将它们主要的远程仓库命名为 origin，并不是 o。这是因为当你用 git clone 某个仓库时，Git 已经帮你把远程仓库的名称设置为 origin 了。

git fetch

git fetch这条命令可以从远程仓库获取数据。当从远程仓库获取数据时，远程分支也会更新以反映最新的远程仓库。

git fetch完成了两步：

1. 从远程仓库中下载本地仓库缺失的提交记录

2. 更新远程分支指针

Git fetch并不会改变你本地仓库的状态，不会更新main分支，也不会修改你磁盘上的文件。

git pull

之前说到git fetch只是获取远程的数据，那么要将这些变化更新到我们的工作当中，我们可以使用之前学到的命令来合并远程分支，例如：

git merge o/main
git rebase o/main

而git pull命令就是这两步合成了一条命令，也就是说，git pull就是git fetch和git merge的缩写

git push

git push是一条与git pull相反的命令，它可以将你的变更上传到指定的远程仓库，并在远程仓库上合并你的新提交记录。

Git Flow工作流

什么是Git Flow

GitFlow 是一种 Git 工作流，这个工作流程围绕着project的发布(release)定义了一个严格的如何建立分支的模型。它是团队成员遵守的一种代码管理方案 。

简单来说，Git Flow就是一种规范，这种规范指导你如何用git来更好地合作完成一个项目的开发。在工作场合实施git时，有很多种工作流程可供选择（Centralized Workflow、Feature Branch Workflow、Gitflow Workflow、Forking Workflow），这些工作流程作为指导方针，只是起到参考的作用，不必视作“铁律”。

这里主要介绍GitGlow Workflow

GitFlow常用分支：

分支名称	分支说明
Production	生产分支，即Master分支，只能从其他分支合并，不能直接修改
Release	发布分支，基于Develop分支创建，待发布完成后合并到Develop和Production分支去
Develop	主开发分支，包含所有要发布到下一个Release的代码，该分支主要合并其他分支内容
Feature	新功能分支，基于Develop分支创建，开发新功能，待开发完毕合并至Develop分支
Hotfix	修复分支，基于Production分支创建，待修复完成后合并到Develop和Production分支去，同时在Master上打一个tag

GitFlow分支介绍

GitFlow模型中定义了主分支和辅助分支两类分支，其中主分支包含主要分支和开发分支，用于与软件开发、部署相关的活动；辅助分支包含功能分支、预发分支、热修复分支和其他自定义分支，主要用于解决一些特定问题。

主要分支：master分支、develop分支

辅助分支：feature分支、release分支、hotfix分支

主要分支（Master）

这个分支存放整个项目最稳定的正式版本，并且这里的代码必须随时可以在生产环境中使用。当一个版本开发完，产生了一份新的可供发布的代码，主要分支上的代码就会被更新。

主要分支上不允许直接提交代码，只接受其他分支的合入。原则上主要分支上的代码必须是合并自预发分支

开发分支（Develop）

开发分支是主开发分支，上面集成了下一个版本的要交付的新功能，当开发分支准备好发布时，应该拉取一个预发分支并附上发布版本号。

开发分支接受其他辅助分支的合入，比如功能分支。开发一个新功能时拉取新的功能分支，开发完后再并入开发分支。

develop分支用来整合各个feature分支，开发中的版本的源代码存放在这里

功能分支（Feature）

功能分支用于开发未来版本的新功能，该分支通常存在开发人员的本地代码库而不要求提交到远程代码库上。有一种观点是功能分支要求足够细粒度以避免称为长期存在的功能分支，应当小步合并而不是一次合并大量代码。

功能分支只能拉取自开发分支，开发完成后要么合并回开发分支，要么因为新功能的不符要求而废弃。

预发分支（Release）

该分支的作用是测试新开发好的版本，通过创建预发分支，可以让开发分支空闲出来接受下一个版本的新的功能分支的合入。

预发分支只能拉取自开发分支，合并回开发分支和主要分支。

release分支不是一个放正式发布产品的分支，你可以将它理解为“待发布”分支。

我们用这个分支干所有和发布有关的事情，比如：

把这个分支打包给测试人员测试

在这个分支里修复bug

编写发布文档

所以，在这个分支里面绝对不会添加新的特性。

当和发布相关的工作都完成后，release分支合并回develop和master分支。

单独搞一个release分支的好处是，当一个团队在做发布相关的工作时，另一个团队则可以接着开发下一版本的东西。

热修复分支（Hotfix）

当生产环境的代码（主要分支上代码）遇到严重问题，必须立即修复时，就需要拉取热修复分支进行代码的紧急修复。这样做不会打断开发分支的开发工作，可以让负责功能开发的人与负责代码修复的人并行、独立地开展工作。

GitFlow工作流程如下：

GitFlow代码实现

创建develop分支

git branch develop//创建develop分支
push -u origin develop//将develop分支推送到远端仓库

开始新的Feature

checkout -b Feature分支名 develop//从develop上创建feature分支并切换到feature分支
push -u origin Feature分支名//将分支推送到远端仓库

编辑Feature分支

git status//查看状态
git add XXXfile//添加提交内容
git commit//提交

完成Feature分支

git pull origin develop//拉取远端仓库 develop 分支合并到本地 develop 分支
git checkout develop//切换到 develop 分支
git merge --no-ff Feature分支名//将 Feature 分支合并到 develop 分支//--no-ff：不使用 fast-forward 方式合并，保留分支的 commit 历史//--squash：使用 squash 方式合并，把多次分支 commit 历史压缩为一次    
git push origin develop//将分支推送远端仓库 
git branch -d Feature分支名//删除 Feature分支

开始Release

checkout -b release-0.1.0 develop

完成Release

git checkout master //切换到master分支上
git merge --no-ff release-0.1.0 //合并Release分支
git push//推送到远端仓库
git checkout develop//切换到develop分支
git merge --no-ff release-0.1.0 //合并Release分支
git push//推送到远端仓库
git branch -d release-0.1.0//删除release分支

开始Hotfix

git checkout -b hotfix-0.1.1 master//创建并切换Hotfix分支

完成Hotfix

git checkout master//切换到master分支
git merge --no-ff hotfix-0.1.1//合并hotfix分支
git push//推送到远端仓库
git checkout develop//切换到develop分支
git merge --no-ff hotfix-0.1.1 //合并hotfix分支
git push//推送到远端仓库
git branch -d hotfix-0.1.1//删除hotfix分支
git tag -a v0.1.1 master//在主分支上打上版本标签
git push --tags//将标签推送到远端仓库

模拟GitFlow开发流程

创建develop分支

首先为默认的master分支配备一个develop分支，一种简单做法是在本地建立一个空的develop分支，把它推送到服务器

git branch develop
git push -u origin develop

现在，其他开发者需要克隆这个仓库，并为develop创建一个追踪分支

git clone "仓库地址"
git checkout -b develop origin/develop

甲和乙开始开发新功能

甲和乙要分别开发新功能，他们俩各自建立了自己的分支。

git checkout -b some-feature develop

在自己的功能开发分支上开展工作：

git status
git add <some-file>
git commit

甲把功能开发好了

甲开发完了他的功能，这时他可以将他的代码合并入本地的develop分支，然后再推送到中央仓库

git pull origin develop
git checkout develop
git merge some-feature
git push
git branch -d some-feature

第一条命令一定要先执行，它可以确保本地的develop分支拥有最新的代码。合并时如果发生冲突，需要在代码中去解决。

甲开始准备一次发布

在乙开发的同时，甲可以进行项目的第一次正式发布了，创建一个新的分支来做产品发布的准备工作

git checkout -b release-0.1 develop

这个分支用来做一些发布前的准备，一旦把这个分支推向中央仓库(Master)，那么这次发布包含的功能就固定下来了，任何还在开发中的功能只能等待下一个发布周期。

甲完成了发布

准备工作完成后，就要把发布分支合并入master和develop分支，然后再将发布分支删除。

git checkout master
git merge release-0.1
git push
git checkout develop
git merge release-0.1
git push
git branch -d release-0.1

用户发现了一个bug

之前发布的版本，用户发现了一个bug，为了解决这个问题，甲基于master创建了一个用于维护的分支，在这个分支上修复了bug，然后把改动的代码直接合并入master

git checkout -b issue-#001 master
git checkout master
git merge issue-#001
git push

一定要记得将维护分支上的改动也合并入develop分支：

git checkout develop
git merge issue-#001
git push
git branch -d issue-#001