从分支中提取所有提交，将指定的提交推送到另一个提交 [英] Pull all commits from a branch, push specified commits to another

问题描述

我有以下分行：

• master


• 生产

以及以下远程分支：

• origin / master


• origin / production

我有一个脚本取得 origin / master 分支，并获取从我上一次获取（ log -p master.origin / master ）更改的内容。然后我合并 origin / master 。

发现的提交被推送到代码审查工具。

我想将成功的提交（仅限他们）推送到生产分支，然后推送到 origin / production 。

我该怎么做？

另外，我有两个脚本运行：从 origin / master ，push将细节提交到一个数据库，然后合并，另一个我正在编写的代码将必须推送成功的提交。

我想让这两个脚本在避免竞争条件/合并冲突的同时运行。因为我只想使用指定的提交，也许有办法摆脱我不想要的提交？

p>我认为你正在寻找的术语是樱桃树。也就是说，从一个分支中间单独提交并将其添加到另一个分支：

  A ----- B ------ C 
 \ 
 \ 
 D 
  

变成

  A ----- B ------ C 
 \ 
 \ 
 D ----- C'
  

当然，可以用git cherry-pick命令完成。

这个提交的问题是git认为提交包含所有的历史记录 - 因此，如果你有三个提交像这样：

  A ----- B ----- C 
  

试着摆脱B，你必须创建一个全新的提交，如下所示：

  A ----------- C'
  

其中C'具有不同的SHA-1 ID。同样，樱桃挑选从一个分支到另一个分支的提交基本上涉及生成一个补丁，然后应用它，从而也以这种方式丢失历史。

提交ID的这种改变中断git的合并功能等等（尽管如果谨慎地使用，会有启发式方法来论述这一点）。更重要的是，它忽略了函数依赖关系 - 如果C实际上使用了B中定义的函数，那么您永远不会知道。

也许更好的解决方法是有更细的分支。也就是说，不是只有'主'，而是'featureA'，'bugfixB'等。对整个分支执行代码审查 - 每个分支都非常专注于做一件事 - 然后合并一个分支，当你完成。这是git所设计的工作流程，以及它的优点：）

如果你坚持要在补丁级别处理事情，你可以看看在darcs - 它认为库是一套补丁，因此樱桃采摘成为基本操作。然而，这有它自己的一系列问题，比如很慢：）

编辑：另外，我不确定我理解你的第二个问题，关于这两个脚本。也许你可以更详细地描述它，可能作为一个单独的问题，以防止变得混乱？

I have the following branches:

• master
• production

and the following remote branches:

• origin/master
• origin/production

I have a script that fetches the origin/master branch and gets the diff of what changed from my last fetch (log -p master..origin/master). Then I merge origin/master.

The commits found are pushed to a code review tool.

I want to push the successful commits – and only them – to the production branch, and then of course to origin/production.

How can I do so?

Also, I have 2 scripts running: the one that fetch from origin/master, push commits details to a database, and merge, and the other that I'm currently writing that will have to push the successful commits.

I'd like to have those 2 scripts running while avoiding race conditions/merge conflict. Since I only want to work with specified commits, maybe there's a way to get rid of the commits that I don't want?

解决方案

The term I think you're looking for is a 'cherry pick'. That is, take a single commit from the middle of one branch and add it to another:

A-----B------C
 \
  \
   D

becomes

A-----B------C
 \
  \
   D-----C'

This, of course, can be done with the git cherry-pick command.

The problem with this commits is that git considers commits to include all history before them - thus, if you have three commits like so:

A-----B-----C

And try to get rid of B, you have to create an entirely new commit like so:

A-----------C'

Where C' has a different SHA-1 ID. Likewise, cherry picking a commit from one branch to another basically involves generating a patch, then applying it, thus losing history that way as well.

This changing of commit IDs breaks git's merging functionality among other things (though if used sparingly there are heuristics that will paper over this). More importantly though, it ignores functional dependencies - if C actually used a function defined in B, you'll never know.

Perhaps a better way to handle this would be to have more fine grained branches. That is, instead of just having a 'master', have 'featureA', 'bugfixB', etc. Perform code review on an entire branch at a time - where each branch is very focused on doing only one thing - and then merge that one branch when you're done. This is the workflow that git is designed for, and what it's good at :)

If you insist on dealing with things at the level of patches, you may want to look at darcs - it considers a repository to be a set of patches, and thus cherry picking becomes the fundamental operation. However this has its own set of problems, such as being very slow :)

Edit: Also, I'm not sure I understand your second question, about the two scripts. Maybe you could describe it in more detail, possibly as a separate question to keep things from getting confusing?

这篇关于从分支中提取所有提交，将指定的提交推送到另一个提交的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！