So I use gitkraken most of the time to streamline my workflow. In my project, I combine 3 “layers”, each with its own origin repo on my github. There’s a portability layer, the framework itself, and the application, where each repo includes files and history from every layer below. I was hoping to be able to have a workflow where I could make changes to all 3 freely when the application branch is checked out, checking out other branches and committing & pushing the relevant files to each one starting from the bottom, merging each one as I go up the hierarchy. But I found that in GitKraken this does not go as smoothly as I expected. I am not allowed to checkout the remote branch at all, citing conflicts, and am forced to stash. When I apply the stash on the other branch many “not sure what to do” messages are reported when checking out the bottom branch after doing a bunch of work within the application branch and the easiest thing to do is mark all as resolved, stage everything and one by one discard the irrelevant files. Then I have to repeat this process 2 more times. These leads me to wonder if I am going about things wrong?
I’m sure that someone else in this community could explain things better than I can, but Git branches don’t really work like layers in Photoshop or other image editing software. While you can have a separate branch for each of the parts of your application and then merge them into Master individually, you can’t work on them fluidly without at least commiting what you’re working on at a time.
Have you taken a look at the GitHub Flow guide? It might be too simple for your workflow, but I think it does a good job of explaining how branches work within Git and what you would need to do to get a system like you’re looking at to work.
Hmmm. I use Git Flow at work, maybe I should be applying that here. I guess every time I want to change something in another layer I just need to checkout first. I wish it could be more fluid, but I suppose doing this necessitates writing self-contained test code to make sure things work *before* using them, but this is actually a paradox because the application I’m writing is intended to BE the test code for development of the framework and the portability layer (which I actually call a “kit”). It’s all very confusing when you are working on something that’s intended to be self contained yet contains three distinct parts that each depend on the one below.
Maybe I can do this? Instead of using remote branches all the time, I create a 4th repo, and make all 3 parts local branches. Then they will be related, and it’ll be easier to checkout and commit things? Then I push those branches to the other repos… somehow.