Skip to content

In conclusion ... #19

@github-actions

Description

@github-actions

Welcome to the end of the hands on tutorial with Git and GitHub! You have now been exposed and practiced the basic workflow that USGS DS uses for collaborating on codebases. See the bottom of this issue for instructions about next steps.

The conceptual diagram of the workflow you just learned/used

image

A summary list of commands that were used.

Setting up a new project

  1. Fork the canonical repo to your username.
  2. Create a local copy of your fork - copy the SSH URL from your fork's GitHub page, then in Git Bash run git clone [insert your fork's SSH URL].
  3. Add the canonical repo as a remote to your local version - copy the SSH URL from the canonical repo's GitHub page, then in Git Bash run git remote add upstream [insert canonical repo's SSH URL].
  4. Verify that you are ready to go with remotes - run git remote -v and check that your fork's URL is next to origin and the canonical repo is listed next to upstream.

Saving a change locally

  1. Change the file(s).
  2. Inspect what changes git detects - run git status
  3. Stage the files that you want to include in your commit - git add [insert file name]. Pro tip: use git add . to stage all changed files listed with git status.
  4. Commit your staged changes - git commit -m "[commit message here]"

Moving your local commits to your fork

  1. Run git push origin master
  2. Look at the "commits" page on your fork on GitHub to see your new commits.

Adding your changes to the canonical repository

  1. Once you have changes on your fork that make it different from the canonical repository, go to your fork's GitHub page and click "New pull request".
  2. In the next screen, verify that the base repository shows the canonical and the head repository shows your fork.
  3. Click "Create pull request".
  4. Add a title and description. Include a peer as a reviewer and link to any related issues by adding #[issue number] in your description.
  5. The reviewer will merge the changes.
  6. Close the loop by pulling down the changes from upstream to your local repo - git pull upstream master

Handling merge conflicts

  1. If you have a merge conflict after pulling down changes, look in the file(s) that have been flagged as having conflicts.
  2. Inspect the content between <<<<<<< HEAD and =======, which is the content that existed before the merge (likely your content).
  3. Now inspect the content between ======= and >>>>>>> [string of letters and numbers], which is the content that is trying to be merged with what currently exists locally (likely the remote content).
  4. Decide what of that content to keep and what to delete.
  5. Remove the merge conflict symbols, <<<<<<< HEAD, =======, and >>>>>>> [string of letters and numbers].
  6. Save the file and then commit your merge resolution (see above for making commits). The the message "resolve merge conflict" is often used.

Feeling confident? Explore more!

There is a lot more Git that can be learned, but the above are the basics that will probably be enough for awhile. As you start to get more advanced, there may be some additional concepts/commands you should learn such as,

  • Temporarily hiding changes in order to pull upstream changes to avoid conflicts (git stash, git stash apply),
  • branching (git checkout -b), and
  • much more!

Action: Once you are done reading this, close this issue and return to the canonical repo's main GitHub page https://github.com/USGS-R/ds-gitflows-[username].

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions