[英]How can I specify a branch/tag when adding a Git submodule?
How does git submodule add -b
work? git submodule add -b
如何工作?
After adding a submodule with a specific branch, a new cloned repository (after git submodule update --init
) will be at a specific commit, not the branch itself ( git status
on the submodule shows "Not currently on any branch").添加具有特定分支的子模块后,新的克隆存储库(在
git submodule update --init
之后)将处于特定提交,而不是分支本身(子模块上的git status
显示“当前不在任何分支上”)。
I can't find any information on .gitmodules
or .git/config
about the submodule's branch or any specific commit, so how does Git figure it out?我在
.gitmodules
或.git/config
上找不到关于子模块分支或任何特定提交的任何信息,那么 Git 是如何弄清楚的呢?
Also, is it possible to specify a tag instead of a branch?另外,是否可以指定标签而不是分支?
I'm using version 1.6.5.2.我使用的是 1.6.5.2 版。
Note: Git 1.8.2 added the possibility to track branches.注意:Git 1.8.2 添加了跟踪分支的可能性。 See some of the answers below.
请参阅下面的一些答案。
It's a little confusing to get used to this, but submodules are not on a branch.习惯这一点有点令人困惑,但子模块不在分支上。 They are, like you say, just a pointer to a particular commit of the submodule's repository.
就像您说的那样,它们只是指向子模块存储库的特定提交的指针。
This means, when someone else checks out your repository, or pulls your code, and does git submodule update, the submodule is checked out to that particular commit.这意味着,当其他人检出您的存储库或提取您的代码并执行 git submodule update 时,子模块将检出到该特定提交。
This is great for a submodule that does not change often, because then everyone on the project can have the submodule at the same commit.这对于不经常更改的子模块非常有用,因为项目中的每个人都可以在同一个提交中拥有子模块。
If you want to move the submodule to a particular tag:如果要将子模块移动到特定标签:
cd submodule_directory
git checkout v1.0
cd ..
git add submodule_directory
git commit -m "moved submodule to v1.0"
git push
Then, another developer who wants to have submodule_directory changed to that tag, does this然后,另一个想要将 submodule_directory 更改为该标记的开发人员执行此操作
git pull
git submodule update --init
git pull
changes which commit their submodule directory points to. git pull
提交其子模块目录指向的更改。 git submodule update
actually merges in the new code. git submodule update
实际上合并到新代码中。
I'd like to add an answer here that is really just a conglomerate of other answers, but I think it may be more complete.我想在这里添加一个答案,它实际上只是其他答案的集合,但我认为它可能更完整。
You know you have a Git submodule when you have these two things.当你有这两件事时,你就知道你有一个 Git 子模块。
Your .gitmodules
has an entry like so:你的
.gitmodules
有一个像这样的条目:
[submodule "SubmoduleTestRepo"] path = SubmoduleTestRepo url = https://github.com/jzaccone/SubmoduleTestRepo.git
You have a submodule object (named SubmoduleTestRepo in this example) in your Git repository.您的 Git 存储库中有一个子模块对象(在本示例中名为 SubmoduleTestRepo)。 GitHub shows these as "submodule" objects.
GitHub 将这些显示为“子模块”对象。 Or do
git submodule status
from a command line.或者从命令行执行
git submodule status
。 Git submodule objects are special kinds of Git objects, and they hold the SHA information for a specific commit. Git 子模块对象是特殊类型的 Git 对象,它们保存特定提交的 SHA 信息。
Whenever you do a git submodule update
, it will populate your submodule with content from the commit.每当您执行
git submodule update
,它都会使用提交中的内容填充您的子模块。 It knows where to find the commit because of the information in the .gitmodules
.由于
.gitmodules
中的信息,它知道在哪里可以找到提交。
Now, all the -b
does is add one line in your .gitmodules
file.现在,
-b
所做的就是在.gitmodules
文件中添加一行。 So following the same example, it would look like this:因此,按照相同的示例,它看起来像这样:
[submodule "SubmoduleTestRepo"] path = SubmoduleTestRepo url = https://github.com/jzaccone/SubmoduleTestRepo.git branch = master
Note: only branch name is supported in a
.gitmodules
file, but SHA and TAG are not supported!注意:
.gitmodules
文件只支持分支名称,不支持 SHA 和 TAG! (instead of that, the branch's commit of each module can be tracked and updated using "git add .
", for example likegit add ./SubmoduleTestRepo
, and you do not need to change the.gitmodules
file each time)(取而代之的是,可以使用“
git add .
”来跟踪和更新每个模块的分支提交,例如git add ./SubmoduleTestRepo
,并且您不需要每次都更改.gitmodules
文件)
The submodule object is still pointing at a specific commit.子模块对象仍然指向特定的提交。 The only thing that the
-b
option buys you is the ability to add a --remote
flag to your update as per Vogella's answer: -b
选项为您购买的唯一功能是能够根据 Vogella 的回答向您的更新添加--remote
标志:
git submodule update --remote
Instead of populating the content of the submodule to the commit pointed to by the submodule, it replaces that commit with the latest commit on the master branch, THEN it populates the submodule with that commit.它不是将子模块的内容填充到子模块指向的提交,而是用主分支上的最新提交替换该提交,然后用该提交填充子模块。 This can be done in two steps by djacobs7 answer.
这可以通过 djacobs7 answer 分两步完成。 Since you have now updated the commit the submodule object is pointing to, you have to commit the changed submodule object into your Git repository.
由于您现在已经更新了子模块对象指向的提交,因此您必须将更改的子模块对象提交到您的 Git 存储库中。
git submodule add -b
is not some magically way to keep everything up to date with a branch. git submodule add -b
并不是通过分支使所有内容保持最新的神奇方式。 It is simply adds information about a branch in the .gitmodules
file and gives you the option to update the submodule object to the latest commit of a specified branch before populating it.它只是在
.gitmodules
文件中添加有关分支的信息,并为您提供在填充之前将子模块对象更新为指定分支的最新提交的选项。
(Git 2.22, Q2 2019, has introduced git submodule set-branch --branch aBranch -- <submodule_path>
) (Git 2.22,Q2 2019,引入了
git submodule set-branch --branch aBranch -- <submodule_path>
)
Note that if you have an existing submodule which isn't tracking a branch yet , then ( if you have git 1.8.2+ ):请注意,如果您有一个尚未跟踪分支的现有子模块,那么(如果您有 git 1.8.2+ ):
Make sure the parent repo knows that its submodule now tracks a branch:确保父仓库知道它的子模块现在跟踪一个分支:
cd /path/to/your/parent/repo git config -f .gitmodules submodule.<path>.branch <branch>
Make sure your submodule is actually at the latest of that branch:确保您的子模块实际上是该分支的最新版本:
cd path/to/your/submodule git checkout -b branch --track origin/branch # if the master branch already exist: git branch -u origin/master master
(with 'origin' being the name of the upstream remote repo the submodule has been cloned from. ('origin' 是上游远程存储库的名称,子模块已从中克隆。
A git remote -v
inside that submodule will display it.该子模块中的
git remote -v
将显示它。 Usually, it is 'origin')通常,它是“起源”)
Don't forget to record the new state of your submodule in your parent repo:不要忘记在父仓库中记录子模块的新状态:
cd /path/to/your/parent/repo git add path/to/your/submodule git commit -m "Make submodule tracking a branch"
Subsequent update for that submodule will have to use the --remote
option:该子模块的后续更新必须使用
--remote
选项:
# update your submodule # --remote will also fetch and ensure that # the latest commit from the branch is used git submodule update --remote # to avoid fetching use git submodule update --remote --no-fetch
Note that with Git 2.10+ (Q3 2016), you can use ' .
请注意,在Git 2.10+ (2016 年第三季度)中,您可以使用 '
.
' as a branch name: ' 作为分支名称:
The name of the branch is recorded as
submodule.<name>.branch
in.gitmodules
forupdate --remote
.分支的
submodule.<name>.branch
在.gitmodules
记录为submodule.<name>.branch
.gitmodules
用于update --remote
。
A special value of.
的特殊值
.
is used to indicate that the name of the branch in the submodule should be the same name as the current branch in the current repository .用于指示子模块中的分支名称应与当前存储库中的当前分支名称相同。
But, as commented by LubosD但是, 正如LubosD 所评论的那样
With
git checkout
, if the branch name to follow is ".
", it will kill your uncommitted work!使用
git checkout
,如果要遵循的分支名称是“.
”,它将杀死您未提交的工作!
Usegit switch
instead.请改用
git switch
。
That means Git 2.23 (August 2019) or more.这意味着 Git 2.23(2019 年 8 月)或更高版本。
See " Confused by git checkout
"参见“被
git checkout
混淆”
If you want to update all your submodules following a branch:如果要更新分支后的所有子模块:
git submodule update --recursive --remote
Note that the result, for each updated submodule, will almost always be a detached HEAD , as Dan Cameron note in his answer .请注意,对于每个更新的子模块,结果几乎总是一个分离的 HEAD ,正如Dan Cameron在他的回答中指出的那样。
( Clintm notes in the comments that, if you run git submodule update --remote
and the resulting sha1 is the same as the branch the submodule is currently on, it won't do anything and leave the submodule still "on that branch" and not in detached head state.) ( Clintm 在评论中指出,如果您运行
git submodule update --remote
并且生成的 sha1 与子模块当前所在的分支相同,它不会做任何事情并使子模块仍然“在该分支上”并且不是处于分离的头部状态。)
To ensure the branch is actually checked out (and that won't modify the SHA1 of the special entry representing the submodule for the parent repo), he suggests:为了确保分支实际被检出(并且不会修改代表父存储库子模块的特殊条目的 SHA1),他建议:
git submodule foreach -q --recursive 'branch="$(git config -f $toplevel/.gitmodules submodule.$name.branch)"; git switch $branch'
Each submodule will still reference the same SHA1, but if you do make new commits, you will be able to push them because they will be referenced by the branch you want the submodule to track.每个子模块仍将引用相同的 SHA1,但如果您确实进行了新提交,您将能够推送它们,因为它们将被您希望子模块跟踪的分支引用。
After that push within a submodule, don't forget to go back to the parent repo, add, commit and push the new SHA1 for those modified submodules.在子模块中推送之后,不要忘记返回父存储库,为那些修改过的子模块添加、提交和推送新的 SHA1。
Note the use of $toplevel
, recommended in the comments by Alexander Pogrebnyak .请注意Alexander Pogrebnyak 在评论中推荐的
$toplevel
的使用。
$toplevel
was introduced in git1.7.2 in May 2010: commit f030c96 . $toplevel
于 2010 年 5 月在 git1.7.2 中引入: commit f030c96 。
it contains the absolute path of the top level directory (where
.gitmodules
is).它包含顶级目录的绝对路径(
.gitmodules
所在的.gitmodules
)。
dtmland
adds in the comments : dtmland
在评论中补充道:
The foreach script will fail to checkout submodules that are not following a branch.
foreach 脚本将无法检出未遵循分支的子模块。
However, this command gives you both:但是,此命令为您提供:
git submodule foreach -q --recursive 'branch="$(git config -f $toplevel/.gitmodules submodule.$name.branch)"; [ "$branch" = "" ] && git checkout master || git switch $branch' –
The same command but easier to read:相同的命令但更易于阅读:
git submodule foreach -q --recursive \
'branch="$(git config -f $toplevel/.gitmodules submodule.$name.branch)"; \
[ "$branch" = "" ] && \
git checkout master || git switch $branch' –
umläute refines dtmland 's command with a simplified version in the comments : umläute 在评论中使用简化版本改进了dtmland的命令:
git submodule foreach -q --recursive 'git switch $(git config -f $toplevel/.gitmodules submodule.$name.branch || echo master)'
multiple lines:多行:
git submodule foreach -q --recursive \
'git switch \
$(git config -f $toplevel/.gitmodules submodule.$name.branch || echo master)'
Before Git 2.26 (Q1 2020), a fetch that is told to recursively fetch updates in submodules inevitably produces reams of output, and it becomes hard to spot error messages.在 Git 2.26(2020 年第一季度)之前,被告知在子模块中递归获取更新的获取不可避免地会产生大量输出,并且很难发现错误消息。
The command has been taught to enumerate submodules that had errors at the end of the operation .该命令已被教导枚举在操作结束时出现错误的子模块。
See commit 0222540 (16 Jan 2020) by Emily Shaffer ( nasamuffin
) .请参阅Emily Shaffer (
nasamuffin
) 提交的 0222540 (2020 年 1 月 16 日) 。
(Merged by Junio C Hamano -- gitster
-- in commit b5c71cc , 05 Feb 2020) (由Junio C
gitster
-- gitster
--在提交 b5c71cc 中合并,2020 年 2 月 5 日)
fetch
: emphasize failure during submodule fetchfetch
: 强调子模块获取过程中的失败Signed-off-by: Emily Shaffer
签字人:Emily Shaffer
In cases when a submodule fetch fails when there are many submodules, the error from the lone failing submodule fetch is buried under activity on the other submodules if more than one fetch fell back on
fetch-by-oid
.在有许多子模块时子模块获取失败的情况下,如果多个获取回退到
fetch-by-oid
上,则单独失败的子模块获取的错误会被其他子模块的活动所fetch-by-oid
。
Call out a failure late so the user is aware that something went wrong, and where .晚点调用失败,以便用户知道出了什么问题,以及哪里出了问题。
Because
fetch_finish()
is only called synchronously byrun_processes_parallel,
mutexing is not required aroundsubmodules_with_errors
.由于
fetch_finish()
仅由run_processes_parallel,
同步run_processes_parallel,
因此不需要围绕submodules_with_errors
互斥。
Note that, with Git 2.28 (Q3 2020), Rewrite of parts of the scripted "git submodule" Porcelain command continues;请注意,在 Git 2.28(2020 年第三季度)中,重写部分脚本化的“git submodule”Porcelain 命令继续; this time it is "
git submodule set-branch
" subcommand's turn.这次轮到“
git submodule set-branch
”子命令了。
See commit 2964d6e (02 Jun 2020) by Shourya Shukla ( periperidip
) .请参阅Shourya Shukla (
periperidip
) 的commit 2964d6e (02 Jun 2020 ) 。
(Merged by Junio C Hamano -- gitster
-- in commit 1046282 , 25 Jun 2020) (由Junio C
gitster
合并-- gitster
-- in commit 1046282 ,2020 年 6 月 25 日)
submodule
: port subcommand 'set-branch' from shell to Csubmodule
:从 shell 到 C 的端口子命令“set-branch”Mentored-by: Christian Couder
导师:Christian Couder
Mentored-by: Kaartic Sivaraam导师:Kaartic Sivaraam
Helped-by: Denton Liu帮助:Denton Liu
Helped-by: Eric Sunshine帮助者:Eric Sunshine
Helped-by: Đoàn Trần Công Danh帮助者:Đoàn Trần Công Danh
Signed-off-by: Shourya Shukla签字人:Shourya Shukla
Convert submodule subcommand 'set-branch' to a builtin and call it via
git submodule.sh
.将子模块子命令 'set-branch' 转换为内置命令并通过
git submodule.sh
调用它。
Git 1.8.2 added the possibility to track branches. Git 1.8.2 添加了跟踪分支的可能性。
# add submodule to track branch_name branch
git submodule add -b branch_name URL_to_Git_repo optional_directory_rename
# update your submodule
git submodule update --remote
See also Git submodules另请参阅Git 子模块
An example of how I use Git submodules.我如何使用 Git 子模块的示例。
And that looks a little bit like this:这看起来有点像这样:
git init
vi README
git add README
git commit
git submodule add git://github.com/XXXXX/xxx.yyyy.git stm32_std_lib
git status
git submodule init
git submodule update
cd stm32_std_lib/
git reset --hard V3.1.2
cd ..
git commit -a
git submodule status
Maybe it helps (even though I use a tag and not a branch)?也许它有帮助(即使我使用标签而不是分支)?
In my experience switching branches in the superproject or future checkouts will still cause detached HEADs of submodules regardless if the submodule is properly added and tracked (ie @djacobs7 and @Johnny Z answers).根据我的经验,无论是否正确添加和跟踪子模块(即 @djacobs7 和 @Johnny Z 答案),切换超级项目中的分支或将来的结帐仍会导致子模块的 HEAD 分离。
And instead of manually checking out the correct branch manually or through a script git submodule foreach can be used.并且可以使用git submodule foreach代替手动或通过脚本手动检出正确的分支。
This will check the submodule config file for the branch property and checkout the set branch.这将检查分支属性的子模块配置文件并检出设置分支。
git submodule foreach -q --recursive 'branch="$(git config -f $toplevel.gitmodules submodule.$name.branch)"; git checkout $branch'
Git submodules are a little bit strange - they're always in "detached head" mode - they don't update to the latest commit on a branch like you might expect. Git 子模块有点奇怪——它们总是处于“分离头”模式——它们不会像你期望的那样更新到分支上的最新提交。
This does make some sense when you think about it, though.不过,当你考虑它时,这确实是有道理的。 Let's say I create repository foo with submodule bar .
假设我使用子模块bar创建存储库foo 。 I push my changes and tell you to check out commit a7402be from repository foo .
我推送我的更改并告诉您从存储库foo检查提交 a7402be 。
Then imagine that someone commits a change to repository bar before you can make your clone.然后想象有人在您可以进行克隆之前提交了对存储库栏的更改。
When you check out commit a7402be from repository foo , you expect to get the same code I pushed.当您从存储库foo检出提交 a7402be 时,您希望获得与我推送的相同的代码。 That's why submodules don't update until you tell them to explicitly and then make a new commit.
这就是为什么子模块在您明确告诉它们然后进行新提交之前不会更新的原因。
Personally I think submodules are the most confusing part of Git.我个人认为子模块是 Git 中最令人困惑的部分。 There are lots of places that can explain submodules better than I can.
有很多地方可以比我更好地解释子模块。 I recommend Pro Git by Scott Chacon.
我推荐 Scott Chacon 的Pro Git 。
Existing answers have the second step missing and overloaded with details.现有答案缺少第二步,并且细节过多。
To switch an existing submodule to track a new remote url and/or a new branch:要切换现有子模块以跟踪新的远程 url 和/或新分支:
.gitmodules
..gitmodules
中编辑事实来源。 For example, from例如,从
[submodule "api"]
path = api
url = https://github.com/<original_repo>/api.git
to至
[submodule "api"]
path = api
url = https://github.com/<another_repo>/api.git
branch = work-in-progress
git submodule sync
: Updates the description of submodules cached by git in .git/modules
from the just-edited source of truth specified in .gitmodules
. git submodule sync
:更新.git/modules
中 git 缓存的子模块的描述,来自.gitmodules
中指定的刚刚编辑的真实来源。
git submodule update --init --recursive --remote
: Updates the checked-out submodules in the working copy. git submodule update --init --recursive --remote
:更新工作副本中签出的子模块。
Commit the changes.提交更改。
To switch branch for a submodule (assuming you already have the submodule as part of the repository):要为子模块切换分支(假设您已经将子模块作为存储库的一部分):
cd
to root of your repository containing the submodules cd
到包含子模块的存储库的根目录.gitmodules
for editing.gitmodules
进行编辑path = ...
and url = ...
that says branch = your-branch
, for each submodule;path = ...
和url = ...
下面添加一行,表示branch = your-branch
,对于每个子模块; save file .gitmodules
..gitmodules
。$ git submodule update --remote
$ git submodule update --remote
...this should pull in the latest commits on the specified branch, for each submodule thus modified. ...这应该为每个修改后的子模块拉入指定分支上的最新提交。
I have this in my .gitconfig file.我的 .gitconfig 文件中有这个。 It is still a draft, but proved useful as of now.
它仍然是一个草案,但到目前为止证明是有用的。 It helps me to always reattach the submodules to their branch.
它帮助我始终将子模块重新附加到他们的分支。
[alias]
######################
#
#Submodules aliases
#
######################
#git sm-trackbranch : places all submodules on their respective branch specified in .gitmodules
#This works if submodules are configured to track a branch, i.e if .gitmodules looks like :
#[submodule "my-submodule"]
# path = my-submodule
# url = git@wherever.you.like/my-submodule.git
# branch = my-branch
sm-trackbranch = "! git submodule foreach -q --recursive 'branch=\"$(git config -f $toplevel/.gitmodules submodule.$name.branch)\"; git checkout $branch'"
#sm-pullrebase :
# - pull --rebase on the master repo
# - sm-trackbranch on every submodule
# - pull --rebase on each submodule
#
# Important note :
#- have a clean master repo and subrepos before doing this !
#- this is *not* equivalent to getting the last committed
# master repo + its submodules: if some submodules are tracking branches
# that have evolved since the last commit in the master repo,
# they will be using those more recent commits !
#
# (Note : On the contrary, git submodule update will stick
#to the last committed SHA1 in the master repo)
#
sm-pullrebase = "! git pull --rebase; git submodule update; git sm-trackbranch ; git submodule foreach 'git pull --rebase' "
# git sm-diff will diff the master repo *and* its submodules
sm-diff = "! git diff && git submodule foreach 'git diff' "
#git sm-push will ask to push also submodules
sm-push = push --recurse-submodules=on-demand
#git alias : list all aliases
#useful in order to learn git syntax
alias = "!git config -l | grep alias | cut -c 7-"
We use Quack to pull a specific module from another Git repository.我们使用Quack从另一个 Git 存储库中提取特定模块。 We need to pull code without the whole code base of the provided repository - we need a very specific module / file from that huge repository and should be updated every time we run update.
我们需要在没有提供的存储库的整个代码库的情况下提取代码——我们需要从那个巨大的存储库中获取一个非常具体的模块/文件,并且每次运行更新时都应该更新。
So we achieved it in this way:所以我们是这样实现的:
Create configuration创建配置
name: Project Name
modules:
local/path:
repository: https://github.com/<username>/<repo>.git
path: repo/path
branch: dev
other/local/path/filename.txt:
repository: https://github.com/<username>/<repo>.git
hexsha: 9e3e9642cfea36f4ae216d27df100134920143b9
path: repo/path/filename.txt
profiles:
init:
tasks: ['modules']
With the above configuration, it creates one directory from the provided GitHub repository as specified in first module configuration, and the other one is to pull and create a file from the given repository.通过上述配置,它从提供的 GitHub 存储库中创建一个目录,如第一个模块配置中指定的那样,另一个是从给定的存储库中拉取并创建一个文件。
Other developers just need to run其他开发者只需要运行
$ quack
And it pulls the code from the above configurations.它从上述配置中提取代码。
The only effect of choosing a branch for a submodule is that, whenever you pass the --remote
option in the git submodule update
command line, Git will check out in detached HEAD mode (if the default --checkout
behavior is selected) the latest commit of that selected remote branch.为子模块选择分支的唯一效果是,每当您在
git submodule update
命令行中传递--remote
选项时,Git 都会以分离的 HEAD模式--checkout
(如果选择了默认的--checkout
行为)最新的提交选定的远程分支。
You must be particularly careful when using this remote branch tracking feature for Git submodules if you work with shallow clones of submodules.如果您使用子模块的浅层克隆,则在对 Git 子模块使用此远程分支跟踪功能时必须特别小心。 The branch you choose for this purpose in submodule settings IS NOT the one that will be cloned during
git submodule update --remote
.您在子模块设置中为此目的选择的分支不是将在
git submodule update --remote
期间克隆的git submodule update --remote
。 If you pass also the --depth
parameter and you do not instruct Git about which branch you want to clone -- and actually you cannot in the git submodule update
command line!!如果你还传递了
--depth
参数并且你没有告诉 Git 你想要克隆哪个分支——实际上你不能在git submodule update
命令行中!! -- , it will implicitly behave like explained in the git-clone(1)
documentation for git clone --single-branch
when the explicit --branch
parameter is missing, and therefore it will clone the primary branch only . -- ,当显式的
--branch
参数丢失时,它将隐式地表现得像git clone --single-branch
的git-clone(1)
文档中解释的那样,因此它只会克隆主分支。
With no surprise, after the clone stage performed by the git submodule update
command, it will finally try to check out the latest commit for the remote branch you previously set up for the submodule, and, if this is not the primary one, it is not part of your local shallow clone, and therefore it will fail with不出所料,在
git submodule update
命令执行克隆阶段后,它最终会尝试检查您之前为子模块设置的远程分支的最新提交,如果这不是主要分支,则为不是本地浅层克隆的一部分,因此它会失败
fatal: Needed a single revision
致命:需要一次修订
Unable to find current origin/ NotThePrimaryBranch revision in submodule path 'mySubmodule'
无法在子模块路径“mySubmodule”中找到当前来源/ NotThePrimaryBranch修订版
git submodule add -b develop --name branch-name -- https://branch.git
Use the below commands使用以下命令
To add submodule (branch-branch)添加子模块(分支分支)
git submodule add -b stage git@github.optum.com:orgname/${reponame}.git
Update Submodule (branch-branch)更新子模块(分支-分支)
######Clone########
> git clone -b master --single-branch --recurse-submodules git@github.com:orgname/project.git
or
> git clone -b stage --single-branch --recurse-submodules git@github.com:orgname/project.git
######Update#######
> git submodule update --remote (only for remote branch -ie master)
or
> git submodule update --recursive --remote
> git submodule update --init --recursive (for remaining branchs)
if you get fatal need single revision error then use below commands:-
before:-
*** stage
remotes/origin/stage**
git branch -a
git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/{branch name}
ex:- git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/stage
after:-
*** stage
remotes/origin/HEAD -> origin/stage
remotes/origin/stage**
then
> git reset --hard
#hard reset revisions#
> git submodule foreach git reset --hard origin/develop
> git submodule foreach git pull origin develop
after commit and push accordingly.. now submodules will get updated.在提交并相应地推送之后.. 现在子模块将得到更新。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.