I guess this is, strictly speaking, more of a git question than a SourceTree question but it's framed on the SourceTree History view.
I'm the new guy where I work, and there doesn't appear to have ever been a regular adherence to any known source code management regimen here. But I'm trying to figure out how we got in the boat we're in today.
For the most part, whenever people check in, they check in to master. There's one guy (who left a few months ago) who apparently would branch and merge but he appears to be the only one.
Anyway, with everyone checking in and pushing to a master remote on github, somehow about a year and a half ago "master" appears to have bifurcated in SourceTree's history view
No real indication of a conscious branch being made. Other than those 2 blue dots in the lower third of the picture, all other commits by all other people for the next year and a half show up on the red line (with occasional bump-outs by that 1 guy who actually used branches intentionally - but always merging back to the red line.
Then a week ago, someone did a check-in and this resulted:
No merge operation (despite the red elbow there). All the commits on the red line over the last year and a half are just dead-ended.
You can view each one of those commits if you highlight them, but they are none of them considered part of the main line. If you browse the file hierarchy in github, the last year and a half of work appears lost.
A) I'm wondering how / why the red line exists when everyone here has been committing and pushing to master the last couple of years. When you look at the list of known branches, master is the only one.
B) I'm wondering how the guy who did the top quarter of check-ins did them in such a way that completely ignored everybody else's work for the last year and a half. (Everybody says they just use the github desktop app with no special flags or anything - and that they don't remember). If you do a merge operation, the stock comment format says "Merge..." but there's none of that here. There are no pull requests and/or branch deletes. Could this guy have done a rebase or something with his push that just forced his year-and-a-half old view as the top line?
C) I'm wondering how to fix this. I don't want to have to process all 200 or so commits individually trying to merge them back into the main line.
Any help understanding how this happened and how to untangle it would be appreciated.
Doing more googling, could this be the result of of a detached head?
I'm still a little hazy on the concept, and I'm trying to figure out how this result can come out of a dozen people all thinking that they're committing and pushing to the master branch.
The cleanest theory I can come up with was that the guy who checked in last week had somehow gotten himself in a detached head state (probably a long time ago) and his push back to master dragged things off the rails.
I mean about a dozen people checked into the red line over the last year and a half, and up until last week a dozen people had a shared view of what the master line was.
It seems Occum's Razor to think it was the 1 guy and his commit last week that broke things than somehow a dozen people interacting over that time.
I'm just trying to sort out exactly what he did.
It doesn't seem like a detached head issue. At least the detached head fixes I've read about don't fix it.
I've tried going back to that commit in the second screen cap, checking it out and branching it, then trying to merge it back to master (the routine suggested for fixing detached heads), but that only results in all the changes on that red line being lost again.
I'm trying to cherry pick the changes since the repo got fubared into that branch but I'm running into a known issue where cherry pick in SourceTree doesn't work.