kotovalexarian-likes-github/moby--moby
1
0
Fork 0
mirror of https://github.com/moby/moby.git synced 2022-11-09 12:21:53 -05:00
Code Releases Activity

Merge pull request #12414 from draghuram/projectdoc

Browse source 
Improve documentation in "project" directory.
This commit is contained in:
moxiegirl 2015-04-20 13:16:20 -07:00
commit f85eb4baad
7 changed files with 58 additions and 66 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
docs/sources/project/advanced-contributing.md
View file

@ -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?

4
docs/sources/project/coding-style.md
View file

@ -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

30
docs/sources/project/create-pr.md
View file

@ -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
@ -56,28 +60,28 @@ Always rebase and squash your commits before making a pull request.
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.
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)
@ -124,4 +128,4 @@ You create and manage PRs on GitHub:
Congratulations, you've created your first pull request to Docker. The next
step is for you learn how to [participate in your PR's
review](/project/review-pr/).
review](/project/review-pr/).

16
docs/sources/project/find-an-issue.md
View file

@ -172,8 +172,8 @@ To sync your repository:
remote: Total 141 (delta 52), reused 46 (delta 46), pack-reused 66
Receiving objects: 100% (141/141), 112.43 KiB | 0 bytes/s, done.
Resolving deltas: 100% (79/79), done.
From github.com:docker/docker
* branch master -> FETCH_HEAD
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.
@ -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

4
docs/sources/project/set-up-git.md
View file

@ -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.

2
docs/sources/project/software-required.md
View file

@ -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

66
docs/sources/project/work-issue.md
View file

@ -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,58 +145,46 @@ 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.
2. Fetch any last minute changes from `docker/docker`.
$ git checkout 11038-fix-rhel-link
$ git fetch upstream master
From github.com:docker/docker
* branch master -> FETCH_HEAD
3. Fetch all the changes from the `upstream master` branch.
3. Start an interactive rebase.
$ git fetch upstream master
$ git rebase -i upstream/master
This command says get all the changes from the `master` branch belonging to
the `upstream` remote.
4. Rebase opens an editor with a list of commits.
4. Rebase your master with the local copy of Docker's `master` branch.
pick 1a79f55 Tweak some of the other text for grammar
pick 53e4983 Fix a link
pick 3ce07bb Add a new line about RHEL
$ 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.
5. Replace the `pick` keyword with `squash` on all but the first commit.
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.
pick 1a79f55 Tweak some of the other text for grammar
squash 53e4983 Fix a link
squash 3ce07bb Add a new line about RHEL
6. Squash the `pick` keyword with `squash` on all but the first commit.
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.
pick 1a79f55 Tweak some of the other text for grammar
squash 53e4983 Fix a link
squash 3ce07bb Add a new line about RHEL
6. Edit and save your commit message.
After closing the file, `git` opens your editor again to edit the commit
message.
`git commit -s`
7. Edit the commit message to reflect the entire change.
Make sure your message includes <a href="./set-up-git" target="_blank>your signature</a>.
Make sure you include your signature.
7. Force push any changes to your fork on GitHub.
8. Push any changes to your fork on GitHub.
The rebase rewrote history, so you'll need to use the `-f` or `--force` flag
to push your change.
$ git push -f origin 11038-fix-rhel-link
$ git push -f origin 11038-fix-rhel-link
## Where to go next