![]() ![]() One habit that I have that I find that helps a lot with minimizing confusion and conflicts when dealing with remote public branches is that I always only submit one single commit with my pull/merge request. □□□ strong personal opinion disclaimer □□□ Managing your commits – the case for single commits If you decide to keep going, it’s a matter of resolving the conflicts in your code editor, adding all changes (with git add no need to create a new commit!) and telling git to continue with the rebase process: There are times when you try to rebase and you will get a warning that there are files with conflicts.Īt this point you will notice that your branch is in “detached” mode: it’s waiting for instructions on what to do next and you must pick one of the two options: resolve the conflicts and continue the rebase with –continue or abort the operation with the –abort flag. Merge branch 'super-cool-premium' into 'main' When my super-cool-premium gets merged to main later on, the main branch history will look like this: Git rebase -onto origin/main is telling git to update my local “super-cool-premium” branch by bringing the latest changes from main and applying my changes on top of it. In this case I use the –onto variant of the rebase command in my “super-cool-premium” branch: Now my local “super-cool-premium” branch needs to reflect that change also: I want to make it look like as if I had branched directly from latest main (without getting into much detail here, this is good because it makes the history look cleaner). Meanwhile my colleagues approved my pull/merge request from “super-cool” and those changes are now merged to the main branch. Now I have all the super-cool changes and can add the premium changes I want. ![]() There are other ways to solve this (like cherry-picking, for example) but what I usually do is to create a branch from the “super-cool” branch: If I create a branch from main, the required code won’t be there. I send this change for code review and I want to start working right-away on adding another feature that depends on the super-cool feature that have not been merged to the main branch yet. I create a local branch “super-cool” from the main branch and add my changes to it. You can continue working on your super-cool feature or just push your local to the remote (for code review, I hope! □) get those latest changes from main and 2. This is the most simple case and all I need to do is to 1. While I’m still working on it OR if I’m ready to send it to code review, I find out that there’s one important bug fix in the main branch and I need it on my local branch too. I created a local branch directly out of the main branch so I can add my super-cool feature. In both cases the “main” branch received updates and I need those updates in my local branch. ![]() I often run into 2 different cases that will determine how I use git rebase:ġ- my local branch was created from the main branch (a “child” branch)Ģ- my local branch was created a from a branch that was branched from main (a “grandchild” branch) The reason for this recommendation is because of how git rebase works – which I will not get into here but you can watch this short video. Treat rebase as a clean up tool for when you are getting ready to open a merge/pull request. Only rebase your local, non-shared branches. You should not use git rebase on a shared branch (say a main or dev branch). ![]() In other words, you want to use git rebase to make sure your work is up to date with all the changes from the main branch and ready to be reviewed and potentially merged. You want to use git rebase when have a local branch with changes (for a bug fix or new feature, for example) and the main branch (the one you created your branch from) received updates and you want those updates in your local branch too, along with your changes. Git rebase is the tool used to combine changes from one branch into another branch. There are many ways to accomplish this but I personally like to use git rebase. And by “easily” I mean preferably without merge conflicts or the dreaded message “your branch is xxx commits behind the target branch”. When you work on a codebase with other people, you need to manage your local branches: you need to ensure that when you push some code and create a merge/pull request on the remote branch, your changes will be easily integrated with the main codebase. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |