Skip to content

Update CONTRIBUTING.md Section 2.7.d and 2.7.e #8479

@santi-jose

Description

@santi-jose

Prerequisite

  1. Be a member of Hack for LA. (There are no fees to join.) If you have not joined yet, please follow the steps on our Getting Started page and attend an onboarding session.
  2. Before you claim or start working on an issue, please make sure you have read our How to Contribute to Hack for LA Guide.

Overview

In Section 2.7.d we instruct devs to sync their fork with origin and to pull upstream changes from gh-pages into their topic branch. However, many of the remaining instructions in 2.7.d and 2.7.e are redundant in most cases.

Action Items

  • In your local IDE, navigate to CONTRIBUTING.md
  • Find section 2.7.d.i
  • Replace the first paragraph in section 2.7.d.i:
If you do not see any output, there have not been any changes in the main Hack for LA website repository since the last time you
checked. So it is safe to push your local commits to your fork.

with

If you pulled the upstream repository and there have not been any changes in the main Hack for LA website repository since you last pulled, you may get an output like this: 
```bash
 * branch              gh-pages   -> FETCH_HEAD
Already up to date.
```
This means it is safe to push your local commits to your fork.
**Note**: Depending on your git settings, you may need to write a commit message to merge the changes that were pulled into your local branch.
  • Delete section 2.7.d.ii. Be careful not to delete the link to the table of contents at the bottom of the 2.7.d.ii section:
##### **ii. If there are conflicting changes in the upstream repository**

When you check the upstream repository, you may see output like this:

```bash
Fetching upstream
remote: Enumerating objects: 11, done.
remote: Counting objects: 100% (11/11), done.
remote: Compressing objects: 100% (7/7), done.
remote: Total 11 (delta 5), reused 7 (delta 4), pack-reused 0
Unpacking objects: 100% (11/11), 8.25 KiB | 402.00 KiB/s, done.
From https://github.com/hackforla/website
+ 770d667...14f9f46 Bonnie     -> hackforla/Bonnie  (forced update)
* [new branch]      bonnie     -> hackforla/bonnie
5773ebe..0c86ecd  gh-pages   -> hackforla/gh-pages
```


**Note:** You can safely ignore changes in other issue branches, such as `bonnie` above. But if you see changes in gh-pages, as in `5773ebe..0c86ecd  gh-pages   -> hackforla/gh-pages`, you should incorporate those changes into your repository before merging or rebasing your issue branch. Use the [instructions below](#27e-working-on-an-issue-5-incorporating-changes-from-upstream) to bring your fork up to date with the main repository.
  • Rename the 2.7.e title from
#### **2.7.e Working on an issue (5): Incorporating changes from upstream**

to

#### **2.7.e Working on an issue (5):Alternative methods for incorporating changes from upstream**
  • Replace first paragraph in section 2.7.e:
Your fork of this repository on GitHub, and your local clone of that fork, will get out of sync with this (upstream) repository from time to time. (That's what has happened when you see something like "This branch is 1 commit behind hackforla:gh-pages" on the GitHub website version of your hackforla repository.)

with

This section shows you alternative methods to sync your fork with the main Hack for LA website repository. The recommended method for syncing your fork is through the GitHub browser as detailed in section [2.7.d](https://github.com/hackforla/website/blob/gh-pages/CONTRIBUTING.md#27d-working-on-an-issue-4-pulling-from-upstream-before-you-push)
  • Before the first code snippet in 2.7.e.i:
git checkout update-give-link-2093
git rebase gh-pages

add

We prefer `rebase` because it keeps the commit history clean and linear. If rebasing fails or becomes complex, use `merge`, which preserves branch history but may add additional merge commits.
  • With CONTRIBUTING.md still open, make a note of the section in which the replaced content appears, so that you will know where to look in the document to preview the change.
  • Changes to CONTRIBUTING.md cannot be tested locally, rather they must be tested after pushing the issue branch to your fork of the repository. Push your issue branch in the usual manner, but before creating the Pull Request, check your updates using this test URL. Also store the test URL for use in a later step:
https://github.com/[REPLACE WITH GITHUB HANDLE]/website/blob/[REPLACE WITH NAME OF ISSUE BRANCH]/CONTRIBUTING.md

(for example: https://github.com/bonniewolfe/website/blob/issue-branch-1234/CONTRIBUTING.md)

  • Create a pull request with your changes. In the Pull Request, after the "Why did you make the changes" section, add this line to help reviewers, replacing the text in brackets (and the brackets) with the test URL from the previous Action Item.
For Reviewers: Do not review changes locally, rather, review changes at [REPLACE WITH TEST URL]

Resources/Instructions

Metadata

Metadata

Assignees

Labels

Complexity: SmallTake this type of issues after the successful merge of your second good first issueFeature: Wikirole: back end/devOpsTasks for back-end developersrole: front endTasks for front end developerssize: 0.5ptCan be done in 3 hours or less

Type

No type

Projects

Status

QA

Relationships

None yet

Development

No branches or pull requests

Issue actions