The Linux kernel goes through several "release candidate" or "-rc" versions for 6-8 weeks until it is stablized. After the stable kernel is released, the "merge window" opens where maintainers will send pull requests to Linus for him to pick up new patches. Once the first release candidate is published (-rc1), only bug fixes can go into the kernel.
In order to prepare for the merge window far in advance, kernel subsystem maintainers often keep a "-next" tree. This stores all the patches that will be sent to Linus during the next merge window. Maintainers' "-next" trees are pushed into the "linux-next" tree, where maintainers make sure their subsystems don't add conflicting code changes. The "linux-next" tree is rebased all the time, and is generally not an easy tree to work with.
Instead, we recommend creating patches directly on top of the subsystem maintainer's -next trees. In this example, we'll work through adding the staging-next tree as a remote, and rebasing any patches on top of the tree.
git remote add staging git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
git fetch staging
3. Now, if you run git remote -a, you will see lines that indicate you have a remote named staging, and it has branches called "master", "staging-linus" (fixes for the current -rc), and "staging-next" (patches queued for the next kernel version):
$ git branch -a | grep staging remotes/staging/master remotes/staging/staging-linus remotes/staging/staging-next
git checkout -b staging-fixes-rebase
git rebase staging/staging-next
You may need to clean up any code conflicts, so that your patches apply cleanly against the staging tree. This page might help explain how to do that (although in your case, you have a merge conflict due to a rebase, not from a merge commit).
When do I want to rebase again?
Occasionally, you may want to update your git repository against the latest -next version. Usually you want to make sure you rebase your tree before you start working on a new patch, in order to make sure your change isn't already in the -next branch. However, that can be problematic if you have patches under review in your current branch. If your new patches depend on your old patches (meaning they apply to the same driver files), you shouldn't rebase until the previous patches have been applied (when you get an automated email from Greg saying it was applied).