Re: git subtree workflow
- From
Paul Campbell <pcampbell@kemitix.net>
- Date
- Feb 27, 2013, 23:37 UTC
- Message-ID
- <CALeLG_nNQ_ERa23Or+qmNmsxQDahRtxbejmUHKnGFd8EoQCtww@mail.gmail.com>
- In-Reply-To
- <CAH3cagOtcR3fgoXK-Xd8vm48q0GPQtYMkWiqQGgydb27HeO0wQ@mail.gmail.com>
On Tue, Feb 26, 2013 at 9:04 AM, Ben McCann <ben@benmccann.com> wrote:
Show 8 quoted lines
> I'm fairly new to git and am trying to determine if git subtree would > be helpful for managing our company's codebase, which has several > repos some of which depend on each other. All the examples I've seen > make sense to me as a one-time operation to merge separate repos into > one monolithic one or to split one monolithic repo into separate > repos. I'm having a harder time understanding how this fits into a > larger picture and what the workflow for working with subtree would > be.
The git subtree command does support pushing and pulling changes to/from a subtree to a remote repo. This operation can be repeated over time as the underlying git subtree split command produces an accurate extract from the subtree.
For example:
$ git clone $superrepo super $ cd super $ git subtree add --prefix=child $childrepo master $ split_head=$(git subtree split --prefix=child)
git subtree split creates a synthetic copy of the child subtree and returns the SHA1 for the head of that subtree.
$ cd .. $ git clone $childrepo child $ cd child $ child_head=$(git rev-parse master)
$split_head and $child_head match.
You could pass either $*_head to gitk and be able to browse identical trees and histories.
$ gitk $child_head & $ cd ../super $ gitk $split_head &
The only difference you should see is that the tree in the super project doesn't have any branches or tags from the child repo.
Show 8 quoted lines
> If I have a bunch of repos on GitHub and some depend on each other, > how would I set them up to work with subtree? Would GitHub continue to > host them as is, host a merged monolithic repo, or host both a > monolithic repo and the splitted out repos? The exact answer probably > varies, but I imagine there's basic workflow that would satisfy 80% of > users. If I have GitHub host both monolithic and splitted out repos, > it seems unclear as to how I keep those repos in sync and make sure > all the developers in our company push their changes to both repos.
This is what I'm using git-subtree for. I have a super project which holds child repos, some of which hold other child repos. You can develop on all of your projects within the super project and still periodically pull and push updates with the remote child repos.
Someone who doesn't know about your child repos can take the monolithic repo and commit to it as normal. You can then pull their commits and push any changes to the child repos. Probably to a non-master branch so you they can be integrated like other pull requests.
Caveats:
1) I would probably avoid the --squash option as I suspect that might mess with $split_head == $child_head. Whether or not it would have any impact of your ability to push or pull I don't know. I've not tried it.
2) When you commit you should ideally not commit a set of files that are in more than one subtree. You're commit history when you push back to the source repo for a subtree might look a bit odd if it's referring to other parts of the super project or it's subtrees.
-- Paul [W] Campbell