#Git add remote submodule update#

We primarily use submodule remote branch tracking There are branches for each released version and tags for various other milestones. How We Use Branches History, Tags, and Workflow (dependency PRs will then include a “mention” comment of the dependent PR).įor information on reviewing and committing PRs, see the committer’s guide. Open the PRs in dependency order and assist reviewers by including the URLs of any upstream dependency PRs Try to minimise these, especially where one depends on another,Īnd especially especially where two depend on each other – that is normally a sign of broken backwards compatibility! Multi-Project ChangesĬross-project changes will require multiple PRs: When you’re finished, don’t forget to go to the UI of your repo to open a pull request. Note how the branch is tracking upstream/master for the purpose of git pull, * my-new-feature-branch -> my-new-feature-branch You could even have multiple remotes at the same time, all working as expected.% git branch my-new-feature-branch upstream/master Additionally, they will make it easier to migrate your repositories to a different organization or Git host as you won't need to change the submodule configuration for that.

They don't force all developers to use HTTPS or SSH leaving them the freedom of choice. I would recommend using relative submodule URLs whenever possible.

#Git add remote submodule update#

Update all modules from the now correct remote URL using the following command in the repository root (because it is called recursively on all submodules, even nested ones): git submodule update - init - recursive - remote gitmodules file (not necessarily the repository root if its submodules contain other nested submodules): git submodule sync This file gets committed to Git.įorce submodules to resynchronize with the modified file using the following command in the folder with the modified. The easiest way I found to do that is as follows: To fix the issue for me (and other SSH users) in repositories which already contain submodules with HTTPS URLs, I have to change the URL. or Usually all repositories in a project are at least hosted in the same service, so this technique can be used. mySubmodule.git example would work as long as the parent repository is in the same GitHub organization, e.g. This works for both HTTPS and SSH users because it uses the root repository URL as base onto which the relative path is applied. The solution is to use a relative URL instead: Url = course, that would cause problems for HTTPS users. Git can handle that but requires you to authenticate over HTTPS, effectively using two different authentication methods for a single repository.įor an SSH user, a correct configuration would be the following: The issue with the above example for an SSH user is the absolute HTTPS path.

Each submodule definition consists of a path inside the repository where the files from the submodule are placed and a URL of its repository, as in the following example: Git repositories with submodules are a different story, though. Fortunately, the way I connect to the repository usually doesn't matter, as all Git hosting services support both HTTPS and SSH. I prefer using Git over SSH which makes me a minority in most teams I work with.