Menu
So I'm working on a project that sometimes has long build times, and the build is clobbered very often. If I have an older branch with some work going on (which has been committed, but is based on an older parent), running git checkout oldbranch changes the working dir to represent all the old code, which makes me need to run a full build again.
However, usually I've only modified one or two files, and the rest don't need to be reset. What I'd like to do is to rebase this branch to the current master head, and preserve those changes to the files.
Basically, if a.rs and b.rs have been modified, then I need a way of making these changes base themselves onto the current head, without touching any files other than those two.
Is there a git-ish way of doing this? Currently I'm juggling patch files to do this.
613
It is best practice to always rebase your local commits when you pull before pushing them.
If you use pull requests as part of your code review process, you need to avoid using git rebase after creating the pull request. As soon as you make the pull request, other developers will be looking at your commits, which means that it's a public branch.
Rebase is another way to integrate changes from one branch to another. Rebase compresses all the changes into a single “patch.” Then it integrates the patch onto the target branch. Unlike merging, rebasing flattens the history because it transfers the completed work from one branch to another.
Going through the same right now I learned git rebase allows you to specify two branches in one go, essentially making it git rebase <remote> <local>, eg.
git rebase origin/master dev This performs a more efficient rebase where your files don't get all re-written (which is the case if you checkout the branch first). You still need to resolve merge conflicts first and you end up with a repository where your local dev branch is checked out.
158
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
