在git中,是否有一种将不相关的分支引入到存储库的简单方法? [英] In git, is there a simple way of introducing an unrelated branch to a repository?
问题描述
在今天帮助一个有git问题的朋友时,我不得不介绍一个
分支,它需要完全独立于 master
分支。
这个分支的内容与 master
分支上开发的
有着不同的来源,但它们将是
在稍后时间合并到 master
分支中。
我从阅读John Wiegley的 Git从底部
上涨如何
分支基本上是标签到遵循特定
约定的提交,以及如何将提交与文件树绑定,并且可选地将
绑定到父提交。我们使用git的管道创建了一个无父母提交给
的存储库:
所以我们删除了索引中的所有文件...
$ git rm -rf。
...从tarball中提取目录和文件,并将它们添加到
索引中。 ..
$ git add。
...并创建了一个树形对象...
$ git write-tree
code> git-write-tree 告诉我们创建的树对象的sha1sum。)
然后,我们提交了树,没有指定父提交... $ echoImported project foo| git commit-tree $ TREE
( git-commit-tree
告诉我们创建的提交对象的sha1sum。)
...并创建了一个指向我们新创建的
提交的新分支。
$ git update-ref refs / heads / other-branch $ COMMIT
最后,我们返回 master
分支继续在那里工作。
$ git checkout -f master
<这似乎是按计划进行的。但是,这显然不是我推荐给那些刚刚开始使用git的
的程序的那种
的程序,要稍微说明一下。 是否有更简单的方法创建一个
的新分支,与存储库中发生的
的所有内容完全无关?
$ b
git checkout
现在支持 - orphan
选项。从手册页:
git checkout [-q] [-f] [-m] --orphan< new_branch> [< start_point>]
创建一个新的孤儿 b $ b< new_branch>,从
开始< start_point>并切换到它。在这个新分支
上做的
第一次提交将没有父母,它将是
新历史的根目录,总共
与所有其他
分支断开连接,并且提交。
这并不正是提交者想要的内容,因为它填充索引和从 总结: I左 While helping a friend with a git problem today, I had to introduce a
branch that needed to be totally separate from the I remembered from reading John Wiegley's Git from the bottom
up how
branches are essentially a label to a commit that follows a certain
convention and how a commit is tied to a tree of files and, optionally
to parent commits. We went to create a parentless commit to the
existing repository using git's plumbing: So we got rid of all files in the index ... ... extracted directories and files from a tarball, added those to the
index ... ... and created a tree object ... ( Then, We committed the tree, without specifying parent commits... ( ... and created a new branch that points to our newly created
commit. Finally, we returned to the This seems to have worked as planned. But this is clearly not the kind
of procedure I would recommend to someone who is just getting started
using git, to put it mildly. Is there an easier way of creating a
new branch that is entirely unrelated to everything that has happened
in the repository so far? There is a new feature (since V1.7.2) which makes this task a little more high-level than what's in any of the other answers. Create a new orphan branch, named
<new_branch>, started from
<start_point> and switch to it. The
first commit made on this new branch
will have no parents and it will be
the root of a new history totally
disconnected from all the other
branches and commits. This doesn't do exactly what the asker wanted, because it populates the index and the working tree from In summary: I left 这篇关于在git中,是否有一种将不相关的分支引入到存储库的简单方法?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!< start_point>
工作树(毕竟,这是一个签出命令)。唯一需要的其他操作是从工作树和索引中删除任何不需要的项目。不幸的是, git reset --hard
不起作用,但可以使用 git rm -rf。
相信这相当于 rm .git / index;其他答案中给出的git clean -fdx
)。 b
$ b
git checkout --orphan newbranch
git rm -rf。
git commit -m'初始提交'
< start_point>
未指定,因为它默认为HEAD,我们也不太在意。这个序列与 Artem的答案,只是不诉诸可怕的管道命令。 master
branch.
The contents of this branch really had a different origin from what
had been developed on the master
branch, but they were going to be
merged into the master
branch at a later time.$ git rm -rf .
$ git add .
$ git write-tree
git-write-tree
told us the sha1sum of the created tree object.)$ echo "Imported project foo" | git commit-tree $TREE
git-commit-tree
told us the sha1sum of the created commit object.)$ git update-ref refs/heads/other-branch $COMMIT
master
branch to continue work there.$ git checkout -f master
git checkout
now supports the --orphan
option. From the man page:git checkout [-q] [-f] [-m] --orphan <new_branch> [<start_point>]
<start_point>
(since this is, after all, a checkout command). The only other action necessary is to remove any unwanted items from the working tree and index. Unfortunately, git reset --hard
doesn't work, but git rm -rf .
can be used instead (I believe this is equivalent to rm .git/index; git clean -fdx
given in other answers).
git checkout --orphan newbranch
git rm -rf .
<do work>
git add your files
git commit -m 'Initial commit'
<start_point>
unspecified because it defaults to HEAD, and we don't really care anyway. This sequence does essentially the same thing as the command sequence in Artem's answer, just without resorting to scary plumbing commands.