Split a git repository to work on two projects at the same time
I am developing a framework to use on my projects; however, the developing of a framework can go so far without context: ie I need to start using it in real-life projects and see specifically what I need to add, fix, or adjust (maybe things that worked on a testing environment don't work for real-life situation, or some things don't make sense, or I want to add features).
First of all, since Framework is obviously a work in progress, I need to be sure that it is kept updated within Real-life project as a different part of it, so I can go back to Framework, edit it, commit, go back to Real-life project update Framework within, go on working with the project.
Second, I would actually like a way to achieve this without doing the project switching. What I mean is that I would like to be able to edit Framework within Real-life project and push those commits to the Framework repository.
Now, I know that the tools to achieve this are most likely git submodule and git subtree , but both of them are pretty confusing. Submodule, especially, seems it is more oriented towards a read-only approach (eg keep your libraries always updated): this would satisfy my first requirement, but not the second.
Any pointers on how to achieve this with Git and how the workflow would look like?
Any of the two approaches would serve you.
Each one can allow what you need, to edit the project in place and to push that specific content to a separate repositories.
Both approaches would also incur in an amount of overhead in order to keep both projects running.
About the two points you mention:
With Submodules you would have a repository inside a folder of other repository. The outer one (Real-Life) keeps saved in a file the location of your submodule (Framework) repository, and the current commit being used. When you want to edit Framework you just go to the sub-folder where it is stored, and inside there it should behave as if you where in a completely separate git repository with its own remote and history. After modifying Framework you return back to Real-Life and update the submodule references. The process would look usually like this:
Edit files in Framework
Move to Framework subfolder
Stage, commit, and push changes to Framework repository
Go back to Real-Life folder
Update Real-Life submodule reference
With Subtrees you work with Real-Life and Framework in the same repository, still keeping Framework code under a specific sub-folder. When you change content in Framework you still commit those Real-Life repository as if was a single project. What the subtree tools allow is that you can isolate the changes that you have in the Framework folder and create from these a set of commits that exists separate from Real-Life, this commits will contain Framework-only changes and can be pushed the the Framework repository. The process would look like this:
Edit files in Framework
Stage, commit, and push to Real-Life repository
Create Framework commits using subtree tools
Push Framework specific commits to Framework repository
If you are still unsure of the trade backs that exist between these two I would suggest that you go with using submodules . You will find more documentation, use cases, and is generally less complex. It has some short-comings but by being familiar with submodules first you could gauge what subtrees offer. More info about submodules.
Branching in Git is one of its many great features. If you have used other version control systems, it's probably helpful to forget most of what you think about branches - in fact, it may be more helpful to think of them practically as contexts since that is how you will most often be using them. When you checkout different branches, you change contexts that you are working in and you can quickly context-switch back and forth between several different branches.
In a nutshell you can create a branch with git branch (branchname), switch into that context with git checkout (branchname), record commit snapshots while in that context, then can switch back and forth easily. When you switch branches, Git replaces your working directory with the snapshot of the latest commit on that branch so you don't have to have multiple directories for multiple branches. You merge branches together with git merge. You can easily merge multiple times from the same branch over time, or alternately you can choose to delete a branch immediately after merging it.
链接地址: http://www.djcxy.com/p/15848.html下一篇: 拆分git仓库以同时处理两个项目