git 问题咨询

[JadePenG]

git 用的比较少, 所以来询问一下大佬们,我遇到如下场景有什么方式可以处理。 目前项目只有一个分支，master 分支。 假如我目前在开发当前项目的 V1.2 版本，但是 V1.1 版本有 BUG 时，我需要修改对应的代码。 但是 V1.2 版本的新功能不可能在一次 BUG 修复中就发布出来。那么此时我应该怎么处理 V1.2 版本新功能的代码呢？

可以不通过新建一次分支的情况下处理嘛。 [这是重点哦]

[fiypig]

同问

[dvsilch]

在本地新建一个分支推到 master 都不行吗？

[gengchun]

用分支

https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell


Because a branch in Git is actually a simple file that contains the 40 character SHA-1 checksum of the commit it points to, branches are cheap to create and destroy. Creating a new branch is as quick and simple as writing 41 bytes to a file (40 characters and a newline).

[pagxir]

这个跟 git 没关系吧，这个是分支管理的问题，即使你换成 SVN 也一样需要考虑怎么去管理分支，什么时候合并分支

[marat1ren]

假设 v1.2 还是在你的本地 master ，那么你可以先把 v1.1 的修复 push 到 master 上去。然后 rebase 有修复的 master 。第二种情况，如果 master 上已经是 v1.2 了，那只能建议新建一个基于 v1.1 的 branch ，把修复 push 到这个新 branch 上。

[CEBBCAT]

你要是实在想问，那么 stash 可以解决你的问题，rebase+checkout 也许也可以

但是你这么做，用的还是 git 吗？以上操作有较高的丢失代码的风险。你未来开发到 2.0 的时候，又该要怎么修复 1.1 的 bug 呢？

[nightwitch]

先从你当前远程的那个 commit id 分叉一个分支 v1.1 ，然后修复 bug ，push 到远端。
本地的 master 有一堆 v1.2 的代码还没实现完，rebase 到修复完 bug 的分支上。

[christin]

只有一个分支万一出问题怎么办 建议多开几条分之，又不要钱

[msg7086]

不新建分支还用什么 git 。你就算是新建文件夹（ 1 ）那也是分支啊。

[zkd8907]

在一些管理的方式下 v1.1 应该是一个 tag ，它会指向到 master 上的一个 commit 。如果 v1.2 在 master 上开发并且又要修改 v1.1 的 bug ，可以直接从 v1.1 的 tag 拉一个新的 hotfix 分支进行开发修复，修复后通过打 v1.1.1 tag 进行发布，同时将 master 也 rebase 到 v1.1.1 上，这样 master 也会包含这个改动。

[FieldFarmer]

另开一个目录重拉远程 v1.1 版本的项目代码，修复后推到远程。
v1.2 commit 后，git pull ，有冲突解决冲突，没冲突继续开发

[AItsuki]

异想天开，我想不出能比新建一个 bugfix 分支更简单的方式。

[duke807]

op 最大的問題其實是 git 用的不熟，我的觀念一直是：git 必須要非常熟悉，才能提高工作效率，否則反而會降低工作效率，搞不好還會把自己坑死

[dangyuluo]

@zkd8907 正常情况下应该有一个 release-v1 的分支，然后 v1.1 这个 tag 应该指向 release-v1 上的一个 commit 。这时把修复 push 到 release-v1 上，再创建一个 v1.1.1tag 就可以了。定期的，相关 fix 应该被 cherry-pick 到 maste 上

[caeger]

git 创建新分支要开始收费了？

[SenLief]

git 的分支开销非常的小啊，随意开新分支就好了。

[caixiangyu17]

Trunk Based development + feature toggle flag
我们就是只有一个分支，所有人直接 push master ，直接 CI/CD 上生产环境，所以这里对 CI/CD 的各种测试要求很高。
如果不想这么麻烦，可以 CI/CD 直接发布到 test 服务器上，先测，然后手动部署到 prod 上

[tedzhou1221]

不新建分支，你可以把修复好的代码 cherry-pick 到 v1.2 分支上。

我们还有同事试过，在 v1.1 上修复代码并提交后，再把 v1.1 合并到 v1.2

[chengyiqun]

不用分支还不如不用 git 。git 最大的优点就是分支建立代价很小。

[raykle]

不新建分支你用什么 git

[SmiteChow]

在服务器上复制一份代码现改，然后可以生成 patch 文件，最后手动把所有服务器上打 patch 补丁。

[Jwyt]

学一下 git 吧，真不难

[lizuoqiang]

都用 git 了，还是看看 git 工作流吧

[daimubai]

stash 可以解决，把 v1.2 的先暂存

[james2013]

不新建分支是处理不了的,难道要把 1.2 版本的所有提交记录还原么?
这种情况,在 1.1 版本最后 1 次 commit 打个 tag,用新分支修改 bug 后,再把这个修复版本打 tag

[ganbuliao]

git flow 看一下吧

[superfatboy]

git flow xiao 一下吧

[konakona]

你们是一个分支打了 2 个 tag 来进行版本管理？
那你先基于 v1.1 的标签创建分支，然后在这个分支上创建一个新的 bugfix or hotfix 分支（这样可以独立 commit id 和文件树），修复完后文件数量应该不多就几个吧？

```
git checkout v1.1
...此时修改文件 A 、B 、C
git add A B C
git commit -m '修复了 xxx 问题'
git status #可以看到只有 3 个文件变动
git -a v1.1.1 -m '修复了 xxx 问题' # 打一个新的 tag

# 接下来要将修改的这 3 个文件的改动合并到 master 分支
git checkout master
git merge v1.1.1
```

[konakona]

上面补充下，我提议的跟我打的命令是 2 个做法。
提议的是用一些 git flow （ flow 是一个统称，代表流程，比如有 git-flow gitlab-flow GitHub-flow 等等）的方式管理版本。

如果不用 flow ，就是直接代码片段里那样也可以的。

[why1001]

不创建分支就是 v1.2 先扔到暂存，改完 bug ，再恢复

[leafre]

stash 能解决，但是分支用起来啊

[tuutoo]

看一下 git 工作流 如何管理和使用分支。基本上不会在 master 上直接开发的。至少会新建 dev, feature, hotfix 或者 bugfix 这种分支。一言两语说不清。 master 永远对应生产库的最新版，其他的都 checkout 分支出来开发新功能或者 bugfix 。完了再合并回分支。。。
bugfix 或者新功能上线后，其他正在开发的分支再从 master 合并(merge)或者变基(rebase)，这个 rebase 也不能乱用(特别是多人开发同一分支的时候)。用之前先好好看一下。。。

[findex]

rebase 即可