Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

...

...

...

Table of Contents

...

Audience

This document is intended for full-time developers, community contributors, and projects managers who all need to understand the details of how to use Github effectively in the RChain Cooperative's environment. Full-time developers and other contributors must follow these guidelines to the extent possible.

...

If you're picking up someone else's pull request, then whatever you do must preserve the commit history. If you can accomplish that by rebasing off someone else's PR, then great. If you need to merge the PR and then create a new PR, then that's also fine. Merging a broken PR and then fixing it "later" is the least preferable, but there are situations where this also works. E.g., if the "fix" is already implemented and will be merged almost immediately.


Please do NOT:

  • Please do not close PRs when there are new changes which result in conflicts. You can add changes and resolve conflicts by merging or rebasing.

The

...

basics of

...

forking

The RChain Cooperative has a variety of repositories under https://github.com/rchain and at various times you may be required to contribute to each of them. This is a simple git workflow that keeps all your work on branches in your own fork of the repository. In the general case, no one ever pushes to rchain/rchain, which keeps our shared repository clean. All git workflows require diligence to maintain good hygiene around branching, issuing pull requests, and merging. The main rules to keep in mind for this one are:

...

Lucidchart
autoSize0
macroId2b113004-cc29-440b-b5c8-ca9049f496a8
pageCount1
instanceId7bf7a548-f937-390d-b7ee-64c4940fe12e
width900
documentId532e2983-c399-4429-bac2-22a254a5d7d2
alignleft
typerich
updated1508040988533
height400


...

Example

...

process

Setup

Make a personal fork of rchain/rchain on github; my user is kirkwood, so I forked to kirkwood/rchain. On your development machine, clone your personal branch (kirkwood/rchain for me) and add rchain/rchain as a remote called upstream.

Code Block
languagetext
themeEmacs
titleClone & Add Remote
<dev:~/src> git clone git@github.com:kirkwood/rchain
Cloning into 'rchain'...
remote: Counting objects: 2100, done.        
remote: Compressing objects: 100% (24/24), done.        
remote: Total 2100 (delta 10), reused 34 (delta 7), pack-reused 2058        
Receiving objects: 100% (2100/2100), 1.52 MiB | 10.25 MiB/s, done.
Resolving deltas: 100% (791/791), done.
<dev:~/src> cd rchain
<dev:~/src/rchain (master)> git remote add upstream git@github.com:rchain/rchain
<dev:~/src/rchain (master)> git fetch --all
Fetching origin
Fetching upstream
remote: Counting objects: 316, done.        
remote: Compressing objects: 100% (89/89), done.        
remote: Total 316 (delta 89), reused 198 (delta 69), pack-reused 87        
Receiving objects: 100% (316/316), 71.69 KiB | 1.79 MiB/s, done.
Resolving deltas: 100% (100/100), completed with 23 local objects.
From github.com:rchain/rchain
 * [new branch]      dev                      -> upstream/dev
 * [new branch]      dev-kent-arithmetic-test -> upstream/dev-kent-arithmetic-test
 * [new branch]      dev-kent-move            -> upstream/dev-kent-move
 * [new branch]      master                   -> upstream/master
<dev:~/src/rchain (master)> git remote -v
origin	git@github.com:kirkwood/rchain (fetch)
origin	git@github.com:kirkwood/rchain (push)
upstream	git@github.com:rchain/rchain (fetch)
upstream	git@github.com:rchain/rchain (push)

Feature

...

branch

Create a new branch, tracking upstream/dev (in other words, branch off of dev in the main rchain repository). Here I'm working on Jira issue CORE-23:

...

See How to sign commits to rchain/rchain for information on how to sign your commits.

Pull

...

request

Issue a pull request on Github from your newly pushed feature branch to dev. Not to master, to dev. Github may try to trick you.


Keeping

...

up-to-

...

date and resolving merge conflicts

Sometimes, once you've created a pull request, things will happen in the upstream repository before you get a chance to merge. This can cause your local code and your fork to become out of date with the upstream repository. Some people are tempted to do a rebase at this point. Do not give in to the dark side of the git. You are going to have to fix the merge conflicts one way or the other. You want to fix them as the result of a merge command, not as the result of a rebase.

...