Skip to content

Latest commit

 

History

History
44 lines (29 loc) · 3.51 KB

assignment.md

File metadata and controls

44 lines (29 loc) · 3.51 KB

Overview

This is a technical writing and editing project as part of your interview.

This project is designed to take between 1 - 2 hours. Please take the time to carefully review the writing style guide.

Instructions

Create a new GitHub repository with the following content (See content) as the first commit. Make a branch and open a PR to edit the text for clarity, and include any questions about the content's meaning, as if you were editing a colleague’s work.

Any changes that you think will improve the text and explain the concepts better are welcome. If anything in the text doesn’t match your opinion on a best practice, feel free to correct the meaning of the text. The result should be a document that you, as a technical writer, would be comfortable sharing with end-users.

Construct your PR to teach the author:

  • Make atomic commits.
  • Write your commit messages to show your rationale for edits.
  • Please construct your commits, commit messages, and PR description as you would for an actual PR as if you were collaborating with a team.
  • It is best to edit the files on your local machine and push with the git command or a desktop Git application rather than editing directly on the github.com website.

Edit the text so that it is easy to read:

  • Correct errors.
  • Put the text in active voice and present tense.
  • Address the reader as you, not we.
  • Phrase statements as positive rather than negative.
  • Make the language simple and plain.
  • Avoid euphemisms.
  • Structure the text so it has a logical flow.

Once you're finished with your edits, send the PR link to the HashiCorp recruiter.

NOTE: DO NOT FORK THE PROJECT. MAKE A COPY OF ALL FILES, CREATE YOUR OWN FRESH REPOSITORY AND SUBMIT A PULL REQUEST TOWARDS YOUR OWN PROJECT. DO NOT MERGE THE PULL REQUEST.

Content

What is the difference between push, pull, and fetch?

  • git push - sent changes from a local branch to a remote repo
  • git fetch - get changes from a remote repo into your tracking branch
  • git pull - will get changes from a remote branch into your tracking branch and merge them into a local branch

Often git push and git pull are described as equivalent. This isn't entirely correct, since under the hood git pull does two things. git push takes our current branch, and checks to see whether or not there is a tracking branch for a remote repository connected to it. If so, our changes are taken from our branch and pushed to the remote branch. This is how code is shared with a remote repository, you can think of it as "make the remote branch resemble my local branch". This will fail if the remote branch has diverged from your local branch: if not all the commits in the remote branch are in your local branch. When this happens, your local branch needs to be synchronized with the remote branch with git pull or git fetch and git merge.git fetch again takes our current branch, and checks to see if there is a tracking branch. If so, it looks for changes in the remote branch, and pulls them into the tracking branch. It does not change your local branch. To do that, you'll need to do git merge origin/master (for the "master" branch) to merge those changes into your branch - probably also called "master".git pull simply does a git fetch followed immediately by git merge. This is often what we desire to do, but some people prefer to use git fetch followed by git merge to make sure they understand the changes they are merging into their branch before the merge happens.