Update behaviour docs

Separate branches
Out-of-date PRs

docs/behaviour.md

@@ -35,6 +35,24 @@ The following options apply globally:
 
 - Log Level
 
+## Separate Branches per dependency
+
+`renovate` will maintain separate branches per-dependency. So if 20 dependencies need updating, there will be at least 20 branches/PRs. Although this may seem undesirable, it was considered even less desirable if all 20 were in the same Pull Request and it's up to the users to determine which dependency upgrade(s) caused the build to fail.
+
+However, it's still possible to override the default branch and PR name templates in such a way to produce a single branch for all dependencies. This needs to be done via configuration file. Here's an example configuration:
+
+```javascript
+templates: {
+  branchName: () => 'renovate-all',
+  prBody: () => 'This Pull Request is for package.json updates generated by the renovate utility.',
+  prTitleMajor: () => 'Renovate dependencies',
+  prTitleMinor: () => 'Renovate dependencies',
+  prTitlePin: () => 'Renovate dependencies',
+},
+```
+
+Perhaps it could be useful to make this a directly configurable option in future.
+
 ## One PR per Major release
 
 `renovate` will create multiple branches/PRs if multiple major branch upgrades are available. For example if the current example is 1.6.0 and upgrades to 1.7.0 and 2.0.0 exist, then `renovate` will raise PRs for both the 1.x upgrade(s) and 2.x upgrade(s).
@@ -56,3 +74,13 @@ Note: Branch names are configurable using the `templates` field.
 
 By default, the script does not create a new PR if it finds an identical one already closed. This allows users to close unwelcome upgrade PRs and worry about them being recreated every run. Typically this is most useful for major upgrades.
 This option is configurable.
+
+## Rebasing/updating Out-of-date Pull Requests
+
+It's often the case that dependency updates can't be merged immediately, and lag behind the base branch. It's also possible that even when updates are merged quickly, they cause merge conflicts with each other and require manual conflict resolution.
+
+Right now, `renovate` doesn't do anything about these, although it keeps adding commits if new releases of the dependency are available. It's also important to note that rebasing and/or resolving conflicts in existing branches is not technically possible via the GitHub API.
+
+Possible future behaviour:
+- It seems undesirable for most to keep rebasing renovate pull requests every time the base changes. This would cause a *lot* of CI builds in most cases
+- It seems desirable to "fix" an existing renovate PR if it is no longer mergeable