01Git初识

CSL369
365 阅读26分钟

Git版本控制

一 版本控制的介绍

版本控制：Version control：版本控制也是一种软件工程技巧，借此能在软件开发的过程中，确保由不同人所编辑的同一程序文件都得到同步；

image-20221014085028353

简单来说，版本控制在软件开发中，可以帮助程序员进行代码的追踪、维护、控制等等一系列的操作。

二 版本控制的功能

1 对于不同版本的存储管理：

  • 一个项目会不断进行版本的迭代，来修复之前的一些问题、增加新的功能、需求，甚至包括项目的重构；
  • 如果我们通过手动来维护一系列的项目备份，简直是一场噩梦；

2 重大版本的备份维护：

  • 对于很多重大的版本，我们会进行备份管理；

3 恢复之前的项目版本：

  • 当我们开发过程中发生一些严重的问题时，想要恢复之前的操作或者回到之前某个版本；

4 记录项目的点点滴滴：

  • 如果我们每一个功能的修改、bug的修复、新的需求更改都需要记录下来，版本控制可以很好的解决；

5 多人开发的代码合并：

  • 项目中通常都是多人开发，将多人代码进行合并，并且在出现冲突时更好的进行处理；

如上所知，都是我们在项目中经常会遇到的问题

发展历史

1 发展初期

在刚开始的时候，人们通过文件备份的方式来进行管理，再通过diff命令，来对比两个文件的差异。

diff命令：是 linux上非常重要的工具，用于比较文件的内容，特别是比较两个版本不同的文件以找到改动的地方。

1 CVS(Concurrent Version System)

  • 第一个被大规模使用的版本控制工具，诞生于1985年；
  • 由荷兰阿姆斯特丹VU大学的Dick Grune教授实现的，也算是SVN的前身（SVN的出现就是为了取代CVS的）。

2 SVN(Subversion)

  • 因其命令行工具名为svn，所以被简称为SVN；
  • SVN是由CollabNet公司于2000年资助并发起开发，目的是取代CVS，对CVS进行了很多的优化；
  • SVN和CVS一样，也属于集中式版本控制工具；
  • SVN在早期公司开发中使用率非常高，但是目前已经被Git取代；

3 Git(Linus的作品)

  • 早期的时候，Linux社区使用的是BitKeeper来进行版本控制；
  • 但是因为一些原因，BitKeeper想要收回对Linux社区的免费授权；
  • 于是Linus用了大概一周的时间，开发了Git用来取代BitKeeper；
  • Linus完成了Git的核心设计，在之后Linus功成身退，将Git交由另外一个Git的主要贡献者Junio C Hamano来维护；

集中式版本控制系统

CVS和SVN都是属于集中式版本控制系统(Centralized Version control Systems,简称CVCS)

  • 它们的主要特点是单一的集中管理的服务器，保存所有文件的修订版本。
  • 协同开发人员，通过客户端连接到服务器，取出最新的文件或者提交更新。
image-20221015113035825

这种做法相比于老式的管理方式带来了很多的好处，使得每个人都能够在一定程度看到项目中其他人做了些什么。

集中式版本控制存在的问题：中央服务器不能出现故障：

  • 如果宕机一个小时，那么在这一段时间内，谁都无法进行提交和更新，也就是没有办法协同工作。
  • 如果中心数据库所在的磁盘发生损坏，又恰巧没有备份的时候，就会丢失所有的数据。

分布式版本控制

Git属于分布式版本控制系统(Distributed Version Control System，简称DCVS)

image-20221015115216981
  • 客户端并不是提取最新版本的文件快照，而是把代码仓库完整的镜像下来，包括完整的历史记录。简单来说就是服务器仓库有什么东西，本来仓库就有什么东西。
  • 这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何 一个镜像出来的本地仓库恢复；
  • 因为每一次的克隆操作，实际上都是一次对代码仓库的完整备份；

Bash-GUI-CMD

image-20221015151203209

Git在安装完成之后，就会有这几个东西，下面分别来说一下，他们之间的关系以及区别：

Bash，Unix shell 的一种，Linux 与 Mac OS X 都将它作为默认 shell。

  • Git Bash 就是一个 shell，是 Windows 下的命令行工具，可以执行 Linux 命令；
  • Git Bash 是基于 CMD 的，在 CMD 的基础上增添一些新的命令与功能；
  • 所以建议在使用的时候，用 Bash 更加方便；

Git CMD

  • 命令行提示符（CMD）是 Windows 操作系统上的命令行解释程序；
  • 当你在 Windows 上安装 git 并且习惯使用命令行时，可以使用 cmd 来运行 git 命令；

Git GUI

  • 基本上针对那些不喜欢黑屏（即命令行）编码的人；
  • 它提供了一个图形用户界面来运行 git 命令；

Git的配置分类

既然已经在系统上安装了 Git，你会需要做几件事来定制你的 Git 环境：

  • 每台计算机上只需要配置一次，程序升级时会保留配置信息；
  • 你可以在任何时候再次通过运行命令来修改它们；

image-20221015160756040

Git 自带一个 git config 的工具来帮助设置控制 Git 外观和行为的配置变量：

  • /etc/gitconfig 文件：包含系统上每一个用户及他们仓库的通用配置
    • 如果在执行 git config 时带上 --system 选项，那么它就会读写该文件中的配置变量；
    • 由于它是系统配置文件，因此你需要管理员或超级用户权限来修改它。（开发中通常不修改）
  • ~/.gitconfig 或 C/用户/coderwhy/.gitconfig 文件：只针对当前用户
    • 你可以传递 --global 选项让 Git 读写此文件，这会对你系统上 所有 的仓库生效；
  • 当前使用仓库的 Git 目录中的 config 文件（即 .git/config）：针对该仓库
    • 你可以传递 --local 选项让 Git 强制读写此文件，虽然默认情况下用的就是它；

Git的配置选项

安装Git后，要做的第一件事就是设置你的用户名和邮件地址。

  • 这一点很重要，因为每一个 Git 提交都会使用这些信息，它们会写入到你的每一次提交中，不可更改；
git config --global user.name "xxx"
git config --global user.email "xxxx"

如果使用了 --global 选项，那么该命令只需要运行一次，因为之后无论你在该系统上做任何事情， Git 都会使用那些信息；

检测当前所有的配置信息：git config --list。

git config user.name

获取Git仓库

我们需要一个Git来管理源代码，那么我们本地也需要有一个Git仓库。

有两种方式获取到一个Git仓库：

  • 方式一：初始化一个Git仓库，并且可以将当前项目的文件都添加到Git仓库中（目前很多的脚手架在创建项目时都会默认创建一个Git仓库）；
  • 方式二：从其它服务器 克隆（clone） 一个已存在的 Git 仓库（第一天到公司通常我们需要做这个操作）；

方式一：初始化Git仓库

  • 该命令将创建一个名为 .git 的子目录，这个子目录含有你初始化的 Git 仓库中所有的必须文件，这些文件是 Git 仓库的核心，执行git init操作；
  • 但是，在这个时候，我们仅仅是做了一个初始化的操作，你的项目里的文件还没有被跟踪；意思是创建了一个git仓库，但是你的文件还没有添加进去。
  • 然后执行git add .将所有文件添加到暂缓区里面。
  • 然后执行git commit -m "附带信息"，执行完之后，目前所有的项目都添加到了本地的git仓库里面。

方式二：从Git远程仓库

git clone https://github.com/xxx/xxx.git

采取git clone的方式。

文件状态的划分

现在我们的电脑上已经有一个Git仓库：

  • 在实际开发中，你需要将某些文件交由这个Git仓库来管理；
  • 并且我们之后会修改文件的内容，当达成某一个目标时，想要记录下来这次操作，就会将它提交到仓库中；

那么我们需要对文件来划分不同的状态，以确定这个文件是否已经归于Git仓库的管理：

  • 未跟踪：当我们新创建文件没有添加到Git仓库管理中，我们需要通过add命令来操作；
  • 已跟踪：添加到Git仓库管理的文件处于已跟踪状态，Git可以对其进行各种跟踪管理；

已跟踪的文件又可以进行细分状态划分：

image-20221016112415040

这里可以分为三个：

  • staged：暂缓区中的文件状态；就是执行完git add .命令之后的状态。Git仅仅是在跟踪，但是没有添加到仓库里面，而是放在了索引区里面。
  • Unmodified：commit命令，可以将staged中文件提交到Git仓库，会将新加入的文件是已经修改的文件，一起进行提交。
  • Modified：修改了某个文件后，会处于Modified状态；修改之后的文件要重新添加到暂缓区，然后进行提交的。

image-20221016114705998

在工作时，你可以选择性地将这些修改过的文件放入暂存区；然后提交所有已暂存的修改，如此反复；

git status

我们在有Git仓库的目录下新建一个文件，查看文件的状态：

就可以使用命令git status或者使用git status -s和git status --short来进行使用。

image-20221016195836162

Untracked files:表示未跟踪的文件

  • 意思就是在之前的提交里面没有。
  • Git不会去跟踪，除非你git add之后才可以。

文件总体操作

git add . 
git commit -m "附带信息"

一 文件添加到暂缓区。

分为两种情况：

  • 第一种：新添加的文件，使用命令git add .，意味着Git开始进行跟踪文件了。
  • 第二种：修改了之前跟踪的文件，这个时候依旧需要先git add . ，然后在commmit。

二 忽略文件

一般我们总会有些文件无需纳入 Git 的管理，也不希望它们总出现在 未跟踪文件列表。

  • 通常都是些自动生成的文件，比如日志文件，或者编译过程中创建 的临时文件等；
  • 我们可以创建一个名为 .gitignore 的文件，列出要忽略的文件的模 式；

在实际开发中，这个文件通常不需要手动创建，在必须的时候添加自 己的忽略内容即可；

image-20221016203601625

比如创建的Vue项目自动创建的忽略文件：

  • 包括一些不需要提交的文件、文件夹；
  • 包括本地环境变量文件；
  • 包括一些日志文件；
  • 包括一些编辑器自动生成的文件；

在我们进行git add .的时候，会优先去查看.gitignore文件的。

三 git commit

当文件在暂存区准备就绪的时候，就可以提交了。

  • 每次在提交之前，可以使用git status可以看看，需要的文件是否已经放在了暂存区。
  • 然后再执行commit命令。
  • git commit -m "xxxx"，xxx代表室这些提交的一些操作信息，比如说：你增加了某个功能之类的。

当然如果我们修改了文件，然后每次先add后commit可能会感到比较麻烦，所以Git也给我们提供了一个方法，使得两个命令一起来使用。

git commit -a -m "xxxx"

注意：不要直接使用git commit -a，后面的一定要加上，如果使用就必须停掉当前的操作，在.git同级目录下使用rm -f .git/index.lock ，即可再次进行提交了。

Git校验和

Git 中所有的数据在存储前都计算校验和，然后以 校验和 来引用。

image-20221017205430137

  • Git 用以计算校验和的机制叫做 SHA-1 散列（hash，哈希）；
  • 这是一个由 40 个十六进制字符（0-9 和 a-f）组成的字符串，基于 Git 中文件的内容或目录结构计算出来；

查看提交历史：git log

当我们想要查看提交历史的时候可以使用该命令。除此之外还有两个命令

  • git log --pretty=oneline ：将信息在一行里面进行显示，或者说一些重要信息的显示。
  • git log --pretty=oneline --graph：图结构，在多分支的时候会显示出来。
image-20221017205615908

不传入任何参数的默认情况下，git log 会按时间先后顺序列出所有的提交，最近的更新排在最上面；

这个命令会列出每个提交的 SHA-1 校验和、作者的名字和电子邮件地址、提交时间以及提交说明；

版本回退

如果想要进行版本回退，我们需要先知道目前处于哪一个版本：Git通过HEAD指针记录当前版本。

  • HEAD 是当前分支引用的指针，它总是指向该分支上的最后一次提交；
  • 可以将它看做 该分支上的最后一次提交的快照；

image-20221017212104003

我们可以通过HEAD来改变Git目前的版本指向：

  • 上一个版本就是HEAD^，上上一个版本就是HEAD^^；
  • 如果是上1000个版本，我们可以使用HEAD~1000；
  • 当然我们也可以指定某一个commit id；
git reset --hard HEAD^
git reset --hard HEAD~1000

//校验和如果没有重复，选择7/8位都是可以的
git reset --hard 2d44982

但是这个时候，如果想要返回到之前的版本

git reflog  //找到之前的校验和
git reset --hard xxxx  //然后重新去到之前的版本。

远程仓库

什么是远程仓库（Remote Repository）呢？

  • 目前我们的代码是保存在一个本地仓库中，也就意味着我们只是在进行本地操作；
  • 在真实开发中，我们通常是多人开发的，所以我们会将管理的代码共享到远程仓库中；

那么如何创建一个远程仓库呢？

  • 远程仓库通常是搭建在某一个服务器上的（当然本地也可以，但是本地很难共享）；
  • 所以我们需要在Git服务器上搭建一个远程仓库；
  • 或者是使用第三方的Git服务器：比如GitHub、Gitee、Gitlab等等；

远程仓库的验证

常见的远程仓库有哪些呢？目前比较流行使用的是三种：

目前Git服务器验证手段主要有两种：

  • 方式一：基于HTTP的凭证存储（Credential Storage）；
  • 方式二：基于SSH的密钥；

方式一：HTTP凭证

因为本身HTTP协议是无状态的连接，所以每一个连接都需要用户名和密码，上一次输入用户名和密码，再次下载新的东西，还是需要输入的。

  • 如果每次都这样操作，那么会非常麻烦；
  • 幸运的是，Git 拥有一个凭证系统来处理这个事情；

下面有一些 Git Crediential(凭证、证书) 的选项：

  • 选项一：默认所有都不缓存。 每一次连接都会询问你的用户名和密码；
  • 选项二：“cache” 模式会将凭证存放在内存中一段时间。 密码永远不会被存储在磁盘中，并且在15分钟后从内存中清除；
  • 选项三：“store” 模式会将凭证用明文的形式存放在磁盘中，并且永不过期；
  • 选项四：如果你使用的是 Mac，Git 还有一种 “osxkeychain” 模式，它会将凭证缓存到你系统用户的钥匙串中（加密的）；
  • 选项五：如果你使用的是 Windows，你可以安装一个叫做 “Git Credential Manager for Windows” 的辅助工具；可以在 这里下载。
git add .
git commit -m "附带信息"
git push

这样远程仓库就可以看到改变了。

方式二：SSH秘钥验证

Secure Shell（安全外壳协议，简称SSH）是一种加密的网络传输协议，可在不安全的网络中为网络服务提供安全的传输环境。

SSH以非对称加密实现身份验证：

  • 例如其中一种方法是使用自动生成的公钥-私钥对来简单地加密网络连接，随后使用密码认证进行登录；
  • 另一种方法是人工生成一对公钥和私钥，通过生成的密钥进行认证，这样就可以在不输入密码的情况下登录；
  • 公钥需要放在待访问的电脑之中，而对应的私钥需要由用户自行保管；

如果我们想要尝试用SSH去访问Git仓库，那么我们就需要生成对应的公钥和私钥。

可以采取下面两个方式，注意最好在git bash里面进行操作，cmd里面可能会出现一些问题：

ssh-keygen -t ed25519 -C “your email"
ssh-keygen -t rsa -b 2048 -C “your email"

这两种方式都是可以的，只是加密的格式不同，推荐使用第一个。然后在gitee中将公钥内容复制粘贴进去就可以了。

同时我们可以继续修改一些东西，然后提交到远程仓库里面。

远程仓库的管理

查看远程地址：比如我们之前从GitHub上clone下来的代码，它就是有自己的远程仓库的：

image-20221019141619633

git remote
#or
git remote –v

其中 -v是verbose(信息、冗余)

// 添加远程仓库
git remote add <shortname> <url>
git remote add pb https://gitee.com/CSL369/leran-g.git

// 重命名远程地址
git remote rename gitlab glab

// 移除远程地址
git remote remove gitlab

本地连接远程

在本地仓库连接远程仓库之后，从远程仓库获取代码的时候会存在两个问题：

问题一：本地分支的上游分支（跟踪分支）

当前分支没有和远程的origin/master分支进行跟踪。

当前本地仓库所处的分支是master分支，但是不知道你要和远程仓库的哪一个分支进行连接。所以会报出这样的错误。

image-20221019223219923

在没有跟踪的情况下，我们直接执行pull操作的时候必须指定从哪一个远程仓库中的哪一个分支中获取内容；

// 解决办法
git branch --set-upstream-to=pb/master (设置上游分支)

问题二：拒绝合并不相干的历史

image-20221019223936887

原因：我们将两个不相干的分支进行了合并。

简单来说就是：过去git merge允许将两个没有共同基础的分支进行合并，这导致了一个后果：新创建的项目可能被一个丝毫没有经验的维护者合并了很多没有必要的历史，到一个已经存在的项目中，目前这个命令已经被纠正，但是我们依然可以通过-- allow-unrelated-histories选项来逃逸这个限制，来合并两个独立的项目；

git pull pb master --allow-unrelated-histories

给一个本地的git仓库添加远程仓库。同时指定一个方便使用的简写：现在你可以在命令行中使用字符串 pb 来代替整个 URL。

所以当我们想要pull下来代码的时候，需要执行下面的代码：

git branch --set-upstream-to=pb/master (设置上游分支)
git pull pb master --allow-unrelated-histories

这个时候我们可以直接执行git push将代码推送到远程仓库。

其他人在拉取代码的时候执行

git fetch
git merge
#or
git pull

远程仓库的交互

1 首先我们要从远程仓库clone代码到本地：

git clone xxxxxxxxx

2 将本地仓库的代码推送到远程仓库：默认情况下是将当前分支（比如master）push到origin远程仓库的；

git push 
#or
git push origin master

3 从远程仓库fetch代码：从远程仓库获取最新的代码

giit fetch
#or 默认情况是从origin获取代码的
git fetch origin

此时获取到的代码，并没有合并到本地仓库，只是保存在了.git文件里面，所以我们要将其合并过来。

前面的push和fetch都是和远程仓库建立连接的。

4 代码合并到本地

git merge

4 简洁写法

git pull
#or
git fetch + git merge(rebase)

git pull相当于是git fetch和git merge的结合。

常见的开源协议

image-20221021212230934

Git tag

对于重大的版本我们常常会打上一个标签，以表示它的重要性：

  • Git 可以给仓库历史中的某一个提交打上标签；
  • 比较有代表性的是人们会使用这个功能来标记发布结点（ v1.0 、 v2.0 等等）；

创建标签：

  • Git 支持两种标签：轻量标签（lightweight）与附注标签（annotated）；
  • 附注标签：通过-a选项，并且通过-m添加额外信息；

1 本地tag标签的创建

git tag v1.0.0
#or
git tag -a v1.1 -m "附注标签"

# 查看现有的tag
git tag

# 当我们想要查看的时候tag的时间和谁标注的
git show  v1.0.0

2 推送到服务器

默认情况下，git push 命令并不会传送标签到远程仓库服务器上。

在创建完标签后你必须显式地推送标签到共享服务器上，当其他人从仓库中克隆或拉取，他们也能得到你的那些标签；

# 将当前的tag推送到远程服务器
git push origin v1.0.0

# 提交所有的tag
git push origin --tags

3 删除tag标签

# 删除本地的tag标签
git tag -d v1.0.0

# 删除服务器的tag标签
git push origin -delete v1.0.0

4 切回到某个tag

git checkout v1.0.0

如果你想查看某个标签所指向的文件版本，可以使用 git checkout 命令； 通常我们在检出tag的时候还会创建一个对应的分支；

Git 的提交对象

几乎所有的版本控制系统都以某种形式支持分支。

  • 使用分支意味着你可以把你的工作从开发主线上分离开来，以免影响开发主线。

在进行提交操作时，Git 会保存一个提交对象（commit object）：

  • 该提交对象会包含一个指向暂存内容快照的指针；
  • 该提交对象还包含了作者的姓名和邮箱、提交时输入的信息以及指向它的父对象的指针；
    • 首次提交产生的提交对象没有父对象，普通提交操作产生的提交对象有一个父对象；
    • 而由多个分支合并产生的提交对象有多个父对象；

当我们执行git add . 的时候，会将所提交的内容保存在如下所示

image-20221023094525616

里面所保存的是2进制的文件，如果想看的话执行，info和pack是自带的文件夹：

image-20221023100846142

# 9a文件夹名字，dc文件开头，最少两位，最多的话能确定文件唯一性就好了
# 返回的bolb代表是二进制的文件
git cat-file -t 9cdc
blob 

# 如果想要看到具体的代码，执行下面代码
git cat-file -p 9cdc

当我们执行git commit -m ""之后，会多出来两个文件夹

image-20221023101537919

image-20221023102917164

首先我们可以根据git log找到commit的校验和，然后根据commit的校验和找到一个tree的校验和，然后根据tree的校验和，去找到我们真实提交的代码。

image-20221023103447869

image-20221023103738349

所以这个时候就不难理解了，当我们git add .的时候，只是存在了后面的文件，但是还没有添加索引。

image-20221023104431464

git master分支

Git的分支，其实本质上仅仅是指向了提交对象的可变指针。

  • Git 的默认分支名字是 master，在多次提交操作之后，你其实已经有一个指向最后那个提交对象的 master 分支；
  • master 分支会在每次提交时自动移动；

image-20221023111949692

Git 的 master 分支并不是一个特殊分支。

  • 它就跟其它分支完全没有区别；
  • 之所以几乎每一个仓库都有 master 分支，是因为 git init 命令默认创建它，并且大多数人都懒得去改动它；

git创建分支

Git 创建新分支：它只是为你创建了一个可以移动的新的指针；

比如，创建一个 testing 分支， 你需要使用 git branch 命令：git branch testing

image-20221023113652555

分支的切换：指向git checkout xxxx，即可以指向当前要切换的分支。此时的HEAD就指向了切换之后的活跃分支。

image-20221023115138885

创建新分支的同时切换过去：通常我们会在创建一个新分支后立即切换过去；

这可以用 git checkout -b xxxx  一条命令搞定。

本地分支

让我们来看一个简单的分支新建与分支合并的例子，实际工作中你可能会用到类似的工作流。

  • 开发某个项目，在默认分支master上进行开发；
  • 实现项目的功能需求，不断提交；
  • 并且在一个大的版本完成时，发布版本，打上一个tag v1.0.0；

继续开发后续的新功能，正在此时，你突然接到一个电话说有个很严重的问题需要紧急修补， 你将按照如下方式来处理：

  • 切换到tag v1.0.0的版本，并且创建一个分支hotfix；

image-20221024210655538

想要新建一个分支并同时切换到那个分支上，你可以运行一个带有 -b 参数的 git checkout 命令：

git checkout –b hotfix，如果是想要先创建分支，然后进去

git branch xxxx
git checkout xxxx

分支上开发、修复bug：

  • 我们可以在创建的hotfix分支上继续开发工作或者修复bug；
  • 当完成要做的工作后，重新打上一个新的tag v1.0.1；

切换回master(git checkout master)分支，但是这个时候master分支也需要修复刚刚的bug：所以我们需要将master分支和hotfix分支进行合并；

# 切换master分支
git checkout master
#合并修改的Bug
git merge hotfix

这个时候出出现合并冲突的问题，如下图：

image-20221024215204932

这个时候我们需要进行一个选择：

image-20221024220108389

大多数情况下，我们会现在都保留，然后再进行add和commit就可以了。

分支的删除和查看

如果我们希望查看当前所有的分支，可以通过以下命令：

# 查看当前所有的分支
git branch #

# 同时查看最后一次提交
git branch –v

#	查看所有合并到当前分支的分支
git branch --merged #

# 查看所有没有合并到当前分支的分支
git branch --no-merged #

如果某些已经合并的分支我们不再需要了，那么可以将其移除掉：所移除的是commit提交的指针，而是不是文件

# 删除当前分支
git branch –d hotfix # 

# 强制删除某一个分支
git branch –D hotfix #

Git的工作流(git flow)

由于Git上分支的使用的便捷性，产生了很多Git的工作流：

  • 也就是说，在整个项目开发周期的不同阶段，你可以同时拥有多个开放的分支；
  • 你可以定期地把某些主题分支合并入其他分支中；

比如以下的工作流：

image-20221025203035370

  • master作为主分支；
  • develop作为开发分支，并且有稳定版本时，合并到master分支中；
  • topic作为某一个主题或者功能或者特性的分支进行开发，开发完成后合并到develop分支中；

image-20221025205030319

Git的远程分支

当我们将某个项目clone下来之后，我们可以创建自己的分支然后进行开发，在最后时候可以与master分支进行合并。

git clone xxxx

# 当前所在分支 master/main
git checkout -b dev

# 本地分支推送到远程仓库
git push origin xxxx

# 删除远程分支
git push origin --delete xxxx

当我们clone仓库地址之后，使用git branch会发现只有master分支

# 切换到dev分支，并且进行跟踪
git checkout --track origin/dev

# 简写
git checkout dev

当我们这样写的时候，首先会自动检查本地有没有dev分支，如果没有，自动再去检查远程仓库，有没有dev分支。如果有的话，就会自动创建一个本地的dev分支，并且跟踪远程仓库的dev分支。

Git rebase

在Git中整合不同分支有两种方式：merge和rebase。

下面简答来了解一下rebase：所谓的rebase有 变基 的说法。

现在我们有两个分支，一个是masetr另外一个是feature分支

此时除了在masetr分支，直接git merge feature之外，还可以使用rebase方法。

# 首先切回到feature分支
git checkout feature

# 执行rebase
git rebase master
image-20221026100054238 
#	切回master分支
git checkout master

# 合并feature分支
git branch feature
image-20221026100331423

此时master就指向了最新的位置了。

公司之后的处理

1 项目已经存在，并且远程仓库也已经建好了

# 1 下载已经存在的代码
git clone  xxxxxxx

# 2	在自己电脑进行开发

# 3 将代码添加到本地仓库
git add .
git commit -m "注释"
git commit -a -m "注释"

# 4	在提交之前最好将同事的代码拉取下来，然后一起进行提交
git pull

# 5	将自己的代码提交到远程服务器里面
git push

2 开发新项目，并且项目由自己来搭建

方案一：

# 1	先去创建一个远程仓库

# 2	clone下来
git clone

#	3	在clone下来的项目进行操作

#	4	后面操作就是一样的了

方案二：

# 1	先在本地进行框架搭建

# 2	初始化本地仓库
git init 
git add . 
git commit -m "注释"

#	3	和远程仓库进行连接
git remote add origin xxxxx

#	4	将本地仓库的maste分支和远程的maste分支建立连接
git branch --set-upstream-to=origin/master

# 5	消除git pull 拒绝合并不相干的历史
git pull origin master --allow-unrelated-histories
git fetch
git merge --allow-unrelated-histories

# 6 将本地代码推送到远程
git push

Git命令速查表

image-20221026144146276

avatar
文章
阅读
粉丝