Git支持新产品变体 [英] Git branching for new product variation

问题描述

master 分支是使用git来管理我正在处理的存储库。 主项目。但是，我也在研究一种与主产品相似但并不相同的并行产品。它位于名为 newproject 的分支中。

代码库在两者之间非常相似，但 newproject 更加精简，并且有一些核心更改。然而，像两个分支一样，大量的CSS，JavaScript等窗饰材料是相同的。另一方面，我删除了大量的 newproject 分支中的文件仍然存在于 master 中。

我不想将这些项目合并到一起，就像创建分支来添加功能或修复错误然后合并回到 master master >中获得任何修复，进入 newproject 那里仍然有重叠/共享文件。

如果我简单地做

  $ git checkout newbranch 
 $ git pull origin master 
  

由于所有已删除的文件仍然存在于 master 中，因此所有已删除的文件都显示为冲突，所以我收到了一堆冲突。
$ b

有没有办法处理这种情况

解决方案

git子模块实现的效果正是您想要的：多个项目所依赖的通用代码体，修复所有依赖项目之间共享的通用代码。子模块通过分离共享代码的历史记录来实现效果，但这只是机制 - 一旦你看到它，你就会明白这是自然而然的正确解决方案。

子模块命令本身用于跟踪一些挑剔的内务细节（通常，您可以 rm -rf * 在回购中，不会丢失任何承诺状态，但嵌套回购并非如此，因此该命令通常会提升子模块.git dirs;类似的东西），但子模块本身不过是一个嵌套的存储库及其自己的历史记录。如果你进入它，git命令甚至不知道它是任何东西的子模块，因为它们不必关心：作为子模块就是回购的使用方式，而不是回购本身固有的任何东西。

  git init projectA 
 cd projectA 
 touch现在有一个文件在projectA根目录，
 ＃但是projectA repo不知道它
 echo'这个内容在文件A处于projectA root'> a 
 git add记录的A＃内容，索引指向它
 git commit -m'A'＃现在projectA repo拥有索引状态的永久记录
 
 
 git init projectInner＃现在有一个完整的repo在projectA root 
＃但是projectA repo不知道它
 cd projectInner 
 echoInner content> Inner＃在内部仓库中有一个文件，没有仓库知道它
 git add Inner＃内容记录，内部仓库的索引记录它
 git commit -mInner＃内部仓库有永久记录
 
 
 cd .. 
 git add projectInner＃现在projectA repo知道内部，内容被记录... 
 git commit -mInner＃现在projectA回购有一个永久记录
  

git add ing an an实际的回购意味着记录它的当前状态，就像添加一个文件或一个目录一样，但是当一个文件的记录状态是它的全部内容时，一个目录的记录状态是它的所有状态的递归状态（跟踪或不跟踪状态）忽略）内容，回购的记录状态只是它的HEAD提交的SHA - 其他所有内容都已经记录在回购本身中。

这里的负载是git子模块只是一个嵌套的回购，它变成了一个嵌套的回购宝可能是一个非常有用的东西。与git的其他部分一样，submodule命令实际上所做的事情非常简单，所有这些显而易见的复杂性都是在实现最便利的所有不同情况下实现的，它非常有用。

I'm using git to manage a repository I'm working on.

the master branch is the "main" project. However, I'm also working on a parallel product that is similar but not the same as the main product. It lives in a branch called newproject.

The code base is very similar between the two, but newproject is more stripped down, and has some core changes. However, tons of the window dressing stuff, like CSS, javascript, etc. are the same between the two branches.

On the other hand, I've deleted lots of files in the newproject branch that still exist in master.

I don't want to merge these projects back together, as is the typical case with branches where you create a branch to add a feature or fix a bug then merge back to master-- these branches will live independently permanently.

However, I still want to get any fixes from master into newproject where there is still overlap / shared files.

If I simply do

$ git checkout newbranch
$ git pull origin master

I get a boatload of conflicts since all the deleted files show up as conflicts since they still exist in master.

Is there a way to handle this situation?

解决方案

The effect git submodules achieve is exactly what you want: a body of common code on which multiple projects depend, with fixes to the common code shared among all the dependent projects. Submodules achieve the effect by separating out the history for the shared code, but that's just mechanics -- and once you see it, you'll understand it's the naturally correct solution.

The submodule command itself exists to keep track of some finicky housekeeping details (ordinarily, you can rm -rf * in a repo and not lose any committed state, but that's not true with nested repos so the command ordinarily hoists submodule .git dirs; things like that), but the submodule itself is nothing but a nested repository with its own history. If you cd into it, git commands don't even know it's a submodule of anything, because they don't have to care: being a submodule is just how the repo's being used, not anything intrinsic to the repo itself.

  git init projectA
  cd projectA
  touch A            # now there's a file at the projectA root,
                     # but the projectA repo doesn't know about it
  echo 'this content is in file "A" at the projectA root'> A
  git add A          # content recorded, the index points to it
  git commit -m'A'   # now projectA repo has a permanent record of the indexed state


  git init projectInner  # now there's an entire repo at the projectA root,
                         # but the projectA repo doesn't know about it 
  cd projectInner
  echo "Inner content" > Inner   # a file at the inner repo, no repo knows about it
  git add Inner                  # content recorded, the inner repo's index records it
  git commit -mInner             # the inner repo has a permanent record


  cd ..
  git add projectInner   # now the projectA repo knows about the inner, the content is recorded ...
  git commit -mInner     # and now the projectA repo has a permanent record

git adding an actual repo means recording its current state, just as for adding a file or a directory, but while the recorded state of a file is its entire contents, and the recorded state of a directory is the recursive state of all its (tracked or un-ignored) contents, the recorded state of a repo is simply its HEAD commit's SHA -- everything else already being recorded in that repo itself.

The payload here is that a git submodule is simply a nested repo, that it turns out a nested repo can be a very useful thing to have. As with the rest of git, what the submodule command is actually doing is brutally simple, all the apparent complexity is in implementing what's most convenient in all the different situations in which it is so useful.

这篇关于Git支持新产品变体的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！