...

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.

This can be accomplished by navigating to https://github.com/nds-org/nds-labs/tree/v2 and clicking on the "Fork" button at the top-right.

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

Image Removed

Clone from Origin Repository

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

To make modifications to the code, the developer clones their origin repository.

This creates a local working copy of the code that is independent of your personal fork.

...

Feature Branches

The best way to avoid conflicts or collisions when merging is to isolate each subset of related changes to its own branch.

Resolving Merge Conflicts

What happens when you do have conflicts? Just follow these steps!

Splitting a Repository While Preserving History

What happens when your repo becomes unmanageably large or bloated?

Cloning the repository (and specifying the "upstream repository") with the following commands:

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

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

git add <filename or regex>

Modify the code all you want and when you are ready to commit to your local copy:

git commit -a -m "Enter a short description of your commit here."

Any changes that they wish to contribute back to the upstream repository can be done in the form of a Pull Request.

Undoing your Last Commit

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:

git reset HEAD^

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.

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.

To make a Pull Request, navigate to your forked repository: https://github.com/your-git-username/nds-labs.git and click one of the several "Pull Request" button to Create a New Pull Request.

Image Removed

You can choose the source and destination remote and branch from here, as well as name your PR and enter a short description if you'd like.

In general, we tend to name Pull Requests after JIRA tickets, if the issue we are addressing has one associated with it. For example: NDS-101: Summary of JIRA Ticket

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

Syncing with Upstream and 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.

Now you go to make a pull request and it says "Cannot automatically merge"

Image Removed

Gimme a break! We went through all of that and there's still going to be merge conflicts? Welcome to source control, my friend.

Not to worry! These things can usually be easily resolved if you are following the feature-branching advice given above.

(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 Recommendations below.)

Recommendations

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.

You work for days and days on a new addition and fix some bugs along the way, only to find that your proposed addition is not going to work properly.

But half of the work you have done on the branch was bug fixed, which need to make their way back upstream.

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.

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

This way, you can make a PR for any modifications separately and once they are ready, instead of needing to manually roll back or redo changes.

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