I have a branch `develop`, and branched a big feature called `next` from it.

In `next` there is a continuous process of editing files that are originally from `develop`, and files that are created new exclusively in `next`.

TL;DR: You can skip the next section and go to the question directly.

---

(a) The changes in `next` on files that were inherited from `develop` are always backwards-compatible and are always committed there (too).

(b) Meanwhile, `develop` itself is also undergoing development, and these changes should also be visible in `next`. Therefore, `next` is rebased on `develop` every now and then.

Committing back to `develop` causes merge conflicts because (b), and rebasing causes merge conflicts because (a). The latter can be fixed by `-X theirs` because the conflicts were already resolved in the first step.

But this is not efficient.

---

**Is there a way to automatically:**

1. Commit files that were originally from a parent branch to the parent branch (e.g. `develop`)
2. Commit files that do not exist on the parent branch to the current branch (e.g. `next`)
3. Rebase the current branch upon the parent branch to bubble up the changes?

---

**Possible complex solution**

I can imagine that some 'simple'(r) git-foo is possible because this wish is not unique. But if not, some `bash` scripting might be possible. For example, the following command:

```
git ls-tree -r develop --name-only

```

will show a list of files that were indeed in `develop`. Files not in that list would be only in `next`.

I guess if all else fails, I could create a shellscript to:

1. First commit all files that exist on `develop` to `develop`
2. Then commit all other files to `next`
3. Rebase `next` on `develop`

But it's not as simple as it sounds.