github fork update workflow

gihub-fork-update-workflow.md

Stage 0: git setup

workflow assumptions

• The upstream project has a develop branch from which feature branch are created.
• Feature branches can be long lived
• I have not commit right on any branch on the upstream project
• I forked the upstream form Github web interface
• I have clone my fork on my local development envirnment
• To submit my changes I create a Pull Request for the upstream develop branch.
• My local development environment is a macOS X system

enable git rerere

If the feature branch is long-lived, several rebase from develop may be needed. Conflicts may emerge. If using rebase, where feature related changes are replayed, these conflicts will keep re-occurring every time. Use git rerere to have git remember how a conflict was solved the previous time it occured.

$ git config --global rerere.enabled true

add upstream remote

before adding upstream, the output of git remote -v may look like this

$ git remote -v
origin	https://github.com/rija/project.git (fetch)
origin	https://github.com/rija/project.git (push)

then add upstream remote:

$ git remote add upstream [email protected]:client/project.git
$ git remote -v
origin	https://github.com/rija/project.git (fetch)
origin	https://github.com/rija/project.git (push)
upstream	https://github.com/client/project.git (fetch)
upstream	https://github.com/client/project.git (push)

Stage 1: Update my develop branch from upstream's develop branch

$ git checkout develop
$ git fetch upstream
$ git rebase upstream/develop
$ git push origin

Stage 2: Update my feature branch from the develop branch

$ git checkout my-feature-branch
$ git fetch origin
$ git rebase develop
$ git push origin

Stage 3: In case of merge conflict

Looking around the conflict

See which files are in conflicts:

$ git ls-files -u
100644 9b42055da84e099659ee6246fb9f5bdb1f034de6 2	tests/behat.yml
100644 d1a9a1ebbe16aa2f7f57c23b4fd57ec906446aa7 3	tests/behat.yml

See what are the conflicts

$ git diff --diff-filter=U
diff --cc tests/behat.yml
index 9b42055d,d1a9a1eb..00000000
--- a/tests/behat.yml
+++ b/tests/behat.yml
@@@ -3,7 -3,7 +3,11 @@@ default
      features:  features
      bootstrap: features/bootstrap
    context:
++<<<<<<< HEAD
 +      class:  'MyMainContext'
++=======
+       class:  'AuthorWorkflowContext'
++>>>>>>> Author-names (#81): setting up test infrastructure
    extensions:
      Behat\MinkExtension\Extension:
        base_url: 'http://lvh.me:9170/'

The number :2 or :3 from the output of git ls-files -u represent the branch identifier. There is sometimes a :1 too. They can be thought as "ours", "theirs" and HEAD. (But the mapping order differs depending on the merging method used). To show the conflicted files from on those three branches:

$ git show :2:tests/behat.yml
$ git show :3:tests/behat.yml

fixing the conflict

in case where the fix is about accepting one of those 3 versions, here is how you accept a version and move on. (Let's say we want to accept the version from :2)

$ git show :2:tests/behat.yml > tests/behat.yml
$ git add tests/behat.yml

If the fix is not that simple, do whatever is necessary and then use git add to signal conflict resolution.

git rebase --skip or git rebase --continue ?

This depend on whether the replaying patch needs to be applied or not once the fix has been made.

The conlicting patch can be consulted in .git/rebase-apply/patch

If the patch still matters, use git rebase --continue. If the fix makes the patch redundant, use git rebase --skip.

some error messages encountered

CONFLICT (content): Merge conflict in Behat/composer.json
warning: inexact rename detection was skipped due to too many files.
warning: you may want to set your merge.renamelimit variable to at least 8522 and retry the command.