Thanks for taking the time to join our community and start contributing!
Quick guide to working with a GitHub repo
Here’s a quick guide to a fairly standard GitHub workflow. This section is handy for people who don’t use git or GitHub often, and just need a quick guide to get going:
Fork the kubeEdge/website repo:
- Go to the kubeEdge/website repo on GitHub.
- Click Fork to make your own copy of the repo. GitHub creates a copy
Open a command window on your local machine.
Clone your forked repo, to copy the files down to your local machine. This example creates a directory called
kubeedgeand uses SSH cloning to download the files:
mkdir kubeedge cd kubeedge/ git clone firstname.lastname@example.org:<your-github-username>/kubeedge-website.git cd kubeedge-website/
Add the upstream repo as a git remote repo:
git remote add upstream https://github.com/kubeedge/website.git git remote set-url --push upstream no_push
Check your remotes:
git remote -v
You should have 2 remote repos:
origin- points to your own fork of the repo on gitHub - that is, the one you cloned my local repo from.
upstream- points to the actual repo on gitHub.
Create a branch. In this example, replace
doc-updateswith any branch name you like. Choose a branch name that helps you recognise the updates you plan to make in that branch:
git checkout -b doc-updates
Ensure you are in your target branch.
The branch mark with
*is your branch now.
Add and edit the files as you like. The doc pages are in the
You can use the guide here for formatting your content and using shortcodes.
git statusat any time, to check the status of your local files. Git tells you which files need adding or committing to your local repo.
Commit your updated files to your local git repo. Example commit:
git commit -a -m "Fixed some doc errors."
git add add-this-doc.md git commit -a -m "Added a shiny new doc."
Push from your branch (for example,
doc-updates) to the relevant branch on your fork on GitHub:
git checkout doc-updates git push origin doc-updates
When you’re ready to start the review process, create a pull request (PR) in the branch on your fork on the GitHub UI, based on the above push. The PR is auto-sent to the upstream repo - that is, the one you forked from.
If you need to make changes to the files in your PR, continue making them locally in the same branch, then push them again in the same way. GitHub automatically sends them through to the same PR on the upstream repo!
Hint: If you’re authenticating to GitHub via SSH, use
ssh-addto add your SSH key passphrase to the managing agent, so that you don’t have to keep authenticating to GitHub. You need to do this again after every reboot.
Please remember read and observe the Code of Conduct.