How to push a part of a project into a separate branch in Git?

Question

git

There is a site, the core of which can be used to create another site.
The difference will be only in styles and layout.
The question arises how to allocate all this within the framework of one project so that there are no intersections in the commits?
Those. on layout, committees go on their own, and if it is necessary to correct the logic, then it immediately goes somewhere nearby.
Do not copy the project to a separate repository, then it will be difficult to maintain the code in two places at once.

Answer 1

1. Git has a subproject system, but somehow it doesn't work in an intuitive way or automatically. Don't forget about subprojects. They don't commit themselves.
2. You can use an assembly (for example, grunt). This option seems to me more preferable, even though it's not git. You can have several subprojects in one git project, store everything in one repository, and build the one you need for release.
3. Select your core as a project for bower, put it on a resource (gitlab/github). Updating kernel versions in projects is carried out accordingly through bower. Then projects for sites can be kept in two separate repositories 1 and 2. (In total, you will have three repositories. The 3rd one is for the core). And even changing the kernel will not greatly affect projects regardless of changes in the kernel, as it would be in the first two options, where you would have to coordinate all subprojects when changing the kernel version and this would be the most unpleasant job, to change something when The 1st project has already been delivered (i.e. if you changed the kernel version, then you need to update all projects at once, but this will not happen with bower). - I think this option is generally perfect! - I'm for this option. The relationship between the repositories is as follows:

Answer 2

I red-eyed somehow for a whole week for something like this)
1. In the current project (project A) that already has a decent number of commits, I decided to allocate a common branch for similar purposes.
I did a rebase of the entire history according to this principle
, threw all common changes (not the fact that this is a separate commit) into the common branch, and merged these changes into new_master
, threw everything else into new_master,
then simply transferred master to a new branch
Hellish work, but since the project was completely covered with tests did not break anything
Now the approach is all common features in common, and then merge with master
2. Next, I created a new repository (project B) in it only one common branch
in the local (project A) added another remote project B
Now I send all pushes only for the common branch to two repositories
3. If a new project (project C) is needed,
I clone project B and change origin to project C,
but with the common branch everything is the same.

Answer 3

use composer to build the project, the core will be in the form of a separate git repository

Answer 4

Look at git subtree, for example: here .