标签: git-merge

我刚做了一个

git merge --squash feature-branch

进入我的develop分店.

问题是上面的命令更新了头部而没有创建新的提交.我的目的是创建一个单一的提交申请到负责人develop.

简而言之,develop合并前后分支的日志完全相同.

有没有办法恢复develop到之前的状态git merge？

谢谢.

解

根据Dan D.的评论和下面接受的答案,我能够解决我的问题.如果你在同一条船上,请看下面我做了什么:

1 - 我跑了git reflog,它列出了我对我的develop分支所做的所有提交和检查.

2 - git reset HEAD@{1}我没有按照建议进行操作,而是在最后一次提交开发时找到了我希望保留的数字.就我而言HEAD@{188}.所以我打字了git reset HEAD@{188}.

3 - 我跑了一个git log,它有一个干净的日志,只显示我做错了合并之前的提交.

4 - 我跑完git add -A .了功能开发期间创建的所有新文件.

5 - 我跑了 git commit -m "install feature-x"

6 - 结果现在我有了develop正确文件的分支,并且日志是干净的 - 只显示了我在开发过程中所做的所有更改的一次提交feature-x.

我仍然需要找出为什么我的原件git merge --squash feature-branch …

我们正在为这个项目安装git,我正在和另一个同事一起玩.

我一直在解决一些精心设计的合并冲突,但我最终得到了一堆我不想要的额外文件.它们是.BACKUP .BASE,.LOCAL和.REMOTE文件.基于这些名称,它们似乎来自解决我的合并.我得到的一些确切的文件名是:

• index.shtml.BACKUP.16908.shtml
• index.shtml.BASE.16908.shtml
• index.shtml.LOCAL.16908.shtml
• index.shtml.REMOTE.16908.shtml
• 我还有另一组上面的文件,但以.21384结尾,假设从另一次合并尝试

是否可以不保存这些文件？你可以想象,现在有9个版本的index.shtml有点烦人.我正在使用git的内置合并工具tortoisemerge.

我通过运行git log遇到了类似的东西,它显然创建了一个"df"文件.只需将其包含在.gitignore文件中即可轻松处理.不过,我不想仅仅在整个项目中累积上面的文件.

我处于一种奇怪的情况:我已经将一个目录(本地存储库)从一个前开发人员复制到我的机器上.远程主机有几个提交不在他的本地存储库中.

如何将主服务器的本地副本与远程主服务器的最新更改合并？

我们的网站使用一堆带翻译的JSON文件进行本地化(每种语言一个文件).文件的内容如下所示:

{
    "Password": "Passwort",
    "Tables": "Tische"
}

许多团队成员同时编辑这些JSON文件,添加新短语和编辑现有短语,即使人们正在更改不同的行,我们也会遇到很多冲突.

有没有办法以这样的方式设置git,以帮助避免合并冲突？

PS 我发现这个脚本有助于本地合并:https://gist.github.com/jphaas/ad7823b3469aac112a52.但是,我对能够解决团队中每个人的问题的解决方案感兴趣(即使是通过GitHub的Web界面编辑JSON的人).

对我来说,典型的git工作流是克隆远程存储库并使用git pull来使其保持最新.我拉的时候不想要合并提交,所以我使用--ff-only选项.

我还为特色工作设立了本地分支机构.我想保留分支历史记录,所以当我将本地分支合并回我的本地克隆时,我使用--no-ff选项.

如何配置git默认使用这些选项？目前我的.gitconfig看起来像这样:

[merge]
  ff = false
[pull]
  ff = only

但是,git pull(实际上是git fetch和git merge)似乎正在拾取合并选项,因此创建了合并.

我们的团队工作如下:

• 我们只有一个master分支在我们的GitHub库,它不是稳定的-认为每天被推存在; 对于稳定版本,我们使用标签(用于开发,我们在GitHub上使用私人分支)
• 我们每3周发布一个新的次要版本,其中包含错误修正和新功能(比如1.2.4,1.2.5,1.2.6 ......)
• 我们还必须在有限的时间内(几个月)维护每个次要旧版本,所以当有人使用1.2.4而最新版本为1.2.7时,他们发现了一个错误,他们可以请求我们修复bug在他们使用的分支上.然后我们发布补丁版本 1.2.4A.
• 补丁非常特殊.对于次要版本,我们通常不会超过1-2个补丁.对于大多数版本,我们不做补丁.

问题是,同时修复master和旧分支上的bug的最佳策略是什么？

我可以想到两个主要策略:

1. 修复bug master,然后检查v1.2.4,然后挑选适当的提交(假设错误修复是一个始终保持的提交)并将结果提交标记为v1.2.4A.

2. 签出v1.2.4,修复错误并提交,将提交标记为v1.2.4A,并将其合并到master,执行合并.

我比较赞成的第一个版本(樱桃采摘),但我想听听对方的约利弊评论.

当然,当中间提交引入一些重大更改时可能会变得复杂,这些更改可能导致无法创建在1.2.4和master中都有效的提交(例如,当某些函数名称更改时)或更复杂的事情).但更常见的情况是修复程序可以毫无问题地移植.

从主人采摘樱桃的优点:

• 我认为樱桃采摘历史更"可食用".考虑一下:

  | <- bugfix done on master
  |
  |
  | <- v1.2.7
  ...
  |
  |
  |
  |
  |
  |
  |
  |
  |
  |  - <- v.1.2.4A (cherry-picked from master)
  | / 
  | <- v1.2.4
  

  Run Code Online (Sandbox Code Playgroud)

  对此:

  | <- bugfix merged to master
  |\ 
  | \
  | …

  Run Code Online (Sandbox Code Playgroud)

我想使用git rebase它来干净地合并主分支中的一个功能(在较少的提交中或至少在更改日志的顶部).请注意,我是唯一一个在存储库上工作的人.

在阅读了Git工作流程和rebase vs merge问题之后,我发现它git rebase会非常好,就像Micah一样,我想重新git push定义更改只是因为我正在从不同的地方工作(例如:我的笔记本,我的家,另一台PC. ..)

所以这里有两个解决方案(对于双向难看的合并):

1. 使用git push -f推送,然后拉动其他机器,但如何在其他机器上干净利落地获得最新版本？
2. 使用merge将主更改合并到功能分支,git push/pull,并且一旦成熟,就执行一个rebase(在一个或多个提交中干净利落)

(2)如下所示:

git co -b feature-a
... change files
git push origin feature-a
... moving to another PC
git pull origin feature-a
... change files
git merge master
... change files (not the "special rebase")
git rebase master
git co master
git merge feature-a
git branch -d feature-a
git push origin :feature-a

您认为哪种解决方案有效？到目前为止,我还没有尝试过其中任何一种(主要是因为害怕让我的日志变得更加混乱).

有没有办法在将master合并到分支时避免pom.xml中版本标记中的合并冲突.我有很多pom文件,80,并且它们都有相同的版本,与master中的版本不同.仅为版本标签执行80个pom文件的git mergetool是费力且耗时的.

谢谢,-Abidi

GitHub上有一个开源项目.它的原始仓库包含最新的主分支.现在有人(不是我)分配了这个仓库,从主分支创建了一个开发分支,并将东西添加到开发分支.我现在想要做的是将开发分支合并回主分支.不幸的是,分叉回购的主分支不是最新的.另请注意,我没有拥有两个相应的远程回购.

目前,我已将原始仓库和分叉仓库克隆到我的本地机器上git clone.如何将forked repo的开发分支合并到我本地计算机上的原始仓库的主分支中(即不在远程服务器上,这是不可能的)？

我正在将上游更改合并到我的项目中,最近有很多提交产生了很多合并冲突.尝试一次解决所有问题是没有意义的.

如何找出哪些提交会产生冲突？以下任何一种都是可以接受的:

• 一种让Git在发现冲突时立即停止合并的方法
• 一种让Git按时间顺序列出所有冲突提交的方法
• 还有其他让我按时间顺序一个接一个地解决冲突的事情,它不涉及一次合并一些提交,希望偶然发现冲突