...

CoreOS should include an installation of Git. Feel free to play around and become familiar with Git in this environment.

Forking Workflow

Going forward, we will try to follow a "forking" workflow. For comparisons of this workflow to others, see below:

• https://www.atlassian.com/git/tutorials/comparing-workflows/
• https://www.atlassian.com/pt/git/workflows

Here's How It Works

Fork Upstream Repository

The premise is that each developer creates a fork of the nds-org (aka "upstream") source repository.

...

(You did create a GitHub account, didn't you? If not, see *New Developer Workflow.)

Clone from Origin Repository

The developer the can make any create or delete any branches they want on their own personal fork (aka "origin").

...

git clone https://github.com/your-git-username/nds-labs.git
cd nds-labs/
git remote add upstream https://github.com/nds-org/nds-labs.git

Commit Local Modifications

Make sure if you create any new files that you want Git to track, call the following command:

...

An administrator can then review the pull request before merging it in, and may ask you to modify your pull request before they will do so.

Push Committed Changes to Your Origin

Once you have a few commits gathered, you'll likely want to save them indefinitely by pushing them back to your personal fork.

...

It is VERY DIFFICULT to remove things from GitHub.com safely once they are pushed there.

Contribute Back with Pull Requests

When you think you have a change that NDS would benefit from, feel free to contribute it back to our repository at https://github.com/nds-org/nds-labs.git in the form of a Pull Request.

...

In the description, I normally like to link to the JIRA ticket as well, if one exists.

Segment Feature Changes to Different Branches

Case: Mix of Live and Dead Code on the Same Branch

Case: Say you want to make a new addition to the code, so you create a fork and start coding right away.

...

Now you'll have to either manually roll back the additions you have made or do a git checkout or git reset and fix the same bugs again manually.

Avoiding the Same Fate

To avoid this situation, it is recommended to separate each additional feature or fix for each particular bug out to its own branch.

...

NOTE: In general, we tend to name branches after the key of their associated JIRA tickets. For example: NDS-101

An aside: Branch Tracking

It is important to note that whichever branch you are currently on when executing git branch or git checkout -b will be "tracking branch" of your branch.

...

If things go awry, you can always choose to blow away the branch altogether and try again.

Undoing your Last Commit

Locally

If you accidentally commit something you ought not have, but have not yet pushed the commit to your personal fork, run the following command to undo the commit:

...

The ^ tells git to reset to "the previous commit before head." You can chain together multiple ^'s to go back to the nth previous commit, but I would not recommend this unless you know what you are doing.

On Personal Fork

If you have already pushed the change to your personal fork, then you may be out of luck.

...

WARNING: Make sure to have any outstanding Pull Requests MERGED before deleting your personal fork, or your changes may get lost.

Resolving Merge Conflicts

Case: Say you want to make a new addition to the code.

So you follow the workflow described above, create a fork and maybe even a new branch to avoid collisions.

...

(You are creating separate branches for each of your features, aren't you? This minimizes the size of potential conflicts by isolating each set of related changes. See below.

Pull from Upstream

On your local copy, pull from upstream to grab any changes to the upstream repo:

...

Notice the line starting with CONFLICT, which indicates that you will manually need to fix this file.

Locate Offending Conflicts

Open the file in your favorite editor and you should see the conflict(s) surrounded by > and <:

...

>>>>>>> COMMIT SHA HASH indicates the SHA hash of the conflicting commit ("their" modifications)

Resolve Any Conflicts

Edit each file appropriately to resolve the merge conflict(s).

...

.....
        {
            "name": "RABBITMQ_EXCHANGE",
            "value": "clowder",
            "canOverride": false
        },
        {
            "name": "TOOLMANAGER_URI",
            "value": "http://localhost:8082",
            "label": "ToolServer address",
            "canOverride": true
        }
    ],
    "ports": [
        {
.....

Tell Git that you have Resolved the Conflicts

Now re-add any conflicting files to git's index.

...

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
You have unmerged paths.
  (fix conflicts and run "git commit")
Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   clowder/clowder.json
no changes added to commit (use "git add" and/or "git commit -a")


$ git add clowder/clowder.json 
 
$ git commit -a -m "Fixed merge conflict"
[master e09f5a2] Fixed merge conflict
 1 file changed, 1 insertion(+), 1 deletion(-)


$ git push origin master
Username for 'https://github.com': your-git-username
Password for 'https://your-git-username@github.com': 
Counting objects: 4, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 366 bytes | 0 bytes/s, done.
Total 4 (delta 3), reused 0 (delta 0)
To https://github.com/your-git-username/ndslabs-specs.git
   c241a36..e09f5a2  master -> master

Verify that Conflict is Resolved

You should now see that your outstanding Pull Request, if you made one, has been updated to include your newly pushed commit.

...