![]() Who cares about a bit of chaos in the git history? The Pull Request wasn't done yet and we could continue fixing conflicts with more merge commits. I could have just given up and not rebased. Wes already fixed most of the conflicts when he merged main into layout-tweaks those 4 times. The merge commits actually made it possible to merge the layout-tweaks branch into main. Looking at the Pull Request on GitHub I was greeted with a big green merge button. The chance that I would make a mistake in the process was too big. With so many commits and merges, it no longer seemed possible to rebase this branch without manually resolving all the conflicts. This way we're actually rebasing more commits than only those on your feature branch.įor layout-tweaks it jumped from 93 commits to more than 200. When you merge the main branch into a feature branch with a merge commit, you also bring in the main branch's new commits. The main branch was already merged into the layout-tweaks branch 4 times with a merge commit. When I rebased and squashed the layout-tweaks branch, something interesting happened I still ran into a lot of conflicts. Normally, this strategy is a nice way to save yourself a headache by squashing first and rebasing on new changes after. With fewer commits and less potential conflicts we can then rebase on the changes in the main branch. Now that we're able to only rebase the changes in our own feature branch, it's a lot easier to squash commits. $ git checkout layout-tweaks $ git rebase -i 945369734b4ca9fcee6cb88e6283fb7f9c52b304 # Squash commits into 1/a few Luckily we can ask git with the git merge-base tool. When your git history looks a bit like in the tweet above, it can be a bit difficult to find the original branch off point. I fucked up Git so bad it turned into Guitar Hero This way you can rebase and squash before you have to resolve conflicts against new changes on the main branch. I prefer to rebase and squash on the commit a feature branch was started from, the branch off point. Squashing commits can help with reducing the amount of merge conflicts. ![]() However, lots of commits will also increase the chance of more merge conflicts. Committing often is a good habit for anyone who uses git. Wes designs in the browser and commits often to keep track of his changes. After a couple commits fixing the same issues over and over again I tried another approach. If there are changes that overlap between main and your feature branch, git will prompt you to resolve the conflicts before it can continue.ĭuring my rebase of the layout-tweaks branch I had a lot of conflicts to resolve. If the changes between main and your feature branch are unrelated git happily rebases your feature branch for you. $ git checkout main $ git pull origin main # get new changes $ git checkout layout-tweaks $ git rebase main ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |