标签：处理 title script asc 绕过 dig rip 问题 模拟
让我们来看一个简单的分支新建与分支合并的例子，实际工作中你可能会用到类似的工作流。 你将经历如下步骤：
开发某个网站。
为实现某个新的需求、问题（#53问题），创建一个分支（名为：iss53）。
在这个分支上开展工作。
正在此时，你突然接到一个电话说有个很严重的问题需要紧急修补。 你将按照如下方式来处理：
切换到你的线上分支（production branch）。
为这个紧急任务新建一个分支（名为：hotfix），并在其中修复它。
在测试通过之后，切换回线上分支(名为：master)，然后合并这个修补分支，最后将改动推送到线上分支，并删除hotfix分支。
切换回你最初工作的分支（iss53）上，继续工作。
首先，我们假设你正在你的项目上工作，并且已经有一些提交。
现在，你已经决定要解决你的公司使用的问题追踪系统中的 #53 问题。 想要新建一个分支并同时切换到那个分支上，idea上操作如下：
填写分支名称
在iss53分支上开发，如下
将分支推送到远程仓库
点击push推送到远程仓库
在远程仓库查看是否有iss53分支
分支的创建与提交完成！
现在你接到那个电话，有个紧急问题等待你来解决。 有了 Git 的帮助，你不必把这个紧急问题和 iss53 的修改混在一起，
你也不需要花大力气来还原关于 53# 问题的修改，然后再添加关于这个紧急问题的修改，最后将这个修改提交到线上分支。 你所要做的仅仅是切换回 master 分支。
idea上操作如下：
特别注意：在你这么做之前，要留意你的工作目录和暂存区里那些还没有被提交的修改，它可能会和你即将检出的分支产生冲突从而阻止 Git 切换到该分支。 最好的方法是，在你切换分支之前，保持好一个干 净的状态。 有一些方法可以绕过这个问题（即，保存进度（stashing） 和 修补提交（commit amending）），我们会在 储藏与清理 中看到关于这两个命令的介绍。
这个时候，你的工作目录和你在开始 #53 问题之前一模一样，现在你可以专心修复紧急问题了。
请牢记：当你切换分支的时候，Git 会重置你的工作目录，使其看起来像回到了你在那个分支上最后一次提交的样子。
Git 会自动添加、删除、修改文件以确保此时你的工作目录和这个分支最后一次提交时的样子一模一样。
接下来，你要修复这个紧急问题。 让我们建立一个针对该紧急问题的分支（hotfix branch），在该分支上工作直到问题解决：
这个时候，git的分支结构图如下：
master 分支的紧急问题分支 hotfix上进行代码开发，模拟如下：
你可以运行你的测试，确保你的修改是正确的，然后提交代码到远程仓库，提交到远程仓库的操作与刚才提交iss53操作一样。
当hotfix这个紧急问题的分支开发完成后，将其合并回你的 master 分支来部署到线上。 你可以使用idea的 git merge来达到上述目的：
首先切换到master
然后，以master为主线合并hotfix,这个很重要，因为是以master为主，将hotfix的的代码合并到master上，不要把顺序弄返
现在，最新的修改已经在 master 分支所指向的提交快照中，这是你只需要提交master到远程仓库（非常重要，千万别忘记），你可以着手发布该修复了。
此时，git的分支结构图如下：
搞定，这时候紧急问题已解决，并且顺利的合并到了master主线上，接下来我们就应该删除分支hotfix
删除本地仓库分支hotfix
删除远程仓库分支hotfix
回到iss53分支上
当前git分支结构如下图：
继续在分支iss53上写代码
iss53开发完成，提交到远程分支（同之前操作一样，图略）；
切换到master分支（同之前操作一样，图略）；
将iss53分支合并到master分支上（同之前操作一样，图略），此时的分支结构图如下：
删除本地iss53分支（同之前操作一样，图略）；
删除远程iss53分支（同之前操作一样，图略）；
完美！
标签：处理 title script asc 绕过 dig rip 问题 模拟
原文地址：https://www.cnblogs.com/wfd360/p/10891314.html
