You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: book/06-github/sections/2-contributing.asc
+16-17Lines changed: 16 additions & 17 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,7 +6,7 @@ Now that our account is set up, let's walk through some details that could be us
6
6
7
7
(((forking)))
8
8
If you want to contribute to an existing project to which you don’t have push access, you can ``fork'' the project.
9
-
What this means is that GitHub will make a copy of the project that is entirely yours; it lives in your user's namespace, and you can push to it.
9
+
When you ``fork'' a project, GitHub will make a copy of the project that is entirely yours; it lives in your namespace, and you can push to it.
10
10
11
11
[NOTE]
12
12
====
@@ -36,12 +36,13 @@ It is centered on the <<_topic_branch>> workflow covered in <<_git_branching>>.
36
36
37
37
Here's how it generally works:
38
38
39
-
1. Create a topic branch from `master`.
40
-
2. Make some commits to improve the project.
41
-
3. Push this branch to your GitHub project.
42
-
4. Open a Pull Request on GitHub.
43
-
5. Discuss, and optionally continue committing.
44
-
6. The project owner merges or closes the Pull Request.
39
+
1. Fork the project
40
+
2. Create a topic branch from `master`.
41
+
3. Make some commits to improve the project.
42
+
4. Push this branch to your GitHub project.
43
+
5. Open a Pull Request on GitHub.
44
+
6. Discuss, and optionally continue committing.
45
+
7. The project owner merges or closes the Pull Request.
45
46
46
47
This is basically the Integration Manager workflow covered in <<_integration_manager>>, but instead of using email to communicate and review changes, teams use GitHub's web based tools.
In addition to issue numbers, you can also reference a specific commit by SHA-1. You have to specify a full 40 character SHA-1, but if GitHub sees that in a comment, it will link directly to the commit. Again, you can reference commits in forks or other repositories in the same way you did with issues.
287
288
288
-
==== Markdown
289
+
==== GitHub Flavored Markdown
289
290
290
291
Linking to other Issues is just the beginning of interesting things you can do with almost any text box on GitHub. In Issue and Pull Request descriptions, comments, code comments and more, you can use what is called ``GitHub Flavored Markdown''. Markdown is like writing in plain text but which is rendered richly.
291
292
292
293
See <<_example_markdown>> for an example of how comments or text can be written and then rendered using Markdown.
293
294
294
295
[[_example_markdown]]
295
-
.An example of Markdown as written and as rendered.
296
+
.An example of GitHub Flavored Markdown as written and as rendered.
The GitHub flavor of Markdown adds more things you can do beyond the basic Markdown syntax. These can all be really useful when creating useful Pull Request or Issue comments or descriptions.
301
300
302
-
====== Task Lists
301
+
===== Task Lists
303
302
304
303
The first really useful GitHub specific Markdown feature, especially for use in Pull Requests, is the Task List. A task list is a list of checkboxes of things you want to get done. Putting them into an Issue or Pull Request normally indicates things that you want to get done before you consider the item complete.
These are incredibly useful when you open a Pull Request early and use it to track your progress through the implementation of the feature.
330
329
331
-
====== Code Snippets
330
+
===== Code Snippets
332
331
333
332
You can also add code snippets to comments. This is especially useful if you want to present something that you _could_ try to do before actually implementing it as a commit on your branch. This is also often used to add example code of what is not working or what this Pull Request could implement.
334
333
@@ -350,7 +349,7 @@ If you add a language name like we did there with 'java', GitHub will also try t
If you're responding to a small part of a long comment, you can selectively quote out of the other comment by preceding the lines with the `>` character. In fact, this is so common and so useful that there is a keyboard shortcut for it. If you highlight text in a comment that you want to directly reply to and hit the `r` key, it will quote that text in the comment box for you.
356
355
@@ -370,7 +369,7 @@ Once rendered, the comment will look like <<_md_quote>>.
Finally, you can also use emoji in your comments. This is actually used quite extensively in comments you see on many GitHub Issues and Pull Requests. There is even an emoji helper in GitHub. If you are typing a comment and you start with a `:` character, an autocompleter will help you find what you're looking for.
376
375
@@ -407,12 +406,12 @@ There are actually quite a number of web services that make use of emoji charact
407
406
http://www.emoji-cheat-sheet.com
408
407
====
409
408
410
-
====== Images
409
+
===== Images
411
410
412
411
This isn't technically GitHub Flavored Markdown, but it is incredibly useful. In addition to adding Markdown image links to comments, which can be difficult to find and embed URLs for, GitHub allows you to drag and drop images into text areas to embed them.
413
412
414
413
[[_md_drag]]
415
414
.Drag and drop images to upload them and auto-embed them.
416
415
image::images/markdown-08-drag-drop.png[Drag and drop images]
417
416
418
-
If you look back at <<_pr_references>>, you can see a small ``Parsed as Markdown'' hint above the text area. Clicking on that will give you a full cheat sheet of everything you can do with Markdown on GitHub.
417
+
If you look at <<_md_drag>>, you can see a small ``Parsed as Markdown'' hint above the text area. Clicking on that will give you a full cheat sheet of everything you can do with Markdown on GitHub.
Copy file name to clipboardExpand all lines: book/06-github/sections/3-maintaining.asc
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -27,14 +27,14 @@ Since you have no code there yet, GitHub will show you instructions for how to c
27
27
We won't belabor this here; if you need a refresher, check out <<_git_basics_chapter>>.
28
28
29
29
Now that your project is hosted on GitHub, you can give the URL to anyone you want to share your project with.
30
-
Every project on GitHub is accessible over HTTP as `https://github.com/<user>/<project_name>`, and over SSH as `[email protected]:<user>/<project_name>`.
30
+
Every project on GitHub is accessible over HTTPS as `https://github.com/<user>/<project_name>`, and over SSH as `[email protected]:<user>/<project_name>`.
31
31
Git can fetch from and push to both of these URLs, but they are access-controlled based on the credentials of the user connecting to them.
32
32
33
33
[NOTE]
34
34
====
35
-
It is often preferable to share the HTTP based URL for a public project, since the user does not have to have a GitHub account to access it for cloning.
35
+
It is often preferable to share the HTTPS based URL for a public project, since the user does not have to have a GitHub account to access it for cloning.
36
36
Users will have to have an account and an uploaded SSH key to access your project if you give them the SSH URL.
37
-
The HTTP one is also exactly the same URL they would paste into a browser to view the project there.
37
+
The HTTPS one is also exactly the same URL they would paste into a browser to view the project there.
0 commit comments