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

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

用分支

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).

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

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

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

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

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

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

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

在一些管理的方式下 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 也会包含这个改动。

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

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

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

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

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

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

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

不新建分支，你可以把修复好的代码 cherry-pick 到 v1.2 分支上。
我们还有同事试过，在 v1.1 上修复代码并提交后，再把 v1.1 合并到 v1.2

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

不新建分支你用什么 git

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

学一下 git 吧，真不难

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

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

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

git flow 看一下吧

git flow xiao 一下吧

你们是一个分支打了 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

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

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

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

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

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

rebase 即可