Yes, your repo looks messier, but it more accurately reflects the lifecycle of the code, and what the developer intended at each commit. Git rebase destroys the context of the commit, leaving basically a diff apply instead of the much more contextually rich merge commit. This doesn't show up on a smaller repo, but if you have a busy repo, with lots of contributers, untangling a mess becomes much harder if you no longer have the true parentage of a given commit. The problem with rebase is that it corrupts the true history of the commits. Rebasing local history is OK (it's more than OK, it's sometimes necessary to maintain a clean history), but changing other people commits history is considered a bad practice. I DO NOT encourage rebasing remote (public or shared) branches. NOTE: Because of many discussions about this note. To get to the next batch of conflicts (if you have any). If you want to merge a feature branch it might be wiser to actually merge your commits thus having a single point of integration of two distinct branches.Īlso the conflict resolving will be now per commit basis, not everything-at-once, so you will have to use git rebase -continue The command will apply all your yet-to-be-pushed commits on top of the remote tree commits allowing your commits to be straight in a row and without branches (easier git bisects, yay!).įew notes though. To keep the repository clean, your commits always on top of the tree until you push them to a remote server. You actually issuing git fetch + git merge commands, which will result with an extra commit and ugly merge bubbles in your commit log (check out gitk to see them). What you might not know is that by typing git pull (Obviously, it can be a "moving target" if others are checking code into "feature/myparentbranch".When working on a project you usually synchronize your code by pulling it several times a day. and without any "conflict files" listed in the PR. You should only see what is different between your "feature/mychildbranch" and "feature/myparentbranch". git commit -m "Use a meaningful message here"Īt this point, if you create a PR (or open an existing one) that is trying to do a feature/mychildbranch -> feature/myparentbranch Now you need to push your code to remote server. Once they work, continue.Īt this point, you have your local code healthy. If the unit tests are broken.then address the issue(s). If it works, continue, if it does not build.fix it. If there are conflicts, that's a whole new SOF question/answer IMHO.īut to finish out the "complete cycle" (let's say you get the conflicts resolved)īUILD your code. now you can do a commit and push to remote) If there are no conflicts, you should be where you want to be. do a merge from feature/myparentbranch (which you know is local and up to date because of the voodoo above */ * another sanity check, show you're on feature/mychildbranch */ Your branch is up to date with 'origin/feature/mychildbranch'. Switched to branch 'feature/mychildbranch' * ok, now (above) you have the latest-greatest feature/myparent, lets do a checkout on the child to switch to the child */ * do a git branch just to show that you're on feature/myparentbranch */ X files changed, Y insertions(+), Z deletions(-) * feature/blah blah blah (specific to my stuff only) Remote: Total 22 (delta 17), reused 0 (delta 0)ĩ6ae0e9.6eb0a03 feature/myparentbranch -> origin/feature/myparentbranch Remote: Compressing objects: 100% (22/22), done. * now pull, the pull will occur on the branch you are currently on, which should be feature/myparentbranch at this point */ Your branch is up to date with 'origin/feature/myparentbranch'. Switched to branch 'feature/myparentbranch' * now checkout the parent branch.note the "switched" happens automatically with the checkout */ make sure at least feature/mychildbranch exists note the "*" below says "this is the branch i am on" */ Longer version (explained) I'll use /* as comments */ /* first, make sure you at least have the child branch */ Short version: git checkout feature/mychildbranch After merge conflict resolutions (if any), it can be pushed to remote. It will retrieve the 2 branches of interest (freshly/newly retrieved) to local. My approach is that I am going to create a new folder, and put the below calls (in that same new folder).so I know I have only "fresh" code on local (but "fresh" (as possible) from the remote server), ( and 'guarantees' i do not have any accidental local changes).
0 Comments
Leave a Reply. |