从svn的背景来看:我很少分支,因为切换速度缓慢,将分支合并回主干需要一个小时以上。有时,如果我需要在网站上热修复问题,我会在主干中进行更改(与之前的更改或新功能一起),然后转到该文件并只运行“svn up path/to/filename”,它将仅更新该文件,修复问题但节省其他文件。
从概念上讲,在git中似乎不可能(也不必要)这样做;是结构化的暂存和分组提交允许挑选吗?因此,我可能会更改站点的特定区域,并将其作为一组提交,而不是像svn那样工作,一天内触摸整个批次并立即提交整个批次?
从svn的背景来看:我很少分支,因为切换速度缓慢,将分支合并回主干需要一个小时以上。有时,如果我需要在网站上热修复问题,我会在主干中进行更改(与之前的更改或新功能一起),然后转到该文件并只运行“svn up path/to/filename”,它将仅更新该文件,修复问题但节省其他文件。
从概念上讲,在git中似乎不可能(也不必要)这样做;是结构化的暂存和分组提交允许挑选吗?因此,我可能会更改站点的特定区域,并将其作为一组提交,而不是像svn那样工作,一天内触摸整个批次并立即提交整个批次?
在这种情况下,您可能想要做的是为您的热修复创建一个新分支,该分支从将需要修复的所有分支的共同祖先分支中分支出来。例如,假设您有几个维护的版本与您当前的开发:
- X - o - o - o - o - o - o - o - o - o (master)
\ \
o - o - o (release A) o - o (release B)
如果你需要制作一个既适用于主分支又适用于两个发行版的热修复,那么请从标有X的提交开始创建一个分支。提交你的修复,然后将该分支合并到所有三个分支中。