当前位置：文江博客话题详情

使用 Git，我如何将工作副本中的一些更改提交到不同的分支？

发布于 2024-08-13 12:31:12 字数 197 浏览 10 评论 0原文

我在一个分支机构工作，得到的工作副本确实很不干净。在查看要提交的更改时，我希望将一些单线修复提交到 master 分支。

在这种情况下，使用 git stash 并没有真正的帮助，因为我的工作副本有很多其他更改，这些更改还不会与 master 合并。

有没有更有效的方法来解决这种情况？（例如进行提交，并移动它的父级？）

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

梦醒时光 2024-08-20 12:31:12

您可以使用 git add -i 使用交互模式。您可以在那里指定要提交的内容和要跳过的内容。

这样你就可以将你的 oneliners 作为单独的提交来提交。通过使用 gitcherry-pick您可以稍后将它们合并到您的 master 中。

回复收藏 0 原文

把梦留给海 2024-08-20 12:31:12

使用 git add -i 选择要提交到此分支的内容，然后更改为 master 并提交其余部分。

使用add -i，您可以选择要准备提交的文件的哪些部分，然后提交它们，同时将同一文件的其他部分保留在提交之外。

回复收藏 0 原文

单调的奢华 2024-08-20 12:31:12

git add -p 将使您直接进入补丁模式，以遵循 @arkaitz-jimenez 正确推荐的流程。

回复收藏 0 原文

与他有关 2024-08-20 12:31:12

我不知道这是否是您想要的，但我只会检查另一个分支（它不会丢失未提交的更改），然后有选择地签入您想要提交的更改。

回复收藏 0 原文

隐诗 2024-08-20 12:31:12

根据之前的建议，这是我提出的解决方案：

使用cherry-pick的解决方案1

只需在分支本身提交单个更改：

git add --patch <files>      # record every change to move to master
git commit

移至master，然后cherry-pick

git stash
git checkout master
git cherry-pick <commitid>

返回分支，它可以重新建立基础。

git checkout <branch>
git rebase master

对于每个重复提交，系统将提示您输入：

git rebase --skip

重复提交已从分支中的补丁集中过滤掉，并且历史记录是干净的。最终的 git merge 仍然可以快进。

解决方案2，无需先在分支中提交

首先提取所有内容移动到master：

git add --patch <files>      # record every change to move to master

然后切换到master进行提交：

git stash --keep-index       # clear the working copy only
git checkout master -m       # merge the index.
git commit

然后回到分支，可以直接rebase到master的提示：

git checkout <branchname>
git rebase master            # move to branch start to the tip of master.
git stash apply              # restore working copy, auto merges the changes

解决方案 3，克隆当前主分支

如果您不介意有多个工作副本（实际上我总是使用 SVN 这样做），还有第三种解决方案：

mkdir ../newrepos
cd ../newrepos
git init
git remote add origin /path/to/your/repository
git fetch master:remotes/origin/master  # fetch remote master to local remotes/origin/master
git checkout -t origin/master           # make new "master" branch, link to remote, checkout.

git commit
git push origin master                  # inject the change in the original repository.

克隆设置完成在这里手动操作，因为 git clone 总是克隆当前活动的分支。

对于更复杂的情况，总是有一个额外的安全防护 git diff > to-master.patch 和 git apply to-master.patch。这使您可以更自由地重置所有内容，并不断尝试，直到一切顺利为止。

在这种情况下，我们正在处理两个分支中都存在的文件中的单行修复。这不会产生任何合并冲突，并允许使用一些快捷方式，例如 checkout -m。

Based on the previous suggestions, this is the solution I've come up with:

Solution 1 with cherry-pick

Just commit the single change at the branch itself:

git add --patch <files>      # record every change to move to master
git commit

Move to master, and cherry-pick

git stash
git checkout master
git cherry-pick <commitid>

Back in the branch, it can be rebased.

git checkout <branch>
git rebase master

For every duplicate commit, you will be prompted to type:

git rebase --skip

The duplicate commits are filtered out of the patch-set in the branch, and the history is clean. The final git merge can still be fast-forward after-all.

Solution 2, without having to commit in the branch first

First extract everything to move to master:

git add --patch <files>      # record every change to move to master

Then switch to master to commit:

git stash --keep-index       # clear the working copy only
git checkout master -m       # merge the index.
git commit

And back in the branch, it can be directly rebased to the tip of master:

git checkout <branchname>
git rebase master            # move to branch start to the tip of master.
git stash apply              # restore working copy, auto merges the changes

Solution 3, make a clone of the current master branch

In case you don't mind having multiple working copies (I always did this with SVN actually), there is a third solution:

mkdir ../newrepos
cd ../newrepos
git init
git remote add origin /path/to/your/repository
git fetch master:remotes/origin/master  # fetch remote master to local remotes/origin/master
git checkout -t origin/master           # make new "master" branch, link to remote, checkout.

git commit
git push origin master                  # inject the change in the original repository.

The clone setup is done manually here because git clone always clones the currently active branch.

For more complex situations, there is always an extra safe guard with git diff > to-master.patch and git apply to-master.patch. This allows you more freedom to reset everything, and try over until you get things right.

In this situation, we're dealing with a one-line fix in a file which exists in both branches. This would not give any merge conflicts, and allows some shortcuts like checkout -m.

回复收藏 0 原文