mirror of
https://github.com/moby/moby.git
synced 2022-11-09 12:21:53 -05:00
Merge pull request #12414 from draghuram/projectdoc
Improve documentation in "project" directory.
This commit is contained in:
commit
f85eb4baad
7 changed files with 58 additions and 66 deletions
|
@ -89,7 +89,7 @@ The following provides greater detail on the process:
|
|||
This is a Markdown file that describes your idea. Your proposal
|
||||
should include information like:
|
||||
|
||||
* Why is this changed needed or what are the use cases?
|
||||
* Why is this change needed or what are the use cases?
|
||||
* What are the requirements this change should meet?
|
||||
* What are some ways to design/implement this feature?
|
||||
* Which design/implementation do you think is best and why?
|
||||
|
|
|
@ -6,8 +6,8 @@ page_keywords: change, commit, squash, request, pull request, test, unit test, i
|
|||
|
||||
This checklist summarizes the material you experienced working through [make a
|
||||
code contribution](/project/make-a-contribution) and [advanced
|
||||
contributing](/project/advanced-contributing). The checklist applies to code
|
||||
that is program code or code that is documentation code.
|
||||
contributing](/project/advanced-contributing). The checklist applies to both
|
||||
program code and documentation code.
|
||||
|
||||
## Change and commit code
|
||||
|
||||
|
|
|
@ -22,7 +22,7 @@ Before you create a pull request, check your work.
|
|||
2. Checkout your feature branch.
|
||||
|
||||
$ git checkout 11038-fix-rhel-link
|
||||
Already on '11038-fix-rhel-link'
|
||||
Switched to branch '11038-fix-rhel-link'
|
||||
|
||||
3. Run the full test suite on your branch.
|
||||
|
||||
|
@ -41,7 +41,11 @@ Before you create a pull request, check your work.
|
|||
|
||||
Always rebase and squash your commits before making a pull request.
|
||||
|
||||
1. Fetch any of the last minute changes from `docker/docker`.
|
||||
1. Checkout your feature branch in your local `docker-fork` repository.
|
||||
|
||||
This is the branch associated with your request.
|
||||
|
||||
2. Fetch any last minute changes from `docker/docker`.
|
||||
|
||||
$ git fetch upstream master
|
||||
From github.com:docker/docker
|
||||
|
@ -57,27 +61,27 @@ Always rebase and squash your commits before making a pull request.
|
|||
pick 53e4983 Fix a link
|
||||
pick 3ce07bb Add a new line about RHEL
|
||||
|
||||
If you run into trouble, `git --rebase abort` removes any changes and gets
|
||||
you back to where you started.
|
||||
|
||||
4. Squash the `pick` keyword with `squash` on all but the first commit.
|
||||
5. Replace the `pick` keyword with `squash` on all but the first commit.
|
||||
|
||||
pick 1a79f55 Tweak some of the other text for grammar
|
||||
squash 53e4983 Fix a link
|
||||
squash 3ce07bb Add a new line about RHEL
|
||||
|
||||
After closing the file, `git` opens your editor again to edit the commit
|
||||
message.
|
||||
After you save the changes and quit from the editor, git starts
|
||||
the rebase, reporting the progress along the way. Sometimes
|
||||
your changes can conflict with the work of others. If git
|
||||
encounters a conflict, it stops the rebase, and prints guidance
|
||||
for how to correct the conflict.
|
||||
|
||||
5. Edit and save your commit message.
|
||||
6. Edit and save your commit message.
|
||||
|
||||
`git commit -s`
|
||||
|
||||
Make sure your message includes <a href="./set-up-git" target="_blank>your signature</a>.
|
||||
|
||||
8. Push any changes to your fork on GitHub.
|
||||
7. Force push any changes to your fork on GitHub.
|
||||
|
||||
$ git push origin 11038-fix-rhel-link
|
||||
$ git push -f origin 11038-fix-rhel-link
|
||||
|
||||
## Create a PR on GitHub
|
||||
|
||||
|
@ -108,7 +112,7 @@ You create and manage PRs on GitHub:
|
|||
4. Scroll down and verify the PR contains the commits and changes you expect.
|
||||
|
||||
For example, is the file count correct? Are the changes in the files what
|
||||
you expect.
|
||||
you expect?
|
||||
|
||||
![Commits](/project/images/commits_expected.png)
|
||||
|
||||
|
|
|
@ -184,8 +184,8 @@ To sync your repository:
|
|||
First, rewinding head to replay your work on top of it...
|
||||
Fast-forwarded master to upstream/master.
|
||||
|
||||
This command writes all the commits from the upstream branch into your local
|
||||
branch.
|
||||
This command applies all the commits from the upstream master to your local
|
||||
master.
|
||||
|
||||
8. Check the status of your local branch.
|
||||
|
||||
|
@ -195,12 +195,12 @@ To sync your repository:
|
|||
(use "git push" to publish your local commits)
|
||||
nothing to commit, working directory clean
|
||||
|
||||
Your local repository now has any changes from the `upstream` remote. You
|
||||
Your local repository now has all the changes from the `upstream` remote. You
|
||||
need to push the changes to your own remote fork which is `origin master`.
|
||||
|
||||
9. Push the rebased master to `origin master`.
|
||||
|
||||
$ git push origin
|
||||
$ git push origin master
|
||||
Username for 'https://github.com': moxiegirl
|
||||
Password for 'https://moxiegirl@github.com':
|
||||
Counting objects: 223, done.
|
||||
|
@ -228,8 +228,8 @@ To sync your repository:
|
|||
Current branch 11038-fix-rhel-link is up to date.
|
||||
|
||||
At this point, your local branch, your remote repository, and the Docker
|
||||
repository all have identical code. You are ready to make changesfor your
|
||||
issues.
|
||||
repository all have identical code. You are ready to make changes for your
|
||||
issue.
|
||||
|
||||
|
||||
## Where to go next
|
||||
|
|
|
@ -88,7 +88,7 @@ contributions through pseudonyms.
|
|||
As you change code in your fork, you'll want to keep it in sync with the changes
|
||||
others make in the `docker/docker` repository. To make syncing easier, you'll
|
||||
also add a _remote_ called `upstream` that points to `docker/docker`. A remote
|
||||
is just another a project version hosted on the internet or network.
|
||||
is just another project version hosted on the internet or network.
|
||||
|
||||
To configure your username, email, and add a remote:
|
||||
|
||||
|
@ -171,7 +171,7 @@ the branch to your fork on GitHub:
|
|||
|
||||
You can use any text editor you are comfortable with.
|
||||
|
||||
6. Close and save the file.
|
||||
6. Save and close the file.
|
||||
|
||||
7. Check the status of your branch.
|
||||
|
||||
|
|
|
@ -82,7 +82,7 @@ your user to the `docker` group as follows:
|
|||
|
||||
$ sudo usermod -aG docker ubuntu
|
||||
|
||||
You must log out and back in for this modification to take effect.
|
||||
You must log out and log back in for this modification to take effect.
|
||||
|
||||
|
||||
## Where to go next
|
||||
|
|
|
@ -109,7 +109,7 @@ Follow this workflow as you work:
|
|||
|
||||
9. Push your change to your repository.
|
||||
|
||||
$ git push origin
|
||||
$ git push origin 11038-fix-rhel-link
|
||||
Username for 'https://github.com': moxiegirl
|
||||
Password for 'https://moxiegirl@github.com':
|
||||
Counting objects: 60, done.
|
||||
|
@ -145,56 +145,44 @@ After you push a new branch, you should verify it on GitHub:
|
|||
|
||||
You should pull and rebase frequently as you work.
|
||||
|
||||
1. Return to the terminal on your local machine.
|
||||
1. Return to the terminal on your local machine and checkout your
|
||||
feature branch in your local `docker-fork` repository.
|
||||
|
||||
2. Make sure you are in your branch.
|
||||
|
||||
$ git checkout 11038-fix-rhel-link
|
||||
|
||||
3. Fetch all the changes from the `upstream master` branch.
|
||||
2. Fetch any last minute changes from `docker/docker`.
|
||||
|
||||
$ git fetch upstream master
|
||||
From github.com:docker/docker
|
||||
* branch master -> FETCH_HEAD
|
||||
|
||||
This command says get all the changes from the `master` branch belonging to
|
||||
the `upstream` remote.
|
||||
|
||||
4. Rebase your master with the local copy of Docker's `master` branch.
|
||||
3. Start an interactive rebase.
|
||||
|
||||
$ git rebase -i upstream/master
|
||||
|
||||
This command starts an interactive rebase to rewrite all the commits from
|
||||
Docker's `upstream/master` onto your local branch, and then re-apply each of
|
||||
your commits on top of the upstream changes. If you aren't familiar or
|
||||
comfortable with rebase, you can <a
|
||||
href="http://nathanleclaire.com/blog/2014/09/14/dont-be-scared-of-git-
|
||||
rebase" target="_blank">learn more about rebasing</a> on the web.
|
||||
|
||||
5. Rebase opens an editor with a list of commits.
|
||||
4. Rebase opens an editor with a list of commits.
|
||||
|
||||
pick 1a79f55 Tweak some of the other text for grammar
|
||||
pick 53e4983 Fix a link
|
||||
pick 3ce07bb Add a new line about RHEL
|
||||
|
||||
If you run into trouble, `git --rebase abort` removes any changes and gets
|
||||
you back to where you started.
|
||||
|
||||
6. Squash the `pick` keyword with `squash` on all but the first commit.
|
||||
5. Replace the `pick` keyword with `squash` on all but the first commit.
|
||||
|
||||
pick 1a79f55 Tweak some of the other text for grammar
|
||||
squash 53e4983 Fix a link
|
||||
squash 3ce07bb Add a new line about RHEL
|
||||
|
||||
After closing the file, `git` opens your editor again to edit the commit
|
||||
message.
|
||||
After you save the changes and quit from the editor, git starts
|
||||
the rebase, reporting the progress along the way. Sometimes
|
||||
your changes can conflict with the work of others. If git
|
||||
encounters a conflict, it stops the rebase, and prints guidance
|
||||
for how to correct the conflict.
|
||||
|
||||
7. Edit the commit message to reflect the entire change.
|
||||
6. Edit and save your commit message.
|
||||
|
||||
Make sure you include your signature.
|
||||
`git commit -s`
|
||||
|
||||
8. Push any changes to your fork on GitHub.
|
||||
Make sure your message includes <a href="./set-up-git" target="_blank>your signature</a>.
|
||||
|
||||
The rebase rewrote history, so you'll need to use the `-f` or `--force` flag
|
||||
to push your change.
|
||||
7. Force push any changes to your fork on GitHub.
|
||||
|
||||
$ git push -f origin 11038-fix-rhel-link
|
||||
|
||||
|
|
Loading…
Reference in a new issue