REBASE ONTO DEVELOP UPDATE
REBASE ONTO DEVELOP CODE

When it's time to update your branch, like you wish to do now, you can use: git checkout myBranch Git switch -c myNewBranch origin/develop -no-track Instead you can regularly use git fetch to update your 'remote tracking branches' (those that start with origin/*) and then you can create all of your new branches from origin/develop instead, like this: git fetch Note, I personally recommend not using develop anymore for this very reason- because it goes out of date quickly and you'll surely forget to keep updating it. After doing that you can then merge develop into your branch to bring in the desired changes. Usually people update their own copy of develop by doing something like this: git checkout developĪnd at that point your local copy of develop will be the same as your copy of origin/develop which will be the same as the remote version of develop. Git merge develop just gives me an 'Already up to date' message. This is why when you tried to update myBranch by merging in develop it didn't work, as you explained: The next thing to understand is your local branch develop doesn't stop pointing to it's tip commit until you tell it to. This is why the concept of 'parent branch' doesn't exist in Git. So it's better to think, 'I created myBranch from commit X.' Or, 'I created myBranch from develop when develop was pointing to commit X.' It's actually the commit X that matters, not develop. In Git though, branches are just pointers to a commit. You used the term 'parent branch' to mean develop because that's the branch you created your branch myBranch from, which makes sense in 'English'. However, if you’re not fully comfortable with git, then I recommend buying the Git Workbook and working through all the exercises.There are many terms in Git that are confusing, and though it's obvious what you mean from your question, based on the discussion in the comments I think it's important to get the proper terminology. Being asked to rebase your PR isn’t scary or (usually) difficult as long as you pay attention to what you’re doing. Add this file to the staging index: git add.Once all conflicts in the file have been fixed, exit your editor.Press find-next in your editor to find the next conflict in the file.$ git status will show you which files are in conflict. This will rewind all your commits on this branch and then replay them against the tip of the branch you are rebasing against.Īs you have been asked to do this, you’ll get conflicts. $ git checkout feature/validator-result-interface The next step is to change to your branch which is the other branch listed in the PR details ( feature/validator-result-interface in this example) and then perform a rebase: $ git pull upstream develop & git push origin develop The target branch in this example is develop, though I see master a lot too. The target branch you want to update can be found at the top of the PR on the GitHub site. I assume you already have an upstream repository as described in The beginner’s guide to contributing to a GitHub project.

REBASE ONTO DEVELOP CODE

The maintainer means that there have been other code changes on the project since you branched which means that your branch cannot be merged without conflicts and they would like to you to sort this out. A maintainer looks at the code and asks you to rebase your PR so that they can merge it. You’ve successfully created a PR and it’s in the queue to be merged.

Rebase onto develop