Contributors' tips, tricks and how tos

We follow C4 = Collective Code Construction Contract. It is a process that emerged with Pieter Hintjens leadership in ZeroMQ community.

• Distilled process
• Process with some explanations
• Some more context

---

Dev flow

Paths to contribute

There are a few paths to contribute:

• when there is an issue (problem) already agreed by the team that needs to be solved - follow C4 process (clear criteria for a solution and code quality should already be there), with optimistic merge and no judgement.
• when there is no issue yet but you know the solution - submit an issue, collaboratively refine criteria for a solution, discuss your idea if you'd like to, and then follow C4.
• when someone wants to submit a proposal, in that case we discuss on a PR, refine and collaboratively decide (vote?) whether to merge or not. Try to avoid this.

Working with remotes

https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes

# check remote repos
git remote
git remote -v

# adding remote repo
git remote add <remote alias> <url>

git fetch <remote alias>
git pull --rebase <remote alias>
git push <remote alias> <branch>

git remote remove <remote alias>

General thoughts

Adding here as for the moment.

How can I easily see the changes?

• without opening ide, in the browser
  • should we auto-deploy each PR somewhere?
• in my IDE, to play with the code
  • since it is not a branch, can not fetch and switch, need to update upstream

---

Keeping the repo in synch with upstream

Mikael does great job with maintaining upstream repo. Keeping both in synch allows us to avoid a lot of work.

To rebase forked repo onto upstream to preserve linear history (be careful when some contributors may have local changes!):

# Add the remote, call it "upstream":
git remote add upstream https://github.com/whoever/whatever.git

# Fetch all the branches of that remote into remote-tracking branches
git fetch upstream

# Make sure that you're on your master branch:
git checkout master

# Rewrite your master branch so that any commits of yours that aren't
# already in upstream/master are replayed on top of that other branch:
git rebase upstream/master

# You may need to force the push to your own forked repo on GitHub
git push -f origin master

Accept 'theirs' for package-lock.json to skip complicated merge.

You may need to force update package-lock.json afterwards:

npm install --package-lock

After forced push, others need to reset their local repo to match the remote

git switch master

git fetch

# to reset without preserving local changes
git reset origin/master --soft
# to reset while preserving local changes
git reset origin/master --soft

---