Simple use of GIT_squash commits when merge request is accepted

目录

• 一、git 发布流程
• • 1.1 流程
  • 1.1 develop 分支打feature分支
  • 1.2 feature分支合并到develop分支
  • • 1.2.1 网页端合并
    • 1.2.2 命令端合并
  • 1.3 develop 分支打release分支
  • 1.4 release分支打tag
  • 1.5 回退(可选)
• 二 git 基础
• • 2.1 git status
  • 2.2 git branch -a
  • 2.3 git checkout
  • 2.4 git stash
  • 2.5 git merge
  • 2.6 squash
  • • 2.6.1 合并分支 squash
    • 2.6.2 用squash合并某个节点
• 三、首次提交 git 代码
• • 3.1 新建项目
  • 3.2 首次提交代码

一、git 发布流程

  为什么要把 feature 分支合并到 develop，然后打 release 分支发布给测试，而不是，直接发布 feature分支这么麻烦呢？
各有利弊吧

• 假如 feature 分支直接发布
    未来上生产肯定是要上 develop 分支的，那么上生产前，肯定是要把 feature 分支合并到 develop，但测试测的确实 feature 分支，保不齐这里会有什么差异，如果是发 release 分支给 测试，那么也就是改写小bug，再合回到 develop 分支，未来上生产的话，就大概率不会有啥问题，因为 release 和 develop 几乎是一样
    假如和小伙伴同时开发，你也不可能单独发 feature 分支，肯定是大家都开发完，合并到 develop 给测试测试，而且合并时的冲突也可以及时的处理掉

• 假如用 release 分支发布
    上面的问题就不会存在，当然可能导致 develop 分支的节点上有 bug，但这个相比于上个，是可以接受的，我感觉

1.1 流程

a、在 develop上打feature分支，feature分支命名：
feature-具体功能或者需求
b、开发完毕，将 feature-具体功能或者需求合并到develop分支
c、在develop分支上打release分支，release分支命名：
release-具体功能或者需求
d、在release-具体功能或者需求 分支上打tag，tag命名：
tag-具体功能或者需求-rc01

1.1 develop 分支打feature分支

git checkout -b feature-IM-channel #切换到 feature-IM-channel 分支
git push --set-upstream origin feature-IM-channel  #将 feature-IM-channel 分支 推送到远端
1
2

1.2 feature分支合并到develop分支

1.2.1 网页端合并

1、Merge Requests

2、New merge request

3、选择好，从哪个分支合并到哪个分支

4、Compare branches and continue

5、填写 Description

6、是否勾选 Squash commits when merge request is accepted ，如果勾选的话，相关的节点不会出现在合并的分支上

1.2.2 命令端合并

将分支 feature-support-redis-encryption 合并到 develop

git checkout develop
git merge feature-support-redis-encryption
git push  
1
2
3

1.3 develop 分支打release分支

git branch release-IM-channel  #本地建立 release-IM-channel 分支
git checkout release-IM-channel #切换到 release-IM-channel 分支
git push --set-upstream origin release-IM-channel #将 release-IM-channel 分支 推送到远端  
1
2
3

1.4 release分支打tag

git tag tag-IM-channel-rc02          #本地打tag
git push origin tag-IM-channel-rc01  #把 tag-IM-channel-rc01 推送tag到远端  

1
2
3

1.5 回退(可选)

为什么要回退呢？
  在将feature分支合并到develop 分支时，使用了squash 操作，它会让feature分支上的节点，不在develop分支上显示，当然这也是，我们使用 squash的原因，因为我们在自己分支上的修改，有些是错误的，并不想让它显示在develop分支上，问题就在于，我当时开发新功能，并不是在develop的基础上打的分支，而是在另外一个分支，比如feature1上打的分支，这就导致feature1上的节点在develop上也不显示了，而feature1分支时稳定的，所以我就想让develop分支回退到我合并前的那个版本，然后，我先将 feature1分支以非squash的方式合并到develop，这样，feature1上的节点在develop上就会显示了，然后我再将我自己的分支以squash的方式合并到 develop分支上，这样就解决问题了
a、回退

git reset --hard HEAD^ 强制回退到上一个版本
git push -f 强推到远端

b、删除本地 release-IM-channel 分支

git branch -d release-IM-channel

c、删除远端 release-IM-channel 分支

git push origin --delete release-IM-channel

d、删除本地 tag

git tag -d tag-IM-channel-rc01

e、删除远端 tag (可能删不掉)

git push origin :refs/tags/tag-IM-channel-rc01

二 git 基础

2.1 git status

2.2 git branch -a

例子

[songbw@hadoop monitorproxy]$ git branch -a
*develop
feature
feature-IM-channel
master
release
remotes/origin/HEAD -> origin/master
remotes/origin/develop
remotes/origin/feature-IM-channel
remotes/origin/feature-support-unified-domain
remotes/origin/fix-add-auth-for-redis
remotes/origin/master
remotes/origin/release
remotes/origin/release-sz-unicom

解释：
  git brach -a 的作用是显示本地和远端的所有分支，带 origin 的表示远端的分支，其它就是本地的分支，带*表示，本地当前所处的分支

2.3 git checkout

我自己的理解：
  git checkout 是用来切换分支的，当你把远端的项目往本地完全克隆一份之后，那么，你的本地就拥有了远端master分支，当用命令 git branch -a，会显示远端的所有分支和本地的 master分支，当你在本地每 git checkout 一个与远端同名的分支，就会把远端对应的分支拉取到本地，此时，git checkout的HEAD指针是指向当前分支的最后一个节点的，也即最新的修改，假如你想切换到某个特定版本的代码，你可以用 git checkout commitID号,但是要注意，commitID对应的节点毕竟是某个分支的中间的某个节点，而我们的分支只能指向尾节点，也即最新修改，所以，git 会提示你，当前的代码处于 ‘detached HEAD’ state，如下：

[songbw@hadoop monitorproxy]$ git status
HEAD detached at 8abf8ce

这就表示当前是在commitID是8abf8ce的代码上 ，因为它并不处于任何一个分支上，所以是一种分离状态，可以通过新建一个分支，让这个版本的代码落在这个分支上，解决问题，具体操作如下：

[songbw@hadoop monitorproxy]$ git checkout -b try-release-sz-unicom

此命令的作用是，新建 try-release-sz-unicom 分支，并切换到此分支，我们知道，git checkout是切换分支，而-b参数表示 git branch 是新建分支，再用 git status 如下：

[songbw@hadoop monitorproxy]$ git status
On branch try-release-sz-unicom

这就表示 commitID 是 8abf8ce 的代码已经落在了 try-release-sz-unicom 分支上面

2.4 git stash

使用场景：
  开发新功能，我需要新建一个分支，在分支上开发，但是忘记了，直接在 devlop 上开发了，这时候，开发完又不能提交，这时可以使用 git stash 命令，把新修改的暂存起来，这时 develop 就回到了最原始的节点，这时，我再重新建立一个分支，用命令 git stash pop 就会把新的修改覆盖到新的分支上面，很完美吧

#暂存
git stash   
#使用上一次暂存，并将这个暂存删除，使用该命令后，如果有冲突，终端会显示，如果有冲突需要先解决冲突（这就避免了冲突提交服务器，将冲突留在本地，然后解决）
git stash pop
1
2
3
4

2.5 git merge

  如果在合并时，没有遇到冲突，那正常提交代码就可以，当同一个文件，两个分支都有修改到时，merge 的时候就会出现问题，会报错，自动 merge 遇到冲突，此时 git status 如下

both modified:   main.py
1

然后打开 main.py 会出现如下字样

<<<<<<< HEAD
187                                                                     "intention_id": "",
188                                                                     "intention_name": "",
189                                                                     "slot": {},
190                                                                     "state": {"state_id": ""},
191                                                                     "is_end": 1,
192                                                                     "action_id": "",
193                                                                     "output": ""}))
194 =======
195                                                                        "intention_id": "",
196                                                                        "intention_name":"",
197                                                                        "label_info": "",
198                                                                        "slot": {},
199                                                                        "state": {"state_id": ""},
200                                                                        "is_end": 1,
201                                                                        "action_id": "",
202                                                                        "output": ""}))
203 >>>>>>> feature-answer-support-user-label
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

  这种情况的出现在于，两个人同时在 develop 分支上打了分支进行开发，同时都修改到了 main.py 文件，那么在最终合并时，就会遇到这样的冲突，因为git 不知道怎么处理main.py 文件，需要开发人员看一下，修改的部分应该怎么处理，要放在哪个位置，该不该放，等等
  解决办法就是自己手动修改 main.py 文件，把 “<<<<<<< HEAD” 、 “=======”、“>>>>>>> feature-answer-support-user-label” 这些字样都去掉，然后再 git add、git commit、git push 就 ok 了

那么，这些字样都是什么含义呢？

<<<<<<< HEAD 到  ======= 是当前节点的内容 

======= 到 >>>>>>> feature-answer-support-user-label 是 需要合并的分支的代码 
1
2
3

如上面例子，两个分支在这两部分的代码不一样，feature-answer-support-user-label 分支多了 label_info 字段，那么你就要去选择用哪部分的代码，然后把那些标志都删掉就 ok

2.6 squash

2.6.1 合并分支 squash

git checkout master
git merge --squash feature-answer-support-transfer-manual
git commit -m "Squash submission of of transfer to manual feature"
git push 
1
2
3
4

将分支 feature-answer-support-transfer-manual 以squash 的方式合并到 master，这种方式不会自动 commit，它会把所有的修改都提交到 master 上，你还可以检查下，如果 没问题的话，自己 commit 一下就可以了

2.6.2 用squash合并某个节点

git checkout master
git merge --squash 8cf8eeb445d86459048ba341c4b14f03eb2fc52e
git commit -m "Squash submission of of 8cf8eeb node"
git push
1
2
3
4

区别就是这个是按节点来的，上面的是按照分支来的，你可以直接用 commit id，因为实际操作中可能会有这样的需求，就是后面的修改，你目前还不需要合并过去，那么就可以只合并某个节点

三、首次提交 git 代码

3.1 新建项目

  如果想在指定的组下面新建项目，也就是点击 git 右上角的 “New project”，是需要权限的，得是 owner 或者 master 角色才行，Developer 是不行的，如下，我的角色是 Developer，我就不能在指定的组下面建项目，这时只能找你的上级了
  如果我新建，新建那里就是写死的，如下：

如果有权限，应该如下显示，是可以选择在哪个组下面建项目的

  建完项目就会有git 地址，也会有首次如何提交代码的提示了

3.2 首次提交代码

  整体上有两种方式

• 一种是，拿到 git 地址，先 git clone 然后，在里面写自己项目，方式如下

Create a new repository
git clone http://xxxxxxx.git
cd xxxx
touch README.md
git add README.md
git commit -m "add README"
git push -u origin master
1
2
3
4
5
6
7

• 另一种是，自己的项目已经写好了，就放在本地，那需要先 git init 一下，具体如下

Existing folder
cd existing_folder
git init
git remote add origin http://xxxxxxx.git
git add .
git commit -m "Initial commit"
git push -u origin master
1
2
3
4
5
6
7

这些代码没有也没关系，在你新建一个项目的时候，就会有提示你怎么做的，还有，在做如上操作的时候，可能需要设置自己的用户名和邮箱，这些都会有提示如何操作的，如下：

git config --global user.name "xxx"
git config --global user.email "xxxx@credithc.com"
1
2

参考文章：
[1] git stash
[2] gitlab 创建分组与项目
[3] gitlab 创建分组与项目2