Menu
I'm facing the following problem and don't have an answer to it:
We have a repo that was cloned from an SVN repo. The project stored in that repo is something like a platform software that gets used by various projects. The structure of the repo is like this:
platform
|- core
|- additional
The structure of that repo cannot be changed for some reasons. Both, core and additional contain data that are part of that platform.
If a project wants to use the platform and add some functionality, it creates a new folder under additional containing the sources and adds a header for that functionality to additional/includes
Currently, we simply branch off new projects from master and everything goes into the same repo. This leads to a branch inflation and my (central) repo grows more and more because all of the commits being made in the single projects go to the central repo (my colleagues are used to SVN, so they push nearly after each commit -- just to be sure...).
First I had in mind were submodules: keep platform as a submodule under a superproject (called super) and then go to super/platform/additional/mystuff, create the sources there and add them to super. But this obviously doesn't work because the files are inside the platform submodule.
Is there any better way to organize my repo, so that:
platform platform don't mess up the repo of platform?EDIT 1: Highly coupled git submodules covers quite a bit of the scenario I'm in: tightly coupled stuff, me the only one knowing a bit more than absolute basics of git, "Most of the developers have only a very cursory knowledge of git". Perfect match!
EDIT 2: While the answer from Michael looks promising, I think that it's a bit too complex to use. I'm looking for some really simple thing that doesn't need that much interaction.
546
Adding topics to your repositoryOn GitHub.com, navigate to the main page of the repository. To the right of "About", click . Under "Topics", type the topic you want to add to your repository, then type a space. After you've finished adding topics, click Save changes.
Creating your first boardProject boards are found on your GitHub organization page or on a specific repository. You will see the Projects tab in the same row as Issues and Pull requests. From the page, you'll see a green button to create a new project. There, you can set a name and description for the project.
On GitHub itself, you cannot group your repos by "folder", unless you create organizations. See SublimeText, for instance, as a group of all sublimeText packages repos.
I found your usage of master a bit confusing as I never knew
whether you meant the platform repository as a whole or just its
master branch.
My solution to this would be the following:
This is where only the platform code goes to. Use e.g. your existing repo as a starting point here.
This is a clone of the platform repository and keeps all the code of a project. Init it with
$ git clone --bare /path/to/platform
You, as a developer, start by cloning the project repository.
$ git clone /path/to/project
Now, make your changes, commit them and push them to the projects bare repo.
$ editor some-file
$ git add -p some-file
$ git commit
$ git push
Pull changes made by other developers to the projects bare repo
by using git pull.
As you also want to make changes to the platform itself, you also need a way to access the platform repo. So you add it as a remote repo to your local repo:
$ git remote add platform /path/to/platform
$ git fetch platform
As you can see now with git branch -a, your local repo knows
about the platform. Now you want to make some changes to the
platform. First you create a local branch central which is a
clone of the master branch of the platform repo:
$ git checkout -b central platform/master
You can always check which branch you're on by using git branch
or git status. Now you make your changes and commit them (to
central, where your on). As central is connected to
platform/master (checkout cat .git/config) you can push your
changes to the platform repo by simply using git push. Also
git pull works without any other arguments.
Use git checkout master and git checkout central to change
between your branches.
Note: You need to have done the work from the previous section.
First change to your platform branch and pull in the new version of the platform:
$ git checkout central
$ git pull
Now go back to your project branch and merge the changes made in the platform into your project branch.
$ git checkout master
$ git merge central
If a conflict occurs, something like this happens:
$ git merge central
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.
Open the files with the conflicts, resolve them, add them to the staging area and commit the merge:
$ editor index.html
$ git add index.html
$ git commit
Now push your changes to the project's bare repo:
$ git push
More about merge conflicts: Pro Git: Basic Merge Conflicts
If you do not want to change the platforms repo, but merge changes from there into your project use
$ git remote add platform /path/to/platform
$ git fetch platform
$ git merge platform/master
The git remote add is only needed the first time you merge.
The other two are always required.
The part about merging is based on the Pro Git Book which is licensed under cc-by-sa. All other content of this post may be considered public domain.
149
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
