![]() You can use this to get back stuff you accidentally deleted, or just to remove some stuff you tried that broke the repo, or to recover after a bad merge, or just to go back to a time when things actually worked. # each one has an index find the one before you broke everything # you will see a list of every thing you've ![]() Oh shit, I did something terribly wrong, please tell me git has a magic time machine!?! git reflog So here are some bad situations I've gotten myself into, and how I eventually got myself out of them in plain english. ![]() Git documentation has this chicken and egg problem where you can't search for how to get yourself out of a mess, unless you already know the name of the thing you need to know about in order to fix your problem. * FeatureÄon't be affraid of rebasing or merge conflicts.Git is hard: screwing up is easy, and figuring out how to fix your mistakes is fucking impossible. Once Refactor is merged into main rebase Feature onto the merge commit, this leads to a semi linear history with features visible and small commits that tell a story about why the code is as. | * tmp/feature-base: this commit is no longer is the refactor branch but it is in the history of Feature * Main: new changes both branches should have these * Refactor.Main: before starting refactoring Graphically from: * Main: new changes both branches should have these ![]() Git rebase tmp/feature-base -onto refactor Make sure to remember the hash of the base of feature (on create a tempoeary branch for it): git branch tmp/feature-base feature.refactor * this was the common base now it's just a commitįor changes in Main you rebase in two steps first Refactor onto Main then Feature onto the moved Refactor. * Refactor: new changes feature should be rebased on these * Fearure.Refactor (common base of Feature and Refactor) From: * Refactor: new changes feature should be rebased on these Git rebase refactor.feature -onto refactor Given new changes in refactor do: git switch feature You can also move the commits from refactor that you need in feature to the base and first merge those into main rebasing refactor and feature on the merge of those changes. Use git rebase to move the branches (refactor and feature) when work happens on the other branches (main and refactor) and finally when refactoring is merged. So while it is possible to branch off of your refactoring branch, I'd evaluate whether you really want to do that, or focus on wrapping up the refactoring first. ![]() If this is truly a refactoring, adding in new features can complicate the determination that the refactoring was successful (is a bug due to the refactor or the new feature). Given all that, I'd caution about having such a long-lived branch ( refactor) that you are doing other development on ( feature2) at the same time. Given your use-case though (the feature depends on the work you're doing in the refactoring) this may be unavoidable. When you start changing the same functions in the same files on the two branches, that means conflicts. In order for the feature2 PR to be as clean as possible, the changes you make in feature2 should be completely unrelated to the changes you're making in refactor. Your PR from feature2 into refactor will only reflect the diffs between those 2 branches, but when you open a PR from refactor into main you will get see diffs from feature2 as well - something to keep in mind for whoever is reviewing. You'll need to regularly pull from refactor into feature2 (in addition to pulling from main into refactor). However, those 2 branches are intertwined now. If your refactor branch is long-lived, and you need to add a new feature based off it the work you've already done, create feature2 off the refactor branch. You can certainly branch off of any branch. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |