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/01-introduction/sections/command-line.asc
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,7 @@ There are a lot of different ways to use Git.
4
4
There are the original command line tools, and there are many graphical user interfaces of varying capabilities.
5
5
For this book, we will be using Git on the command line.
6
6
For one, the command line is the only place you can run *all* Git commands – most of the GUIs only implement some subset of Git functionality for simplicity.
7
-
If you know how to run the command line version, you can probably also figure out how to run the GUI version, while the opposite is not neccesarily true.
7
+
If you know how to run the command line version, you can probably also figure out how to run the GUI version, while the opposite is not necessarily true.
8
8
Also, while your choice of graphical client is a matter of personal taste, _all_ users will have the command-line tools installed and available.
9
9
10
10
So we will expect you to know how to open Terminal in Mac or Command Prompt or Powershell in Windows.
Copy file name to clipboardExpand all lines: book/03-git-branching/sections/remote-branches.asc
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -85,7 +85,7 @@ If you didn't want it to be called `serverfix` on the remote, you could instead
85
85
====
86
86
If you're using an HTTPS URL to push over, the Git server will ask you for your username and password for authentication. By default it will prompt you on the terminal for this information so the server can tell if you're allowed to push.
87
87
88
-
If you don't want to type it every sinlge time you push, you can set up a ``credential cache''. The simplest is just to keep it in memory for a few mintues, which you can easily set up by running `git config --global credential.helper cache`.
88
+
If you don't want to type it every single time you push, you can set up a ``credential cache''. The simplest is just to keep it in memory for a few mintues, which you can easily set up by running `git config --global credential.helper cache`.
89
89
90
90
For more information on the various credential caching options available, see <<_credential_caching>>.
Anyone can also leave general comments on the Pull Request. In <<_pr_discussion>> we can see an example of the project owner both commenting on a line of code and then leaving a general comment in the discussion section. You can see that the code comments are brought into the conversation as well.
Now the contributor can see what they need to do in order to get their change accepted. Luckily this is also a very simple thing to do. Where over email you may have to re-roll your series and resubmit it to the mailing list, with GitHub you simply commit to the topic branch again and push.
@@ -168,7 +168,7 @@ This is the basic workflow that most GitHub projects use. Topic branches are cre
168
168
[NOTE]
169
169
.Not Only Forks
170
170
====
171
-
It's important to note that you can also open a Pull Request between two branches in the same repository. If you're working on a feature with someone and you both have write access to the project, you can push a topic branch to the repository and open a Pull Request on it to the `master` branch of that same project to initiate the code review and discussion process. No forking neccesary.
171
+
It's important to note that you can also open a Pull Request between two branches in the same repository. If you're working on a feature with someone and you both have write access to the project, you can push a topic branch to the repository and open a Pull Request on it to the `master` branch of that same project to initiate the code review and discussion process. No forking necessary.
172
172
====
173
173
174
174
==== Advanced Pull Requests
@@ -237,7 +237,7 @@ To https://github.com/tonychacon/blink
237
237
<1> Add the original repository as a remote named ``upstream''
238
238
<2> Fetch the newest work from that remote
239
239
<3> Merge the main branch into your topic branch
240
-
<4> Fix the conflict that occured
240
+
<4> Fix the conflict that occurred
241
241
<5> Push back up to the same topic branch
242
242
243
243
Once you do that, the Pull Request will be automatically updated and re-checked to see if it merges cleanly.
@@ -395,7 +395,7 @@ Not that this is incredibly useful, but it does add an element of fun and emotio
395
395
396
396
[NOTE]
397
397
====
398
-
There are actually quite a number of web services that make use of emoji charaters these days. A great cheat sheet to reference to find emoji that expresses what you want to say can be found at:
398
+
There are actually quite a number of web services that make use of emoji characters these days. A great cheat sheet to reference to find emoji that expresses what you want to say can be found at:
The two choices are to get notifications over ``Email'' and over ``Web'' and you can choose either, niether or both for when you actively participate in things and for activity on repositories you are watching.
238
+
The two choices are to get notifications over ``Email'' and over ``Web'' and you can choose either, neither or both for when you actively participate in things and for activity on repositories you are watching.
239
239
240
240
====== Web Notifications
241
241
242
242
Web notifications only exist on GitHub and you can only check them on GitHub. If you have this option selected in your preferences and a notification is triggered for you, you will see a small blue dot over your notifications icon at the top of your screen as seen in <<_not_center>>.
If you click on that, you will see a list of all the items you have been notified about, grouped by project. You can filter to the notifications of a specific project by clicking on it's name in the left hand sidebar. You can also acknowledge the notifiction by clicking the checkmark icon next to any notification, or acknowledge _all_ of the notifictions in a project by clicking the checkmark at the top of the group. There is also a mute button next to each checkmark that you can click to not receive any further notifications on that item.
248
+
If you click on that, you will see a list of all the items you have been notified about, grouped by project. You can filter to the notifications of a specific project by clicking on it's name in the left hand sidebar. You can also acknowledge the notification by clicking the checkmark icon next to any notification, or acknowledge _all_ of the notifictions in a project by clicking the checkmark at the top of the group. There is also a mute button next to each checkmark that you can click to not receive any further notifications on that item.
249
249
250
250
All of these tools are very useful for handling large numbers of notifications. Many GitHub power users will simply turn off email notifications entirely and manage all of their notifications through this screen.
Copy file name to clipboardExpand all lines: book/07-git-tools/sections/advanced-merging.asc
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,7 +1,7 @@
1
1
[[_advanced_merging]]
2
2
=== Advanced Merging
3
3
4
-
Merging in Git is typically fairly easy. Since Git makes it easy to merge another branch multiple times, it means that you can have a very long lived branch but you can keep it up to date as you go, solving small conflicts often, rather than be suprised by one enormous conflict at the end of the series.
4
+
Merging in Git is typically fairly easy. Since Git makes it easy to merge another branch multiple times, it means that you can have a very long lived branch but you can keep it up to date as you go, solving small conflicts often, rather than be surprised by one enormous conflict at the end of the series.
5
5
6
6
However, sometimes tricky conflicts do occur. Unlike some other version control systems, Git does not try to be overly clever about merge conflict resolution. Git's philosophy is to be smart about determining when a merge resolution is unambiguous, but if there is a conflict, it does not try to be clever about automatically resolving it. Therefore, if you wait too long to merge two branches that diverge quickly, you can run into some issues.
Now we have a `commits.bundle` file in our directory. If we take that and send it to our partner, she can then import it into the original repository, even if more work has been done there in the meantime.
95
95
96
-
When she gets the bundle, she can inspect it to see what it contains before she imports it into her repository. The first command is the `bundle verify` command that will make sure the file is actually a valid Git bundle and that you have all the neccesary ancestors to reconstitute it properly.
96
+
When she gets the bundle, she can inspect it to see what it contains before she imports it into her repository. The first command is the `bundle verify` command that will make sure the file is actually a valid Git bundle and that you have all the necessary ancestors to reconstitute it properly.
This means that it's easy to share our replacement with others, because we can push this to our server and other people can easily download it. This is not that helpful in the history grafting scenario we've gone over here (since everyone would be downloading both histories anyhow, so why seperate them?) but it can be useful in other circumstances.
187
+
This means that it's easy to share our replacement with others, because we can push this to our server and other people can easily download it. This is not that helpful in the history grafting scenario we've gone over here (since everyone would be downloading both histories anyhow, so why separate them?) but it can be useful in other circumstances.
Copy file name to clipboardExpand all lines: book/07-git-tools/sections/signing.asc
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -178,7 +178,7 @@ Fast-forward
178
178
1 file changed, 2 insertions(+)
179
179
----
180
180
181
-
You can also use the `-S` option with the `git merge` command itself to sign the resulting merge commit itself. The following example both verifies that every commit in the branch to be merged is signed and futhermore signs the resulting merge commit.
181
+
You can also use the `-S` option with the `git merge` command itself to sign the resulting merge commit itself. The following example both verifies that every commit in the branch to be merged is signed and furthermore signs the resulting merge commit.
Copy file name to clipboardExpand all lines: book/07-git-tools/sections/stashing-cleaning.asc
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -212,7 +212,7 @@ Finally, you may not want to stash some work or files in your working directory,
212
212
213
213
Some common reasons for this might be to remove cruft that has been generated by merges or external tools or to remove build artifacts in order to run a clean build.
214
214
215
-
You'll want to be pretty careful with this command, since it's designed to remove files from your working directory that are not tracked. If you change your mind, there is often no retreiving the content of those files. A safer option is to run `git stash --all` to remove everything but save it in a stash.
215
+
You'll want to be pretty careful with this command, since it's designed to remove files from your working directory that are not tracked. If you change your mind, there is often no retrieving the content of those files. A safer option is to run `git stash --all` to remove everything but save it in a stash.
216
216
217
217
Assuming you do want to remove cruft files or clean your working directory, you can do so with `git clean`. To remove all the untracked files in your working directory, you can run `git clean -f -d`, which removes any files and also any subdirectories that become empty as a result. The `-f` means 'force' or "really do this".
0 commit comments