Make a Change Using a Local Clone
Overview
To make a significant changes to the armory/docs
repository, you can fork the repository and work from a local clone. The workflow below walks through a fork-and-pull-request change to the armory/docs
repository.
Before you begin
Make sure you have git installed on your computer and have configured your GitHub account. See the GitHub Help for details.
Fork and clone
-
Navigate to the
armory/docs
repository with a web browser. -
Click Fork.
-
In a terminal window, clone your fork:
-
Navigate to the new
armory/docs
directory. Set thearmory/docs
repository as theupstream
remote: -
Confirm your
origin
andupstream
repositories:Output is similar to:
-
Pull in the site theme submodule
-
Navigate to the
armory/docs
repository with a web browser. -
In a terminal window, clone the repo:
Update your local repository
Make sure your local repository is current before you start making changes. Fetch commits from your fork’s origin/master
and armory/docs
upstream/master
:
Create a working branch
Make sure you are in your master
branch before you create your working
branch. You can use git branch
to see which branch you are in.
If you are not in master
, execute git checkout master
to go to your master
branch. See the Understanding history: What is a branch? section of the Git User Manual for more information.
Create a new working branch:
Create a new working branch based on upstream/master
.
Since git
tracks changes to upstream\master
, you don’t need to rebase your fork before you create a working branch.
Create your content
Make your changes. Be sure to follow the guidelines in the Content Guide and the Style Guide.
Use the git status
command at any time to see what files you’ve changed.
Test or preview changes locally
Once you have made changes, the next step is to test your changes in action. How you do this depends on the resource you changed and the resources it interacts with.
If you make changes to armory/docs
and want to preview them locally, install the version of Hugo specified in the netlify.toml
file. Run this command from the repo root:
hugo server
You don’t have to compile and preview locally. When you submit a pull request, Netlify generates a Deploy Preview
that you and the reviewers can use to view the rendered content.
Commit your changes
-
Check which files you need to commit:
Output is similar to:
-
Add new files listed under Untracked files to the commit:
Repeat this for each new file.
-
Create a commit:
-a
: Commit all staged changes.-m
: Use the given<your-commit-subject>
as the commit message. If multiple-m
options are given, their values are concatenated as separate paragraphs.
Your commit messages must be 50 characters or less. Do not use any GitHub Keywords in your commit message. You can add those to the pull request description later.
-
Push your working branch and its new commit to your remote fork:
You can commit and push many times before you create your PR.
Create a pull request
-
In a web browser, go to the
armory/docs
repository. You should see your recently pushed working branch with a Compare & pull request button. -
Click Compare & pull request. This takes you to the Open a pull request screen.
-
The Title defaults to the commit subject. Update the title so it follows the
<type>(<scope>): <subject>
format. Make sure you include a space after the colon. For example:docs(plugins): add documentation for plugin creators
The
armory/docs
repository uses a PR title checker, so your PR will fail if the title is not in the correct format. -
The Leave a comment field defaults to the commit description. Pull request descriptions are the first step to helping reviewers and project maintainers understand why your change was made. Do not leave this field blank. Provide as much description as possible. A good description helps get your PR merged faster!
-
Leave the Allow edits from maintainers checkbox selected.
-
-
Click the Create pull request button.
Congratulations! You can view your submitted pull request on the Pull requests tab.
Do not delete your working branch until your pull request has been merged! You may need to update your content based on reviewer feedback.
When you look at your PR, you may see a This branch is out-of-date with the base branch message. This means approvers merged PRs while you were working on your changes. If you see a Merge conflict message, you need to rebase your PR.
Addressing feedback locally
Reviewers may ask you to make changes to your pull request. Read the feedback and make changes in your working branch.
-
After making your changes, create a new commit:
-
Push your changes:
Changes from reviewers
Sometimes reviewers commit changes to your pull request. Fetch those commits before making any other changes.
-
Fetch commits from your remote fork and rebase your working branch:
-
After rebasing, force-push new changes to your fork:
Merge conflicts and rebasing
If another contributor commits changes to the same file in another PR, it can create a merge conflict. You must resolve all merge conflicts in your PR.
-
Update your fork and rebase your working branch:
Then force-push the changes to your fork:
-
Fetch changes from
armory/docs
'supstream/master
and rebase your branch: -
Inspect the results of the rebase:
This results in a number of files marked as conflicted.
-
Open each conflicted file and look for the conflict markers:
>>>
,<<<
, and===
. Resolve the conflict and delete the conflict marker.For more information, see How conflicts are presented.
-
Add the files to the changeset:
-
Continue the rebase:
- Repeat steps 2 to 5 as needed.
After applying all commits, the git status
command shows that the rebase is complete.
-
Force-push your working branch to your remote fork:
The pull request no longer shows any conflicts.
For more information, see Git Branching - Basic Branching and Merging, Advanced Merging.
Feedback
Was this page helpful?
Thank you for letting us know!
Sorry to hear that. Please tell us how we can improve.
Last modified August 25, 2022: (c330a861)