...

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.

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

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 Added

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 Added

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