CODEWITHSUNDEEP
git
Maxime Fabre
Maxime Fabre

Reputation: 2252

Rebase from commit

I have a framework that I coded, it's into a Github repository, as the master branch. Into that branch are only the core files of the framework, so I named it the core branch. Now into other branches, I list projects that use said core framework — I did this because I though working with branches would be easier but as I just discovered, it's not. Seriously.

So to sum up : I have a core branch, and a project branch that uses that core. Now on the project branch, I do mostly commits related to the project (added image X, modified stylesheet Y) but sometimes I modify the core, to make it better.

Now what I'd like to do, and again I thought this would be simple, is when I start working on the core more than the project, merge the changes to the core into the core branch. There's several solution and it's all starting to confuse me, and since I would like not to mess up my core branch, how should I proceed ?

I know I can cherry pick commits and push it but I'd really like to keep the history of changes to the core files, so I've been directed to rebasing. Problem is : if I rebase my core branch to a specific commit on the project branch, it will push all the files and stuff that have nothing to do with the core. So how do I rebase from a certain commit (and not to, which seems to be the default ?).

Here is some sort of idea of what commits on the project branch might look like :

project branch

00:12 - Added image X
00:14 - Modified stylesheet Y to have a pink background (pink is pretty)
00:16 - Modified class core.background to handle pink background
00:18 - Modified class core.string to always capitalize Pink (because it's so pretty)

How do I merge the last two commits into core branch without merging the two first one that were project-related, and by keeping history — ie. keeping those two changes to the core as two commits and not one ?

Edit : more precisions. My core framework defines a project's folder organization and thus needs to be at the root of the project folder. That's why it's not a submodule, which would have been the dream. Also, I tried a fork of the core, but apparently you can't fork your own projects.

If there is another way besides branches to do what I want, I'm all ears.

Upvotes: 0

Views: 88

Answers (1)

simont
simont

Reputation: 72677

git branches don't really work like that - the branches all relate to the repository. Separating projects, or parts of projects, into separate branches isn't really the right way to go. Eventually, most branches should be merged into a release branch of some type, or discarded.

I have a core branch, and a project branch that uses that core. Now on the project branch, I do mostly commits related to the project...

I'd really like to keep the history of changes to the core files [separate]

From that, I think it sounds a lot like you have a good use case for two separate repositories, one for core-files and one for project - you want to keep the history of core and project separate. Rather than keeping them in the same repository in different branches, I'd advocate pulling the core-files into a git submodule of projects. That'd give you several advantages right off the bat:

  • project and core history are separate.
  • Using core with another project is very simple; import core as a git submodule of the otherproject.
  • The history of both project and core is much, much easier to maintain, because you're not having to cherry-pick between branches anymore.

Upvotes: 1

Related Questions