Git 介绍及入门

237 阅读13分钟

一、前言之Git介绍

1、什么是Git ?

相信大家一听到git,必然会想到 开源版本控制分布式 这几个关键词, 开源很好理解,那么什么又是版本控制,以及什么又是分布式呢?

版本控制养成记
  • 基于文件名的版本管理

上边这张图相信大家都在网上看过, 是否有想起当初辛辛苦苦写的论文却迟迟不通过的心酸呢, 这种以修改文件名的版本管理方式也是版本控制的一种,只不过版本越多,你的本地文件就越来越多,到一定数量的时候,想必给文件取名的时候就得抠破脑袋吧。这种版本管理方式在各行各业也都有应用, 比如在公司写PPT、方案、策划、设计等, 往往都是被甲方或领导打回N次之后才会通过的吧。

  • 基于本地版本控制软件的管理

这是git官网的一张本地版本控制图, 有了这个软件之后, 在你的电脑上只会看见一个文件, 软件将你的历史版本管理在后台, 类似于玩游戏中的存档, 你可以随时回退到历史版本。 这种方案解决了文件过多的问题, 但缺陷在于只能管理在本地管理, 不能提供多人协同工作.

  • 集中式版本管理工具

这是慢慢发展到后来出现的一种解决多人协同的一种版本管理方式, 他最核心的就是中心服务器, 需要协同工作的人员将所有的版本都存储在版本存储中心, 但致命的缺陷就是,如果中心服务器挂了, 又或者本地工作电脑断网了, 就不能将自己的新版本提交到中心服务器。最著名的集中式版本管理软件就是SVN, 早期很多公司都有使用。

  • 分布式版本管理工具

又随着技术的慢慢发展, 又出现了新的版本管理方式, 即分布式版本管理, 如图所示, 这种方式跟集中式版本管理工具相同的是, 分布式版本管理也有一个中心仓库, 不同的是在各个协同工作的电脑上也储存了所有的的版本数据, 需要协同工作的同学在提交新的版本时先是提交在本地仓库, 然后再推送到中心仓库, 这样就算中心仓库挂了, 也可以在协同工作同学的电脑上copy一份完整的版本数据, 也避免了因网络问题导致新的版本无法提交到中心仓库,这也是当前最火最常用的版本管理工具。


我们所讲的Git 即为目前最常用的分布式版本管理软件.

2、为什么要做版本控制?

简单的说, 是为了保留所有版本的数据, 以便以后回滚和修改

3、git安装

参考git官网教程: git-scm.com/book/zh/v2/…


二、前戏之Git入门

1、初始化之自报家门

当你的电脑第一次安装git时, 需要配置你的个人信息, 即向git报上你的邮箱和名字, 否则在你执行到commit命令时就会报错

使用以下两条命令配置邮箱和名字:

  # 配置邮箱
  git config --global user.email "you@example.com"
  # 配置名字 
  git config --global user.name "Your Name"

2、版本控制的步骤

  • 进入要管理的文件夹

cd dir 进入需要管理的文件夹

  • 初始化

    git init 初始化当前文件夹之后, git就相当于拥有了管理当前文件夹的权限, 并创建了一些git管理相关的文件

  • 管理

    对当前目录初始化之后,git就可以管理当前目录下的所有文件了

    使用 git status 检测当前目录下文件的状态

    • 三种状态的变化
      • 红色: 新增的文件 / 修改了原老文件 --> git add filename

      • 绿色: git已经管理起来了 --> git commit -m 'info'

      • 生成版本

    当文件还未被管理时, 使用 git add filename 将文件管理起来, 使用git add . 将当前目录下的所有文件都管理起来

  • 生成版本

    当你需要的文件都被git管理起来之后, 就可以创建一个版本了, 使用git commit -m 'info' 提交到本地管理库, 每执行一次git commit 都会在本地创建一个版本库

    如果你想看看当前已提交的版本信息, 用git log 查看你的历史提交信息

3、Git三大区域

git的三个区域为 工作区暂存区版本库, 三大区域关系如上图所示

工作区即为你平时写数据的目录, git会自动检测文件是否被修改, 被修改后文件会被标识为已修改未提交文件, 数据编写完成之后使用git add 将文件或改动 添加到暂存区, 当你暂时想要的数据都完成添加或改动后, 就可以用git commit 提交到版本库了.

4、Git的后悔药

人生不能倒退,只能往前, 所以人们想起自己的种种遗憾时总说,如果人生有后悔药,我肯定...

Git为了不留遗憾, 创造了Git人生中的后悔药,你随时可以用 git reset --hard commit_id 命令回退/前进 到你想去的任何版本, 在Git中这颗后悔药叫做 回滚

回滚相关命令总结:

git log             		# 查看当前版本之前的历史提交信息
git reflog          		# 可以查看你回滚之前的历史提交信息
git reset --hard commit_id	# 回滚到commit_id 的版本
git reset --hard HEAD^		# 回滚到上一个版本, 每增加一个 ^  版本多回退一个版本

有了回滚之后, git的三大区域关系就成了下图关系了.

5、Git之初识分支

  • 分支理解

Git的分支就像是孙悟空的拔毛吹分身技能, 他可以吹很多个分身去做不同的事情, 比如让一个分身去学习Git, 让另一个分身去学习SVN, 最后将这两个分身一合并, 孙悟空既学会了Git,又学会了SVN

Git中通常存在一个主线分支 master, 可以理解为孙悟空的真身, 一般执行git init之后就默认创建了此分支

  • 分支的创建/合并/删除

    通常为了不影响主线分支, 我们在开发新功能时会使用 git branch new_branch 创建一个新的分支,并使用 git checkout new_branch切换到新分支上, 新分支的内容和当前主线分支内容一致, 当新分支的功能开发完毕之后需要合并到主分支上, 一般先切回主分支,使用 git merge 要合并的分支合并分支, 某些分支在完成任务之后失去了存在意义, 我们使用 git branch -d 要删除的分支 删除分支

    分支的切换实际上时HEAD指针的切换,所以在切换分支很快。

  • 线上紧急处理bug策略

    当你正在新分支上开发新功能时, 线上突然报错, 需要紧急解决bug, 常见的解决办法是: 先切换到线上使用的分支(一般为master), 从当前分支创建一个解决bug的新分支(比如: fixbug), 在fixbug上解决完bug,然后切换回master合并fixbug再重新上线, 这样即不影响我们正在开发的新功能, 也解决了bug

  • 工作流

    简单的分支工作流可以参考下图:

  • 分支相关命令总结:

    git branch			# 查看分支信息
    git branch new_branch		# 创建新分支
    git checkout new_branch		# 切换分支
    git checkout -b new_branch	# 创建新分支并切换到新分支
    git merge 要合并的分支		# 合并分支
    git branch -d 分支名		# 删除分支
    

6、Git配置文件路径

  • 项目的配置文件: 项目/.git/config

    使用命令行配置时用 --local 针对当前项目配置

    git config --local user.name ''
    git config --local user.email ''
    
  • 全局配置文件: ~/.gitconfig

    使用命令行配置时用 --global 配置全局配置

    git config --global user.name ''
    git config --global user.name ''
    
  • 系统配置文件

    • Windows: 一般是在 C:\Users\Administrator.gitconfig
    • Mac: /etc/.gitconfig

    使用命令行配置时使用 --system 配置系统配置

    git config --system user.name ''
    git config --system user.name ''
    

7、Git忽略文件

  • .gitignore

    项目中往往存在一些数据/缓存文件等, 我们不希望Git管理这些文件, 也不希望把这些文件推送到远程仓库, 只需要在项目根目录创建一个 .gitignore, 用来管理我们想忽略的文件。

    1. 按照单个文件名忽略
       a.py			# 忽略a.py
    2. 通配符忽略相同后缀的文件
       *.py			# 忽略所有.py 文件
    3. 忽略文件夹下的所有文件
        Dir/		# 忽略Dir目录下的所有文件
    4. 反向选择
        !a.py		# 还是需要a.py的
    5. 忽略部分
        *.py[c|a|d]		# 忽略 .pyc .pya .pyd 后缀的文件
    
  • 注意:

    只能忽略当前还未提交到版本管理的文件


三、Git之远程仓库

1、 远程仓库介绍

截至目前,我们的代码只存在本地库中, 还没有实现多人协作, 通常的做法是创建一个远程仓库,将本地库完整复制一份到远程仓库, 其他人可以从远程仓库中拉取代码,并开发新功能之后再次推送到远程仓库

git的远程仓库需要依赖代码托管平台, 常见的有 GitHub码云GitLab

2、 本地库 <==> 远程仓库

注册代码托管平台账户之后, 需要上传你的ssh key之后才能推送代码, 之后就可以创建远程仓库并关联你的本地库了

  • 本地库关联远程仓库

    1. 给远程仓库起别名
        git remote add origin 远程仓库地址
    2. 向远程仓库推送代码
        git push -u origin 分支
    
  • 新电脑下载远程仓库代码

    1. 克隆远程仓库代码
        git clone 远程仓库地址 
    2. 切换分支 (可能只能看到master分支, 但实际上是克隆了远程仓库的所有分支)
        git checkout 分支
    

3、四大区域

有了远程仓库之后, git的关系图就成了这样:

4、记录简洁之 rebase

  • 简洁你的commit记录

    在完成一个项目时, 避免不了一个项目在push到远程仓库之前有多个commit, 这样在查看日志时提交记录非常多, 部分commit记录实际上可以合并成一个commit记录, 我们可以利用 git rebase -i 来做这件事.

    1. 用commit_id 来合并, 将当前提交记录 到 commit_id 之间的记录合并为一个记录
        git rebase -i commit_id
    2. 用HEAD~ + 需要合并的前几次提交数 来合并, Num为几,就将前几次提交合并为一个记录
        git rebase -i HEAD~Num
    

    **注意: **

    1. 执行合并命令后,需要最后几次提交记录的pick为 s (squash) 保存退出后, 删除多余的提交信息

    2. 不要合并已经push到远程仓库的记录

  • 简洁分支合并记录

    普通的分支合并在查看记录时会有一条分叉, 我们可以使用rebase 让分支记录更简洁 不分叉

    这是使用merge合并分支时的记录:

    这是使用rebase合并分支的记录:

操作流程: python 1. 在dev分支上, rebase master分支 git rebase master 2. 切换回master, merge dev分支 git merge dev 注意: 1. rebase的过程中如果文件有冲突, 先手动解决冲突, 再执行 git rebase --continue 继续合并 2. 不要在公共分支使用rebase 3. 本地和远端对应同一条分支,优先使用rebase,而不是merge

5、相关命令总结

  • 远程仓库相关命令小总结:

    1. 关联远程仓库
        git remote add origin 远程仓库地址
    2. 向远程仓库推送代码
        git push -u origin 分支
    3. 从远程仓库拉取代码
        git pull origin 分支
        等同于以下两行命令:
            git fetch origin 分支
            git merge origin/分支
    4. 克隆远程仓库到本地
        git clone 远程仓库地址
    
  • rebase 相关命令小总结

    1. 用commit_id 来合并, 将当前提交记录 到 commit_id 之间的记录合并为一个记录
        git rebase -i commit_id
    2. 用HEAD~ + 需要合并的前几次提交数 来合并, Num为几,就将前几次提交合并为一个记录
        git rebase -i HEAD~Num
    3. 简洁分支记录
        git rebase 分支
    4. 丢弃一次合并
        git rebase –abort 
    5. 图形查看分支记录
        git log --graph
    6. 简化显示log信息
        git log --graph --pretty=format:"%h %s"
    

6、快速解决冲突之BeyondCompare

在合并分支时,往往不是一帆风顺,可能会有文件产生冲突导致合并出现问题, 普通的解决方式就是打开冲突文件, 找到冲突的地方手动处理之后再次提交, 这里介绍一个第三方软件可以快速的打开冲突文件帮助我们快速解决冲突文件.

在使用前需要安装好 BeyondCompare, 安装好之后在Git Bash中配置相关配置即可

  • windows 配置

    打开项目内部的 .git/config 配置文件,添加:

    [merge]
          tool = bc3
    [mergetool]
          # 防止合并后生产后缀为.orig的备份文件
          keepBackup = false
    [mergetool "bc3"]
          # 目录根据自己的实际路径更改
          cmd = "\"C:/Program Files/Beyond Compare 4/BComp.exe\" \"$LOCAL\" \"$REMOTE\" \"$BASE\" \"$MERGED\""
    
  • mac

    直接在命令行输入:

    git config --local merge.tool bc3
    # 路径按实际更改
    git config --local mergetool.path '/usr/local/bin/bcomp'
    git config --local mergetool.keepBackup false
    

    注意:

    windows修改项目内部config和Mac 配置时使用 --local参数 都是只对当前项目有效.

  • 使用方法

    在合并分支时如果提示有文件产生了冲突, 直接在命令行输入: git mergetool 命令, BeyondCompare会自动打开冲突文件展示有冲突的地方, 这个时候你就可以自己决定要留下的内容了, 修改之后关闭BeyondCompare软件就可以接着执行commit、push 等操作了


四、多人协作

1、 多人协作工作流程

多人协作往往是项目负责人创建一个组织,将参与此项目的开发者拉入组织内,并创建项目的远程仓库, 分配权限, 之后各开发者在自己的电脑上关联此仓库地址,就可以开发了。

如果有新的开发者加入项目, 先clone项目到本地, 在开发分支上创建新的功能分支进行开发, 开发完成之后发送pull request, 由负责代码审查的人审查通过之后合并到开发分支, 然后负责人可以在开发分支上创建预发布分支(测试分支), 有bug就改bug, 没bug就可以合并到master分支上做上线了。

2、 多人协作工作流

五、命令总结

git常用命令总结: juejin.cn/post/688781…