Skip to content

Latest commit

 

History

History
292 lines (226 loc) · 10.5 KB

k8s-contrib.md

File metadata and controls

292 lines (226 loc) · 10.5 KB

Contributing

The Kubernetes projects use a single fork with multiple branch approach, as opposed to the git/gerrit workflow.

Set up

  1. Fork in the cloud: go to https://www.github.com/kubernetes/website and fork

  2. Clone your local fork

    git clone git@github.com:<github_id>/website.git

    git clone git@github.com:aimeeu/website.git
  3. Set kubernetes/website as upstream remote

    git remote add upstream https://github.com/kubernetes/kubernetes.git
  4. Confirm remotes

    git remote -v
    origin	git@github.com:aimeeu/website.git (fetch)
    origin	git@github.com:aimeeu/website.git (push)
    upstream	https://github.com/kubernetes/website (fetch)
    upstream	https://github.com/kubernetes/website (push)

Note: if you need to change the url for a remote, use git remote set-url

Update fork master from kubernetes/website master

Always always always update your master fork before you create a branch for a PR!

git checkout master
git fetch origin
git fetch upstream
git merge upstream/master
git push -f origin
aimee@aimee-lemur:~/Dev/git/github.com/aimeeu/k8s/sigdocs/website$ git fetch upstream
remote: Enumerating objects: 40, done.
remote: Counting objects: 100% (40/40), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 57 (delta 36), reused 36 (delta 36), pack-reused 17
Unpacking objects: 100% (57/57), done.
From https://github.com/kubernetes/website
   24eee4265..5153d6e4f  master        -> upstream/master
   de2a1b36a..8480ad721  dev-1.15-ja.1 -> upstream/dev-1.15-ja.1
aimee@aimee-lemur:~/Dev/git/github.com/aimeeu/k8s/sigdocs/website$ git merge upstream/master
Updating 24eee4265..5153d6e4f
Fast-forward
 content/en/docs/concepts/storage/storage-classes.md                | 18 +++++++++++++++---
 content/en/docs/setup/production-environment/container-runtimes.md |  5 +++++
 content/es/docs/reference/glossary/applications.md                 | 13 +++++++++++++
 content/fr/docs/reference/glossary/pod.md                          | 18 ++++++++++++++++++
 4 files changed, 51 insertions(+), 3 deletions(-)
 create mode 100644 content/es/docs/reference/glossary/applications.md
 create mode 100644 content/fr/docs/reference/glossary/pod.md
aimee@aimee-lemur:~/Dev/git/github.com/aimeeu/k8s/sigdocs/website$ git push -f origin
Total 0 (delta 0), reused 0 (delta 0)
To github.com:aimeeu/website.git
 + 8398508e5...5153d6e4f master -> master (forced update)

Working locally

  1. Always update origin/master from upstream/master before creating a local working branch!! Never use git pull to do a merge because that creates a merge commit, which makes commit history messy. https://kubernetes.io/docs/contribute/new-content/open-a-pr/#changes-using-github
  2. Create a local working branch
    git checkout -b <branch-name> upstream/master
  3. Makes changes, test locally
    hugo serve
  4. Commit and push
    git commit -as
    git push -f origin <branch-name>
  5. Go to https://github.com/kubernetes/website and create a Pull Request; follow instructions in #7 https://kubernetes.io/docs/contribute/intermediate/#work-on-the-local-repository
  6. Address feedback, push updates
    git commit -a --amend
    git push -f origin <branch-name>
  7. When all feedback has been addressed, squash commits down to a single commit (k8s project policy); check the number of commits on the PR's Commits tab and with git log. If the number of commits you made is not the same between the two, you've foobarred something. Might lead to squash/rebase hell. Note: you will not have to squash commits if you use ```git commit --amend``
    git rebase -i HEAD~<number of commits>

Note: if you use git commit -a --amend, only one commit will appear in the GitHub UI. So keep the commit message the same and just add line items for what was updated in each commit (the opposite of OpenStack etiquette).

Pulling down somebody's PR for local testing

https://help.github.com/en/articles/checking-out-pull-requests-locally

aimee@aimee-lemur:~/Dev/git/github.com/aimeeu/k8s/sigdocs/website$ git checkout master
Switched to branch 'master'
Your branch is up to date with 'upstream/master'.
aimee@aimee-lemur:~/Dev/git/github.com/aimeeu/k8s/sigdocs/website$ git remote -v
origin	git@github.com:aimeeu/website.git (fetch)
origin	git@github.com:aimeeu/website.git (push)
upstream	https://github.com/kubernetes/website (fetch)
upstream	no_push (push)
aimee@aimee-lemur:~/Dev/git/github.com/aimeeu/k8s/sigdocs/website$ git fetch upstream pull/16813/head:update115toHugo572
remote: Enumerating objects: 1, done.
remote: Counting objects: 100% (1/1), done.
remote: Total 2 (delta 1), reused 1 (delta 1), pack-reused 1
Unpacking objects: 100% (2/2), done.
From https://github.com/kubernetes/website
 * [new ref]             refs/pull/16813/head -> update115toHugo572
aimee@aimee-lemur:~/Dev/git/github.com/aimeeu/k8s/sigdocs/website$ git branch
  15748-removeThirdPartyContent
  15965-blog
  aimeeu-15878-contribIntermediate
  aimeeu-2019SurveyResultsBlog
  aimeeu-addReviewBestPractices
  aimeeu-bootstrapVersion
  aimeeu-updateImportedDocsScriptDirections
  aimeeu-updateRefDocsLocation
  clarifyContentGuide
* master
  release-1.16
  update115toHugo572

Merge conflicts and rebasing

{{< note >}} For more information, see Git Branching - Basic Branching and Merging, Advanced Merging, or ask in the #sig-docs Slack channel for help. {{< /note >}}

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.

  1. Update your fork and rebase your local branch:

    git fetch origin
    git rebase origin/<your-branch-name>

    Then force-push the changes to your fork:

    git push --force-with-lease origin <your-branch-name>
  2. Fetch changes from kubernetes/website's upstream/master and rebase your branch:

    git fetch upstream
    git rebase upstream/master
  3. Inspect the results of the rebase:

    git status

This results in a number of files marked as conflicted.

  1. Open each conflicted file and look for the conflict markers: >>>, <<<, and ===. Resolve the conflict and delete the conflict marker.

    {{< note >}} For more information, see How conflicts are presented. {{< /note >}}

  2. Add the files to the changeset:

    git add <filename>
  3. Continue the rebase:

    git rebase --continue
  4. Repeat steps 2 to 5 as needed.

    After applying all commits, the git status command shows that the rebase is complete.

  5. Force-push the branch to your fork:

    git push --force-with-lease origin <your-branch-name>

    The pull request no longer shows any conflicts.

Squashing commits

{{< note >}} For more information, see Git Tools - Rewriting History, or ask in the #sig-docs Slack channel for help. {{< /note >}}

If your PR has multiple commits, you must squash them into a single commit before merging your PR. You can check the number of commits on your PR's Commits tab or by running the git log command locally.

{{< note >}} This topic assumes vim as the command line text editor. {{< /note >}}

  1. Start an interactive rebase:

    git rebase -i HEAD~<number_of_commits_in_branch>

    Squashing commits is a form of rebasing. The -i switch tells git you want to rebase interactively. HEAD~<number_of_commits_in_branch indicates how many commits to look at for the rebase.

    Output is similar to:

    pick d875112ca Original commit
    pick 4fa167b80 Address feedback 1
    pick 7d54e15ee Address feedback 2
    
    # Rebase 3d18sf680..7d54e15ee onto 3d183f680 (3 commands)
    
    ...
    
    # These lines can be re-ordered; they are executed from top to bottom.

    The first section of the output lists the commits in the rebase. The second section lists the options for each commit. Changing the word pick changes the status of the commit once the rebase is complete.

    For the purposes of rebasing, focus on squash and pick.

    {{< note >}} For more information, see Interactive Mode. {{< /note >}}

  2. Start editing the file.

    Change the original text:

    pick d875112ca Original commit
    pick 4fa167b80 Address feedback 1
    pick 7d54e15ee Address feedback 2

    To:

    pick d875112ca Original commit
    squash 4fa167b80 Address feedback 1
    squash 7d54e15ee Address feedback 2

    This squashes commits 4fa167b80 Address feedback 1 and 7d54e15ee Address feedback 2 into d875112ca Original commit, leaving only d875112ca Original commit as a part of the timeline.

  3. Save and exit your file.

  4. Push your squashed commit:

    git push --force-with-lease origin <branch_name>