标签: git-merge

我需要撤消在 GitHub for Windows 中启动的合并。

它已同步到单个存储库，我尝试同步它，但收到冲突错误消息，因此我犯了“将远程跟踪分支“origin/pp-chart”合并到“pp-chart”中的错误。

我想撤销我所做的一切，我该怎么办？

好的，这是我的场景：

第 1 步 - 在 Git master 上，状态是最新的

第 2 步 - 处理项目并需要添加功能

第 3 步 - 创建分支，在新分支上构建功能

第 4 步 - 切换回 master，新功能中的文件/文件夹仍然存在。有没有搞错？

所以我的问题是，我没有将分支合并到 master 中，但分支文件/文件夹出现在 master 中。这是正常的吗？

我期望的行为是未合并的文件保留在各自的分支中，并且在合并之前不显示。我将对此进行更多实验。也许我在想更多的 GitHub 并且需要考虑更多的 Git。也许我需要阅读更多关于分支和合并的内容。显然还在那里学习 Git。

我知道Team Foundation版本控制中的无基础合并是危险的.我想知道Git是否也有危险.

如果你不熟悉baseless merge,这是一个例子.红色虚线是一个毫无根据的rebase/merge.

用Git做这个是安全的吗？

输入'git commit -m（然后一条消息就可以），我的问题是一旦我提交或合并，git就会拉出一个屏幕...... 现在，一旦我输入了一条消息（黄色），我就无法执行任何操作……我按了 Enter，我已经查阅了菜单，我已经阅读了 GitBook，但我无法通过这个屏幕……可以请告诉我如何实际提交此屏幕。如何输入这些数据，或者接受它或者任何 git 需要做的来输入这些数据。一旦我输入了我的消息（黄色），按 Enter 键什么也不做...请帮助...

我在 git repo 中有一个分支（例如 Feature-X）。

我所做的是以下

git checkout master
git merge Feature-X

我解决了很多冲突。我还没有提交更改。

但是，事实证明我想要的是进行反向合并（即合并 master 到 Feature-x），因为分支可能仍然不稳定。

是否有任何命令可以挽救我在解决冲突时所做的工作，或者我是否需要再次进行解决，这次是在分支 Feature-X 中？

我在想是否有办法获取当前补丁，但以“相反”的顺序将其应用到分支 Feature-X 中。例如，当补丁说行 X 更改为 Y 时，这与 Feature-X 将要掌握有关。如果我想做相反的事情，补丁应该说行 Y 更改为 X，对吗？这只是我的想法。任何解决方案都可以。

我有该文件的三个版本：

version 1       common ancestor      version  2
-------------   ---------------      ------------- 
before          original line        original line
original line                        after

比较这些版本以生成最终合并版本时会发生什么？

我已经阅读了一些关于这个主题的信息，但我仍然很困惑它到底是如何工作的。

至于后一个例子：

比较版本之间的单行是否为线性？如果是这样，则最终合并应如下所示：

1 line: before
2 line: conflict (both left and right contributors are changed compared to ancestor) 

这是正确的理解还是工作方式不同？

我有一个开发分支，在它准备好之前我不小心将其合并到了 Master 分支中。

由于我错误地执行了此操作，因此我决定恢复 Master 中的更改，以便我的任何更改都不会发生在那里。此过程创建了一个恢复提交，从主服务器中删除了我的更改。

一切都很好我以为...

一周过去了，我几乎准备好将我的分支合并回 Master 中。由于还有其他开发人员在其他分支上工作，我决定通过将 Master 中的任何新更改合并回我的分支来更新我的开发分支。

这个过程似乎删除了我所有的工作。

回顾一下Master刚刚传来的历史，它包含了意外提交和恢复提交。这意味着每当我从 Master 更新我的分支时，恢复提交都会删除我的大部分工作。

如何将 master 中的更改合并回我的分支，但不包括恢复提交？

我能想到的唯一的两种可能性是：

• 仔细检查合并中的每个项目，并尝试手动删除恢复项目（我认为这是不可能正确完成的，而且完全是一场噩梦）。
• 复制我在本地进行更改的所有文件，从 Master 合并，然后尝试将所有更改复制/粘贴回我的分支（这可能也是一场噩梦）。

我希望有一种更好的自动化方法来做到这一点（我希望进行某种合并但忽略某些提交过程）。

我有两个分支A和B，我想将B合并到A。但是，我不希望从B进行任何更改以转移到A。除了合并后进行的手动更改外，A应该保持不变。我知道，从技术上讲，这与整个合并的想法背道而驰，但这是关于记录这些分支之间的关系。我想要的是，存储库的图形在相应的提交处合并了这两个图形之间的合并，即，我希望git“思考”实际合并。

一种可能的方法是reset在合并后执行。但是，这不在如上所述的图中。分支之间没有实际链接。

我的 Git 存储库如下所示：

我创建了 2 个分支 - Branch_1 和 Branch_2。现在我终于准备好将此 Branch_2 合并到 Master 分支中。但是当我合并时，它显示了 Branch_1 和 Branch_2 的所有提交，因为中间有多个合并。任何人都可以建议如何在这种情况下继续进行一次提交，然后将我的代码合并到主分支吗？

git log --oneline --graph --color --all --decorate

* 36dbb26 (origin/Branch_2) changed abc
* 1a7bf25 changed T
* 110095a changed Z
*   1087d5d Merge remote-tracking branch 'origin/Branch_1' into Branch_2
|\
| * 8c9d02a (origin/Branch_1) sleep added between each processing to discover partitions
| * ca401cb changed S
| * 20a4edd changed R
* 3f472ef install package
*   1087d5d Merge remote-tracking branch 'origin/Branch_1' into …

常见的情况是合并一个分支直到它的最后一次提交：

      A---B---C topic
     /         \
D---E---F---G---H master

但我想排除最后一次提交，如下所示：

        A---B---C topic
       /     \
  D---E---F---G  master

是否可以将topic分支合并到 master 而不包含topic's last commit？

使用GIT似乎就像在玩一种新的国际象棋，没人真正知道规则。这是我所做的，请让我知道为什么这么快就出错了。

我有一个主叉子/仓库和我的个人叉子。

git clone https://github.com/myfork/project.git
cd project
git submodule update
git checkout -b newbranch
git remote add upstream https://github.com/CompanyX/project.git
git fetch upstream  # <- hoping to update my fork
git pull upstream mainbranch # want the latest stuff from upstream
# Result: 100's of modified files, deleted files, and even merge conflicts... unrecoverable.

我已经看过几次了。如果在从主叉子更新叉子之前在叉子中创建分支，则叉子和主叉子之间的差异将导致合并冲突，最终无法解决。

我是在做错事还是在冒危险？

如果不是某些东西的副本，那么叉子到底是什么？是叉 但在git的另一种名不副实的任期？

共有三个分支：dev、master、release。
流程是从 dev 合并到 master，从 master 合并到release。
发布分支在生产中被引用。
（基本上，来源反映在 git pull 的生产中。）

我使用的是 Gitea，它与 Github 类似。
基本上，我通过拉取请求合并到每个分支。

有一天，我被要求仅反映发布分支上的特定提交。
当时，我使用cherry-pick将特定提交从master分支合并到release分支。
这时我从命令行手动合并...

并释放。

然后，几天后，我将 master 分支合并到release分支中以发布所有提交。
这时我从命令行手动合并...

当前的问题是如果拉取请求没有通过该怎么办。
我可以通过拉取请求从开发合并到主控。
但是通过pull request从master合并到release会存在一些冲突。

上次我手动解决并合并了release分支的冲突，所以dev、master、release分支的内容是一样的。
之后，开发工作就交给了dev。
之后，我能够从开发者的拉取请求合并到主控者。（无冲突）
并且从 master 的拉取请求合并到发布将导致冲突。

我认为原因是之前发布分支中手动合并的影响。
手动合并后如何规范拉取请求的合并？

当我尝试将分支合并到 master 时，我预计会发生合并冲突。这两个分支都有一个文本文件，其中包含不同的文本。

# make project directory
mkdir projA
cd projA

# initialize git repo
git init

# make commit in master branch
echo "text 1" > fileA.txt
git add .
git commit -m "commit A"

# make commit in a new branch
git checkout -b branch1
echo "text 2" > fileA.txt
git add .
git commit -m "commit B"

# merge branch into master
git checkout master
git merge branch1

但合并命令只是进行快进合并，并保留 brach1 的 txt 文件中存在的文本，而不是 master 分支中的文本。

有人可以向我解释一下为什么 git …