A busy time for completing the BP doc

Hi all-

we're entering the last few days of allocated time for changes to the BP
doc. We have quite a few people working in the doc - and not always in
discrete, well-contained sections.

To make it easier to merge PRs, please can you "rebase" your local repo
before submitting your changes - if there are any merge conflicts, you'll
need to deal with them locally.

That said, you can often avoid merge conflicts by regularly fetching from
the main repo and rebasing ...

Fetch just gets all the changes.
Rebase plays your new changes on top of ones from the fetched repo (and
avoids lots of unnecessary merge commits)

(assuming "upstream" is the w3c/sdw repo), the following git commands are
all you need:

> git fetch upstream
> git rebase upstream/gh-pages

FWIW, I've included below some notes that I took when a colleague of mine
(thank you Mark Hedley) helped me resolve a local merge conflict.

Jeremy

*How to deal with merge conflicts in Git*


remote repository: upstream

branch: myBranch

working file: index.html


so- you’ve done a rebase which has thrown up a merge conflict …



   1. > git status … check what has gone wrong; you should see some
   red-flagged files where the conflict occurs
   2. manually fix & save the file; the working copy of the conflicting
   file will have “>>>>>>” to mark the places where there are issues ...
   when you're finished, the ">>>>>>" should also have been removed
   3. > git add index.html … tell Git that this file is ready for
   re-inclusion in on-going rebase
   4. > git status … everything should be green now
   5. > git rebase -- continue … continue the rebase; if more merge
   conflicts are found, go back to step #1
   6. > git log … once all the conflicts are resolved, have a look at the
   commit log just to check all makes sense
   7. > git push -f upstream myBranch … force push your changes to the
   remote repository; you need to force, because you’re actually changing the
   Git history as a result of replaying your changes after someone else’s - so
   the commit SHA refs change; specify the branch to minimise the downside of
   doing anything wrong - this way you don’t accidentally destroy the history
   on, for example, the main branch