pull a remote repo and pushing those files
We're working on a big project here at work with feature "bundles" (EDIT: "bundle" is just a term we use internally to refer to a specific functionality package, and isn't meant as a git term) spread out into several different git repositories. I'm getting ready to send a batch of changes upstream for review and testing, but I've run into a snag trying to get everything to play together nicely.
What I've done so far is clone
from the repo containing the code bundle into my main project, which works insofar as it gets the files where they need to go. However, when I go to add/commit
and push
, the files from the "bundle" repo won't go with it, presumably because they are part of a different git repository than the one I'm pushing from.
It's not really a viable option to ask all the other developers on the team to pull in my "bundle" every time it changes (especially since it's still somewhat early in the dev cycle and sees a lot of revisions and refactoring), and I don't really want to copy the files by hand every time开发者_开发技巧 I need to send them up, either. Preferably, I'd be able to set things up so that I could pull from my "bundle" repo into my main repo, then push the changes as a whole.
Is there a way to do what I'm looking for with git?
I'm not getting a clear picture of what you want (the usage of the word bundle seems non-standard here?); However,
man git-remote
might be what you needgit push --mirror
(perhaps starting with agit clone --mirror
- If you want the inverse (track all remote branches in a local repo), see my recent additions here: "fetch --all" in a git bare repository doesn't synchronize local branches to the remote ones
Yes, you can do it using forking.
Here is some tutorial how to fork a repository and make basic actions you need: http://help.github.com/fork-a-repo/ (GitHub help)
And here you can find something more about remotes (this feature is used to work with forks): http://help.github.com/remotes/
Your description is still not perfectly clear to me, but it sounds like you might need to use a submodule, a subtree merge, or git subtree
(a “third-party” tool).
You should probably ask around your project to see if there are plans in place for how to handle this kind of situation. Someone may have already planned how to integrate content from the “bundle” repositories into the rest of the code in the “main” repository.
Submodules are the standard way to publish a link from one repository to another (using special “gitlink” tree entries and data in the .gitmodules
file). The use of submodules allows other users to reestablish the repository-inside-repository setup that (it sounds like) you created locally during your development.
Using submodules will require some workflow changes for any other people that need to access them (i.e. git submodule update
(with --init
the first time) to make sure they have the right commit subrepository commit checked out after updating (e.g. pulling into) the “main” repository).
A subtree merge is a way of directly incorporating the content from an unrelated commit (e.g. from the repository of a library) into a subtree (subdirectory) of your main project. Only the users that need to pull in (or push out) updates to the content under the subtree actually need to do anything differently (e.g. they can use git merge -s subtree
to merge in updates to the source history). Some people dislike subtree merges because it incorporates (“pollutes”) the main project’s history with a copy of the subtree’s history.
The git subtree
tool (a third-party tool) can help manage normal subtree merges. For example, the git subtree split
subcommand can take commits made atop the main repository’s history and rewrite them so that they appear atop the subtree’s original history. This makes it easy to make “local” changes to the subtree content and later push them “upstream”. It also has a --squash
mode that offers much of the benefit of a normal subtree merge while preventing the history “pollution”.
The author of git subtree
has linked to a tutorial that seems fairly useful.
精彩评论