AI 助理
备案控制台
开发者社区 开发与运维 文章 正文

对象准备入手前端开发，我连夜给ta准备了这篇git指南之终极奥义

2022-08-30 257
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
简介： 对象是真的，连夜码字是真的，Git指南也是真的

标题：对象准备入手前端开发，我连夜给她准备了这篇git指南之终极奥义

引言：持续性更新下去，穷举法列出各种场景，已简洁通俗的处理方式让这篇文章成为你的git辞典

1、基础篇

1.1、git理解

1.1.1、仓库

远端仓库：线上代码的落库地方；

本地仓库：远端仓库克隆到本地的地方；

远端仓库本地副本：储存了远程仓库各分支数据在本地的一个副本，用作同步修改记录；

1.1.2、区域

工作区：当前的工作区域，日常开发的环境；

暂存区：执行git add 之后，修改的文本会被临时存到到此；

历史记录区：执行git commit 的所有记录都在此处；

1.1.3、状态

已修改（modified）：文本发生了变更，但还未被标记为暂存（明亮色）；

已暂存（staged）：对发生变更的文件基于当前分支做个标记，让其加入到下次提交的暂存区中（亮色）；

已提交（committed）：变更的文件安全的保存到了本地仓库中（亮色消失）；

1.2、git配置

安装

安装包下载地址：https://git-scm.com/downloads

图形化工具SourceTree下载地址：https://www.sourcetreeapp.com/，先不着急用它，先把命令操作玩熟

注册账号

gitHub账号注册地址：https://github.com/

按要求注册一个账号，设置自己的username & email & password，牢牢记住。

本地配置

1、本地配置自己的账号信息

本地安装好Git后，打开Git Bash，依次配置自己的账号，邮箱（建议qq邮箱即可）

  • git config --global user.name "yourName"：配置账号
  • git config --global user.email "yourEmail"：配置邮箱
  • git config --list：可以查看自己的配置信息了

2、本地生成SSH公钥

打开Git Bash，生成git密钥，然后将公钥内容设置到gitHub中；

  • ssh-keygen -t rsa -C "yourName"：生成公钥的信息
  • 命令执行完后，一直enter键回车即可（下文讲述如何生成多个公钥）；
  • 大概在C盘，用户，用户名文件夹，.ssh下面，有一个id_rsa.pub文件，文本方式打开它，然后复制其内容；
  • 登录GitHub，右上角自己头像那儿，下拉选择Settings，页面跳转后，左侧点击SSH and GPG Keys；
  • 点击New SSH key，Ttile任意填写（建议不要瞎写，最好有记忆特征），Key type默认为Authentication key即可，把上面复制的id_rsa.pub内容粘贴进Key里面，点击按钮Add SSH key即可；

1.3、命令汇总

git clone

git clone -b targetBranch xxxx.git：将指定的代码仓库克隆到本地；

  • -b：克隆指定的分支（或者tag也行），如果没有-b，则默认克隆主分支；

git init

从远端直接克隆拉下来的代码，就是一个仓库。但是如果本地是一个全新的环境，想提交到远端上去，就必须执行git init命令，当当前目录初始化为一个git仓库，再继而完成后续操作；

git remote

处理本地仓库和远程仓库之间的关系，操作步骤有很多，这里只是简单介绍，下文详述使用

  • git remote add xxxx.git：将本地仓库与指定远程仓库关联起来，通常用于新项目的第一次初始化时；
  • git remote rm xxxx.git：将本地仓库与指定远程仓库断开，（用得少）；
  • git remote -v：查看远程仓库的git 地址；
  • git remote update：对照远程仓库，更新本地仓库（通常用于协作，远程仓库有分支，tag……之内的变更，本地需要更新一下）

git branch

  • git branch ：查看本地分支（会标明当前分支），
  • git branch -a：查看本地&远程分支（全量的）（会标明当前分支），换成-r表示只查看远程分支；

git checkout

切换&创建分支

  • git checkout dev_ike：本地分支切换到dev_ike上（前提是它得存在）
  • git checkout -b dev_ike：从本地当前分支上，在本地创建一个新的分支dev_ike，
  • git checkout -b dev_ike origin/dev_ike：基于远程分支dev_ike，在本地创建一个新的分支dev_ike

git status

查看当前分支的变更和暂存情况，会列出当前分支名，发生变更的文件，已加入暂存区的文件

.gitignore

创建.gitignore文件，可以依次配置需要被忽略的文件或者文件夹，支持通配符，表明这些内容无需被纳入git管理，属于本地私有

例如一些本地IDE环境不需要提交到远程

.idea/
.vscode
.DS_Store
*.code-workspace
*.retry

git add

文件发生变更之后，在提交之前，需要先把它们加入到暂存区，支持通配符；

  • git add service.go user.go：把service.go和user.go两个文件加入到暂存区
  • git add *.go：把所有的.go文件加入到暂存区；
  • git add .：把当前目录下所有变更的文件都加入到暂存区；
  • git add -A：把当前仓库内所有变更的文件都加入到暂存区（支持跨目录结构）；

git reset

回滚重置，有其他的操作可以替代，这里只介绍一种常用的：

  • git reset HEAD .：本地分支文件发生了变更，被误操git add到暂存区了，执行这个命令可以把变更文件从暂存区恢复出来

git commit

提交变更到本地仓库，必须在文件加入暂存区之后提交才有效；

  • git commit -m "重置密码后强制登录"：提交代码，-m表示对这次提交的文本描述，认真编写，方便溯源

    养成习惯：永远都不要使用git commit -am，add 和 commit一定要分开进行

git push

将本地仓库的提交内容推送到远程仓库，这是必要的一步。

  • git push origin dev_ike：例如：当前分支为dev_ike，现将本地提交项全部推送到远程仓库的dev_ike

    适用于所有场合，如果远程没有dev_ike分支，证明dev_ike是本地新建的分支，该操作会将这个新分支和提交项一并推送到远端；如果远程已存在dev_ike，且commit落后本地dev_ike，那么这就是一次正常的push，如果远端dev_ike分支有新的提交（协同开发），就涉及冲突项的解决，下文讲述；

  • git push -set-upstream origin dev_ike`：或者也可以使用这个，表明与远程分支建立联系，后续直接git push即可

git pull

将远端仓库指定分支领先的提交项，拉取到本地并合并到本地分支；

如果之前推送使用了-set-upstream，表明本地分支与远端分支已有了联系，可以直接git pull；

  • git pull origin dev_ike：适用于所有场合，即：当前本地分支是dev_ike，拉取远程分支dev_ike最新的代码；

git rm

从本地仓库中删除指定文件&文件夹的git管理，多适用于文件&文件夹已经被纳入git仓库管理，此时再将其添加到.gitignore是无效的，可以使用git rm先将其从git管理中删除，然后再添加到.gitignore中；

  • git rm *.retry：从本地git管理中删除所有的.retry文件；
  • git rm -r .idea/：从本地git管理中删除.idea目录；
注意，这个命令不仅仅将文件从git管理中删除了，而且也将文件从磁盘中删除了，所以正确的做法是，先保存副本，然后执行该命令，再将副本拷回来，然后将副本路径添加到.gitignore中。

git fetch

将远端仓库指定分支领先的提交项，拉取到本地。但是并不会合并到本地分支。

理解就是：本地已有了变更，但是还没变更完，想先把远程的更新拉下来，但又不想着急合并，怕影响自己的调试逻辑.
  • git fetch origin dev_ike：将远端分支的更新拉取到本地，但不着急合并到本地分支；

git merge

将指定分支的代码合并到当前分支。

例如上文，如果使用完git fetch，之后，本地分支的开发也完成，就需要将fetch代码合并到本地分支：

git merge origin/dev_ike：将指定分支的代码，合并到当前分支；

git log

查看提交记录，即commit的记录，会看到提交时间，提交人，提交描述，以及核心的commitId；

  • git log：查看当前分支的提交记录

git diff

作用与发生变更的文件，主要看前后变更了什么内容。

  • git diff service.go：看看service.go文件的哪些行发生了变更，编辑器内部的终端会进入查看模式，按q退出，按enter继续下一行；

git reflog

查看当前用户的所有git操作，checkout，pull，push，merge……

  • git reflog

git cherry-pick

将指定分支的commit内容，复制到当前分支来，多用于代码提交错了分支，又懒得返工处理；

  • git cherry-pick release/dev_ike 6461c3b1：将release/dev_ike的commitId为6461c3b1那次提交项，复制到当前分支；

    commitId可以多个，空格隔开即可

git tag

标签操作，很多应用在版本迭代过程中，会用标签来管理版本（记住：标签跟分支不要重名）

  • git tag：查看仓库的标签列表；
  • git tag tagv1.3.5：基于本地仓库当前的commitId，打上标签tagv1.3.5；
  • git push origin tagv1.3.5：将标签tagv1.3.5推送到远端仓库；
  • git tag -d tagv1.3.5：删除本地标签（删除不掉的话，用-D试试）；
  • git push origin --delete tagv1.3.5：删除远端标签；
  • git tag -l v1.3：筛选标签

2、应用篇

2.1、公钥配置方案

Windows

见上述本地配置。

Mac

  • command + space，输入“终端”，打开它；
  • 配置git：git config --global user.name "yourName"；
  • git config --global user.email "yourEmail"；
  • 执行：ssh-keygen -t rsa -C yourEmail；（可以覆盖执行，直接覆盖原信息）
  • 找到密钥文件：open ~/.ssh；
  • 或者直接：cd /Users/${pcYourName}/.ssh/，然后打开目录下的id_rsa.pub文件

Linux

配置步骤一样，公钥文件应该在/root/.ssh/，没有的话，全局搜一下吧find / -name id_rsa.pub

多套公钥

有时候，公司自有的Git服务器，对外自己又需要使用gitHub，可准备两套密钥分别配置上自有Git和GitHub上，

生成密钥的方式，区分开邮箱（区分开自己的gitHub账号和公司分配给自己的git账号），

ssh-keygen -t rsa -C "git账号的邮箱"

执行后，在这一步输入id_rsa需要保存的文件名，注意别重名，不然覆盖了

Enter file in which to save the key (/Users/zheng/.ssh/id_rsa): your id_rsa_name

一路回车，即可。密钥位置：（跟上面的文件位置一样），配置上传方法也是一样；

2.2、妙用checkout

切换分支

# 切换到本地分支dev/v1.3上面去
git checkout dev/v1.3

创建分支

# 基于本地dev/v1.2分支，创建一个本地新分支dev/v1.3，并且切换到它上去
git checkout -b dev/v1.3 dev/v1.2

# 基于远端dev/v1.2分支，创建一个本地新分支dev/v1.3，并且切换到它上去
git checkout -b dev/v1.3 origin/dev/v1.2

# 基于本地当前分支，创建一个本地新分支dev/v1.3，并且切换到它上去
git checkout -b dev/v1.3

清空文件变更

# 清空test.go的变更，回归到初始状态，未加入暂存区的（即未使用add）
git checkout test.go

# 清空本地分支当前目录下所有文件的变更，回归到初始状态，未加入暂存区的（即未使用add）
git checkout .

切换commitId

在排查历史遗留bug的时候，有时候需要看当前程序包是基于哪个分支的哪个commit编译构建的，然后好查看具体的代码，其实，开发者也是可以依据commitId来拉取分支。

# 切到版本分支，从log中找到提交的commitId
git log

# commitId也是可以被checkout的，比方说查询到的commitId为下述这个
git checkout 22dfbf1f907764c5ae70381b8191104f9af21d8c

# 基于commitId检出，其实是临时的分支，所以最好还是基于这个“临时”之上，拉取一个新的分支，方便溯源.
# 假设当前版本为v1.2，基于临时分支创建一个新分支名为：bugfix/v1.2
git checkout -b bugfix/v1.2 22dfbf1f907764c5ae70381b8191104f9af21d8c

切换tag

有的版本是打tag的，所以排查历史bug的时候，需要先切换到对应tag下面，然后基于tag构建出本地的bugfix。

# 查看目标tag
git tag

# 后续……跟commitId检出是一样的，

2.3、分支删除

如果只是想删除掉本地仓库的分支，则无需push --delete到远端，如果是想在git仓库中，删除掉目标分支，则需要同时删除本地分支和远程分支。

# 删除本地分支dev/v1.2，如果该分支中有提交项未进行合并，则终止删除动作
git branch -d dev/v1.2

# 删除本地分支dev/v1.2，强制删除，包括删除掉该分支中已提交但未进行合并的项
git branch -D dev/v1.2

# 删除远端分支dev/v1.2，（从远端仓库中删除）
git push origin --delete dev/v1.2

2.4、分支合并&提交

如果想把自己在开发分支上新增的提交合并到主分支，然后推送到远端，推荐先切换到主分支上拉一下最新的提交，然后再合并，方便处理冲突；

# 先切换到主分支（假设当前主分支为master）
git checkout master

# 拉取主分支最新的提交（以防冲突）
git pull origin master

# 将开发分支dev/v1.2上的提交合并到master分支上来
git merge dev/v1.2

# 将合并的提交项，及时推送到远端master分支上
git push origin master

2.5、查看文本变更

有时在编辑区，不管是作草稿设计，还是实际开发，容易忘记自己改了什么东西，是否需要提交，可以diff一下，查看文件变更了哪些

# 查看该文件变更了哪些内容
git diff service.go

# 如果是一些无关紧要，甚至手误导致错误的变更，可以复原它
git checkout service.go

3、场景篇

3.1、新项目推送到远端

以GitHub为例，想把本地已有的项目推送到gitHub上。

  1. 打开个人主页，点击右上角头像，Your repositories，点击绿色按钮，News;
  2. 取名Repository name，建议跟项目名称保持一致最好，依次决定是否选择下面其他的选项（是否公开&私有）；
  3. 点击按钮Create repository，接下来的页面会生成该仓库的git地址；
  4. 回到本地项目目录，打开Git Bash，执行git init，初始化会生成git相关配置信息；
  5. 是否决定创建.gitignore文件，将不需要推送到远程仓库的文件路径先添加到.gitignore中；
  6. git add .，将当前目录所有文件加入到暂存区，git add会主动忽略.gitignore配置的文件和目录；
  7. git commit -m "first commit"，全部提交；
  8. git branch -M master，创建主分支名称为master；
  9. git remote add origin yourPorjectGitUrl，添加项目的git地址（https协议和ssh协议都可以）；
  10. git push -u origin master，将master分支推送到远端，第一次提交master分支添加-u参数后，后续基于该分支就可以直接git push 了。
  11. 基于此，远程仓库建好，并与本地仓库相互关联起来；

3.2、从远端拉取新项目

以公司项目为例，会提供git地址和对应的分支；

  1. git clone -b targetBranchName gitUrl；拉取目标分支的代码；
  2. git checkout -b ike/notes；基于当前目标分支，先检出一个自己的分支（名称自取）。这一步无关紧要，但是很有必要。绝大多数程序员不喜欢写注释，或者注释写的很糟，作为开发者，拿到代码的第一瞬间别想着迅速开发，先完整熟悉一遍，如果能调试更好，然后在自建的分支上标明好注释，做到细心且敏感。这个用于注释的分支属于本地所有，注释完需要先commit，在切换到开发分支，但是不要push到远端，它只存在自己本地；

3.3、开发&提交

更新项目

如果在切分支的时候，发现目标分支在web界面上可以查到，但是本地git branch -a时差不多，执行一下这个命令，更新一下本地仓库就有了。

git remote update

独立开发

独立开发一般对分支，版本的管控要求不严格，也不会遇到提交冲突的场景，没什么注意事项，直接基于开发分支上调试开发即可；

  1. git status。本地工作区文件发生变更后，可以git status，查看哪些文件发生了变更，然后哪些文件需要加入到.gitignore文件中（以便在后续的add，commit操作中忽略它们），哪些需要添加到暂存区，以便提交；
  2. git add。在第一步之后，选择需要提交的文件，全选的话，git add .，或者也可以指定具体的文件（有的不需要提交），git add xxx yyy，空格分隔，或者也支持通配符git add *.go，只将所有的.go文件加入暂存区……
  3. git commit。第二步操作完毕，将暂存区变更提交，git commit -m "这是你对这次提交的注释说明"；
  4. git push。提交完成后，将本地变更推送到远端仓库，假设本地分支对应的是远端分支master：git push origin master，如果使用git push -u origin master，表示将本地master分支与远端master关联起来，后续在此分支上的推送直接git push即可；

一不小心提交错了

1、直接执行的git add .，发现其实有些自己本地的文件不需要加入暂存区，挪出来的办法：

# 执行该命令，将暂存区的文本全部复原回去
git reset HEAD .

# 重新根据自己需要加入暂存区的文件add，通配符，目录，空格分开……都可以
git add *.go *.js

2、已经执行了commit，但是推送到远端的时候想到，有些新创建的文件不需要推送远端上去，

# 将不需要推送到远端的这些文件，复制一份出来，在其他的目录临时保存
# 然后执行，将不需要推送到远端的这些文件删掉，同样支持通配符，多文件空格分开；
git rm xxx.go

# 再进行正常的推送。
git push origin xxxxx

# 然后把备份复制的文件复制回来到目录中，此时文件是新创建的，属于变更类型，将其加入到.gitignore文件中，作为后续git管理的忽略。
该方法只适用于，这些文件在add的时候，是自己新创建的，如果是已存在的，建议还是手动改两遍在提交推送，因为git rm之后，再推送的话会直接把远端的这些文件也删除掉的。

3、如果是已经push到远端，发现刚刚有些新建的文件，不需要推送远端上去，可以同样按第二条的来一遍，来完之后也正常push，然后将备份的文件陆续加入.gitignore中，如果是有些内容不需要推送到远端上去，直接本地做一次还原的修改，git add ,git commit ,git push。重新执行一次添加，提交，推送吧。

协同开发，解决冲突

协同开发的提交步骤跟独立开发差不多，最好严格按照规范，因为处理冲突的场合时有发生。

1、正常提交遇到的冲突，git add ，git commit，在git push的时候报错提示如下：

error: 推送一些引用到 'https://github.com/994625905/*******' 失败
提示：更新被拒绝，因为远程仓库包含您本地尚不存在的提交。这通常是因为另外
提示：一个仓库已向该引用进行了推送。再次推送前，您可能需要先整合远程变更
提示：（如 'git pull ...'）。
提示：详见 'git push --help' 中的 'Note about fast-forwards' 小节。

表示远程仓库的提交领先了本地，禁止直接推送上去，需要先pull拉下来，看是否有文件变更重叠需要调整，然后在push上去；

2、如第一步所致，执行了git pull，出现如下提示（如果没有出现，则合并正常，没发现文件变更重叠，继续执行git push 吧）：

remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 3 (delta 2), reused 0 (delta 0), pack-reused 0
展开对象中: 100% (3/3), 689 字节 | 229.00 KiB/s, 完成.
来自 https://github.com/994625905/ike_httpToDubbo
 * branch            master     -> FETCH_HEAD
   e837b04..363af70  master     -> origin/master
自动合并 settings.js
冲突（内容）：合并冲突于 settings.js
自动合并失败，修正冲突然后提交修正的结果。

以上提示说明，settings.js文件发生了冲突，需要手动处理，然后重新add，commit，push。冲突文件如下：

'use strict'
const fs = require('fs');
const settingFile = './setting.json';

process.env.settingsFile = settingFile;
process.env.settings = fs.existsSync(settingFile) ? fs.readFileSync(settingFile).toString() : '{}';

let default_settings = {
    appName: 'ike_httpToDubbo',
    bindIP: '0.0.0.0',
    bindPort: 8080,
    config: './config.json',
}
let settings = Object.assign({}, default_settings, JSON.parse(process.env.settings));
// 领先提交
exports.settings = settings;

<<<<<<< HEAD
// 测试冲突场景
exports.configs = JSON.parse(fs.readFileSync(settings.config).toString())
=======
exports.configs = JSON.parse(fs.readFileSync(settings.config).toString())
>>>>>>> 363af70c5a1bd3e1a1f703b40e3ffb415e21b849

在执行git pull时，git会自动合并，如果远端与本地，对于同一文件的同一行处发生了变化，它会给出标记提示

<<<<<<< HEAD

这里标记为1号代码块，是自己本地 对于这些行 的变更内容与远程发生冲突，所以被隔离了起来

=======

这里标记为2号代码块，是从远端pull下来，对于这些行 的变更内容与本地发生冲突，所以被隔离了起来，>>后面跟的是commitId

>>>>>>> 363af70c5a1bd3e1a1f703b40e3ffb415e21b849

所以处理方式很简单，只需要分清楚，到底是1号代码块的逻辑符合需求，还是2号代码块的逻辑符合需求，或者两者需要融合一下，然后针对1，2号代码块做调整，删除<<<<<HEAD，======，>>>>>这些东西，重新add，commit，push即可。

注：这种冲突文件，冲突块，可能不止一处，需要结合git提示信息，在冲突文件内搜索查看综合处理。

针对1，2步骤可知，在add，commit提交代码前，最好是先执行pull动作，检测是否冲突；

3、本地文件发生了变更，在未执行add, commit提交前，主动先pull的时候，出现了冲突：

wangjinchao@IKEJCWANG-MB0 ike_httpToDubbo % git pull origin master
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 3 (delta 2), reused 0 (delta 0), pack-reused 0
展开对象中: 100% (3/3), 718 字节 | 239.00 KiB/s, 完成.
来自 https://github.com/994625905/ike_httpToDubbo
 * branch            master     -> FETCH_HEAD
   6b3d34a..3caa033  master     -> origin/master
更新 6b3d34a..3caa033
error: 您对下列文件的本地修改将被合并操作覆盖：
        settings.js
请在合并前提交或贮藏您的修改。
正在终止

解决方案两种：

省事版：

# 将提示的冲突文本临时备份到别处，例如上面的settings.js（多个冲突的话，会一一列举出来）
# 然后将冲突的文件恢复到原始状态，即取消变更内容，多个文件的话，空格隔开即可
git checkout settings.js

# 在重新执行git pull，就能顺利拉下来了，
git pull origin master

# 然后对比刚备份的文件和更新后的文件（文件对比工具，或者人肉对比），重新编辑它

# 完事之后，在执行add , commit , push

费事版：

# 基于当前分支新建一个临时分支，并切换过去，此时本地的变更都会被携带到新分支上
git checkout -b temp_ike

# 可以先用status看一下哪些文件发生了变更，然后add，commit
git status
git add .    # 将当前目录所有的变更文件加入到暂存区
git commit -m 'commit log'

# 这样一来，新的变更内容被存在了新分区中，而原来的分支还是原样

# 然后切换回去，重新执行pull，就能成功拉取下来了，假设之前分支为master，
git checkout master
git pull origin master

# pull成功后，就需要把刚刚临时分支的提交内容给合并过来，然后重新push到master分支上
git merge temp_ike

# 会发现冲突提示，列举冲突文件
自动合并 test.js
冲突（内容）：合并冲突于 test.js
自动合并失败，修正冲突然后提交修正的结果。

冲突块如下所示：跟上文解决冲突方式一样，手动解决test.js的冲突块，

<<<<<<< HEAD
// 测试冲突
let test = "this is test"
=======
let test = "this is test"

// 解决冲突
>>>>>>> temp_ike
<<<<<<< HEAD

这里标记为1号代码块，是当前分支 对于这些行 的变更内容与merge 的分支发生冲突，所以被隔离了起来

=======

这里标记为2号代码块，是merge 的分支，对于这些行 的变更内容与当前分支发生冲突，所以被隔离了起来，>>后面跟的是merge分支名称

>>>>>>> temp_ike

所以处理方式很简单，只需要分清楚，到底是1号代码块的逻辑符合需求，还是2号代码块的逻辑符合需求，或者两者需要融合一下，然后针对1，2号代码块做调整，删除<<<<<HEAD，======，>>>>>这些东西，同样这些冲突块可能不止一处，需要逐一调整，然后重新add，commit，push即可。

以上费事版方案中的merge：适合所有分支代码合并时出现了代码冲突的解决方案。

3.5、快速构建分支

给一段快速构建分支的脚本，适应场景如下，一个项目由多个代码仓库构成，且本地这些代码都位于同一路径下面，分支行政约束统一为开发分支：develop/版本号，发版分支：release/版本号（禁止提交，必须有develop分支合并过来）。现在一个版本已发版，需要根据该版本的发版分支重新全量新建新版本的分支；

#!/bin/bash

function help() {
    echo ""
    echo "Usage:"
    echo "  $0 dir targetBranch newBranch"
    echo "  example:"
    echo "      $0 /root/ikejcwang/rio/src v1.4.1 v2.0"
    echo ""
    # shellcheck disable=SC2242
    exit -1
}

if [ $# -lt 2 -o "$1" == "-h" -o "$1" == "-help" ]; then
  help
fi

cd "$1"

dirList=$(ls | awk '{print $1}')
bashBranch="$2"
newBranch="$3"

for (( i = 0; i < ${#dirList[@]}; i++ )); do
    cd "${dirList[i]}"
    git remote update
    git branch -a |grep "${newBranch}"
    if [ $? -ne 0 ]; then
      git branch -a |grep "release/${bashBranch}"
      if [ $? -eq 0 ]; then
        git checkout -b develop/"${newBranch}" origin/release/"${bashBranch}"
        git push origin develop/"${newBranch}"
        git checkout -b release/"${newBranch}" origin/release/"${bashBranch}"
        git push origin release/"${newBranch}"
      fi
    else
      echo "${dirList[i]} already has ${newBranch}"
      # shellcheck disable=SC2242
      exit -1
    fi
    cd ../
done
# 用法，查看用法详细
./gitBranch.sh help

# 实操，代码仓库均位于/root/ikejcwang/rio/src下，需要从1.4.1上，构建出2.0的 develop 和 release
./gitBranch.sh /root/ikejcwang/rio/src v1.4.1 v2.0

3.5、gitmodules使用

3.6、SourceTree使用

未完待续，抽时间再写了

文章标签：
Go
Shell
前端开发
开发工具
网络安全
数据安全/隐私保护
git
程序员
安全
开发者
关键词：
前端git
前端开发GIT
前端奥义
前端ta
ike潮
目录
相关文章
海拥
|
7月前
|
存储 前端开发 开发工具
前端开发中的Git版本控制：构建可靠的协作和代码管理
前端开发中的Git版本控制：构建可靠的协作和代码管理
海拥
88 0
html的七十二变
|
1月前
|
前端开发 持续交付 开发工具
理解前端开发中的 Git - Rebase
Git Rebase 是前端开发中常用的一种版本控制操作，用于将一个分支的更改整合到另一个分支。与合并（Merge）不同，Rebase 可以使提交历史更加线性整洁，有助于保持代码库的清晰和可维护性。通过 Rebase，开发者可以将特性分支的改动应用到主分支上，同时保留或重写提交记录。
html的七十二变
42 9
土木林森
|
1月前
|
监控 前端开发 JavaScript
前端开发的终极奥义：如何让你的代码既快又美，还不易出错？
【10月更文挑战第31天】前端开发是一个充满挑战与机遇的领域，本文从性能优化、代码美化和错误处理三个方面，探讨了如何提升代码的效率、可读性和健壮性。通过减少DOM操作、懒加载、使用Web Workers等方法提升性能；遵循命名规范、保持一致的缩进与空行、添加注释与文档，让代码更易读；通过输入验证、try-catch捕获异常、日志与监控，增强代码的健壮性。追求代码的“快、美、稳”，是每个前端开发者的目标。
土木林森
39 3
shiningrise
|
2月前
|
前端开发 开发工具 git
如何清理 docker 磁盘空间+修改 Gitea 服务器的 Webhook 设置+前端一些好学好用的代码规范-git hook+husky + commitlint
如何清理 docker 磁盘空间+修改 Gitea 服务器的 Webhook 设置+前端一些好学好用的代码规范-git hook+husky + commitlint
shiningrise
42 5
shiningrise
|
2月前
|
前端开发 开发工具 git
搭建Registry&Harbor私有仓库、Dockerfile（八）+前端一些好学好用的代码规范-git hook+husky + commitlint
搭建Registry&Harbor私有仓库、Dockerfile（八）+前端一些好学好用的代码规范-git hook+husky + commitlint
shiningrise
25 0
游客fz577umxdejsg
|
4月前
|
JavaScript IDE 前端开发
前端开发工具配置 nodejs & git & IDE
前端开发工具配置 nodejs & git & IDE
游客fz577umxdejsg
77 2
小周sir
|
4月前
|
存储 前端开发 开发工具
前端常用的git操作
【8月更文挑战第24天】前端常用的git操作
小周sir
31 1
一杯龙井解千愁
|
5月前
|
前端开发 JavaScript 开发工具
前端优化之路：git commit 校验拦截
前面在git分支规范那篇文章里，介绍了commit提交规范，但是想要做到高效落地执行，就需要做些别的功课。
一杯龙井解千愁
120 2
东方睿赢
|
6月前
|
前端开发 持续交付 开发工具
详细介绍Git的基本原理、在前端开发中的应用以及如何使用Git来优化团队协作
【6月更文挑战第14天】Git是前端开发中的必备工具，它通过分布式版本控制管理代码历史，支持分支、合并和冲突解决，促进团队协作。在前端开发中，Git用于代码追踪、版本控制、代码审查和持续集成部署，优化团队协作。制定分支策略、编写清晰提交信息、定期合并清理分支以及使用Git钩子和自动化工具能进一步提升效率。理解并善用Git，能有效提升前端项目的质量和开发效率。
东方睿赢
88 3
土木林森
|
7月前
|
前端开发 持续交付 开发工具
【专栏：工具与技巧篇】版本控制与Git在前端开发中的应用
【4月更文挑战第30天】Git是前端开发中的必备工具，它通过分布式版本控制管理代码历史，支持分支、合并、回滚等操作，促进团队协作和冲突解决。在前端项目中，Git用于代码追踪、代码审查、持续集成与部署，提升效率和质量。优化协作包括制定分支策略、编写清晰提交信息、定期合并清理分支及使用Git钩子和自动化工具。掌握Git能有效提升开发效率和代码质量。
土木林森
110 2

热门文章

最新文章

  • 1
    从0开始打造一款APP：前端+搭建本机服务，定制暖冬卫衣先到先得
  • 2
    WeaveFox：蚂蚁集团推出 AI 前端智能研发平台，能够根据设计图直接生成源代码，支持多种客户端和技术栈
  • 3
    前端页面加载性能指标之LCP
  • 4
    前端必须掌握的设计模式——单例模式
  • 5
    （前端3D模型开发）网页三维CAD中加载和保存STEP模型
  • 6
    探索无界：前端开发中的响应式设计深度实践与思考###
  • 7
    探索前端性能优化：关键策略与代码实例
  • 8
    前端自动化测试
  • 9
    探索无界：前端开发中的响应式设计哲学####
  • 10
    前端状态管理：Vuex 核心概念与实战
  • 1
    代码管理的艺术：你的团队是否还在为 Git 分支管理头疼？
    21
  • 2
    git rebase的使用
    46
  • 3
    工程化：Commitlint / 规范化Git提交消息格式
    96
  • 4
    git rebase的使用
    49
  • 5
    工程化：Commitlint / 规范化Git提交消息格式
    43
  • 6
    jenkins配置git
    38
  • 7
    【Git】Git 命令参考手册
    29
  • 8
    【Git】Git 完全指南：从入门到精通
    68
  • 9
    Git 快速入门：全面了解与安装步骤
    43
  • 10
    git 常用命令
    143

    • 相关课程

    更多
  • Git 基础入门到实战详解
  • 移动Web前端开发
  • Ajax 前端开发入门与实战
  • 零基础学前端HTML+CSS
  • 前端开发CSS基础
  • 前端开发框架Bootstrap使用教程

    • 相关电子书

    更多
  • Vue.js 在前端服务化上的探索与实践
  • 阿里文娱大前端技术实践
  • 前端代码是怎样智能生成的

    • 相关实验场景

    更多
  • 前端开发基础3：CSS3常见显示属性
  • 前端开发基础6：Node.js和LESS预编译工具
  • 前端开发基础2：VS Code和Edge的联动开发
  • 前端开发基础1：前端开发环境的安装和配置
  • 代码质量提升小妙招
  • 重温童年的“五子棋”，赢取专属阿里云Serverless证书
    • 下一篇
    DataWorks售前咨询