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

简介: 对象是真的,连夜码字是真的,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 keyTtile任意填写(建议不要瞎写,最好有记忆特征),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使用

未完待续,抽时间再写了

目录
相关文章
|
6月前
|
存储 前端开发 开发工具
前端开发中的Git版本控制:构建可靠的协作和代码管理
前端开发中的Git版本控制:构建可靠的协作和代码管理
84 0
|
19天前
|
监控 前端开发 JavaScript
前端开发的终极奥义:如何让你的代码既快又美,还不易出错?
【10月更文挑战第31天】前端开发是一个充满挑战与机遇的领域,本文从性能优化、代码美化和错误处理三个方面,探讨了如何提升代码的效率、可读性和健壮性。通过减少DOM操作、懒加载、使用Web Workers等方法提升性能;遵循命名规范、保持一致的缩进与空行、添加注释与文档,让代码更易读;通过输入验证、try-catch捕获异常、日志与监控,增强代码的健壮性。追求代码的“快、美、稳”,是每个前端开发者的目标。
31 3
|
1月前
|
前端开发 开发工具 git
如何清理 docker 磁盘空间+修改 Gitea 服务器的 Webhook 设置+前端一些好学好用的代码规范-git hook+husky + commitlint
如何清理 docker 磁盘空间+修改 Gitea 服务器的 Webhook 设置+前端一些好学好用的代码规范-git hook+husky + commitlint
35 5
|
1月前
|
前端开发 开发工具 git
搭建Registry&Harbor私有仓库、Dockerfile(八)+前端一些好学好用的代码规范-git hook+husky + commitlint
搭建Registry&Harbor私有仓库、Dockerfile(八)+前端一些好学好用的代码规范-git hook+husky + commitlint
20 0
|
3月前
|
存储 前端开发 开发工具
前端常用的git操作
【8月更文挑战第24天】前端常用的git操作
25 1
|
3月前
|
JavaScript IDE 前端开发
前端开发工具配置 nodejs & git & IDE
前端开发工具配置 nodejs & git & IDE
|
4月前
|
前端开发 JavaScript 开发工具
前端优化之路:git commit 校验拦截
前面在git分支规范那篇文章里,介绍了commit提交规范,但是想要做到高效落地执行,就需要做些别的功课。
|
5月前
|
前端开发 持续交付 开发工具
详细介绍Git的基本原理、在前端开发中的应用以及如何使用Git来优化团队协作
【6月更文挑战第14天】Git是前端开发中的必备工具,它通过分布式版本控制管理代码历史,支持分支、合并和冲突解决,促进团队协作。在前端开发中,Git用于代码追踪、版本控制、代码审查和持续集成部署,优化团队协作。制定分支策略、编写清晰提交信息、定期合并清理分支以及使用Git钩子和自动化工具能进一步提升效率。理解并善用Git,能有效提升前端项目的质量和开发效率。
83 3
|
6月前
|
前端开发 持续交付 开发工具
【专栏:工具与技巧篇】版本控制与Git在前端开发中的应用
【4月更文挑战第30天】Git是前端开发中的必备工具,它通过分布式版本控制管理代码历史,支持分支、合并、回滚等操作,促进团队协作和冲突解决。在前端项目中,Git用于代码追踪、代码审查、持续集成与部署,提升效率和质量。优化协作包括制定分支策略、编写清晰提交信息、定期合并清理分支及使用Git钩子和自动化工具。掌握Git能有效提升开发效率和代码质量。
100 2
|
6月前
|
存储 缓存 前端开发
超越极限,前端性能优化的终极奥义
在当今互联网时代,前端性能优化成为了每个开发者必须面对的挑战。本文将介绍一些独特的、能够极大提升前端性能的技巧和策略。通过深入探索代码压缩、资源加载、渲染优化和缓存策略等方面,我们将揭示出前端性能优化的终极奥义。
下一篇
无影云桌面