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: content/backups/_index.md
+247-1Lines changed: 247 additions & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -5,4 +5,250 @@ title: "Backing up repositories"
5
5
6
6
# Introduction
7
7
8
-
Your repository doesn't have to _just_ live on your computer -- it's possible to back it up to the cloud (or another computer, or multiple locations on your current computer) and keep the timelines consistent across all of them.
8
+
Your repository doesn't have to _just_ live on your computer -- it's possible to back it up to the cloud (or another computer, or multiple locations on your current computer) and keep the timelines consistent across all of them.
9
+
10
+
11
+
# Making a GitHub account
12
+
13
+
{{% aside %}}
14
+
✋ If you already have a GitHub account, you can [skip this section](#acct-end)
15
+
{{% /aside %}}
16
+
17
+
Follow this link to create a new GitHub account:
18
+
19
+
{{% aside %}}
20
+
🔗 https://github.com/signup
21
+
{{% /aside %}}
22
+
23
+
<aid="acct-end"></a>
24
+
25
+
# Setting up account credentials
26
+
27
+
28
+
Click user icon:
29
+
30
+
31
+
Choose settings:
32
+
33
+
34
+
Choose `SSH and GPG Keys` from the menu on the left (1):
35
+
36
+
37
+
38
+
{{% aside %}}
39
+
✋ If you already have SSH keys listed on this page in your GitHub account, you can [skip the remainder of this section](#key-end)
40
+
{{% /aside %}}
41
+
42
+
Click the green `New SSH Key` button (2), and then minimize your web browser.
43
+
44
+
Open your computer's terminal application -- on Windows with WSL it will be called `Ubuntu`. On MacOS, it's just called `Terminal`. From the terminal, run the following command:
45
+
46
+
```bash
47
+
ssh-keygen
48
+
```
49
+
50
+
Hit the enter key to accept the default values for the questions the tool asks you. This will generate an **SSH key**, which is like a super-powered password that comes in two parts: a _private_ key and a _public_ key. You'll share the public key with GitHub. Run this command, which prints the contents of your public key to the terminal:
51
+
52
+
```bash
53
+
cat ~/.ssh/id_rsa.pub
54
+
```
55
+
56
+
It'll look...well..._incomprehensible_. That's a good thing! We'll never be typing it in ourselves. Select and copy all of the command output (starting with the text `ssh-rsa` and extending all the way down to the blank line).
57
+
58
+
Now, go back to your web browser that was open to GitHub's "Add SSH Key" page and paste the contents into the "Key" box. Give the key indicating which computer you generated it on, and click the green "Add" button:
59
+
60
+
61
+
62
+
Now to test that everything works, go back to your terminal and run the following command:
If you see a warning printed like the text below, just type `yes` and hit enter to continue:
69
+
70
+
```plaintext
71
+
The authenticity of host 'github.com (IP ADDRESS)' can't be established.
72
+
ED25519 key fingerprint is SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU.
73
+
Are you sure you want to continue connecting (yes/no)?
74
+
```
75
+
76
+
Regardless, if things were successful, you'll see a message like this:
77
+
78
+
```plaintext
79
+
Hi [USERNAME]! You've successfully authenticated,
80
+
but GitHub does not provide shell access.
81
+
```
82
+
83
+
If you _don't_ see that message, ask for help before you move on.
84
+
85
+
{{% aside %}}
86
+
ℹ️ In general, we need to repeat this process on any new computer we're using to connect to Github. You can add as many SSH keys as you want to your account.
87
+
{{% /aside %}}
88
+
89
+
<aid="key-end"></a>
90
+
91
+
# Backing our repo up to our GitHub account
92
+
93
+
We need to start by making an empty repository on GitHub's website, which we'll soon fill with all of our work from the solo workflow.
94
+
95
+
From anywhere on GitHub's website, click the plus button at the top-right (1) and select 'New Repository' (2):
96
+
97
+
98
+
99
+
From here, you'll be able to select some options for how your repository will be stored. Make the following choices:
100
+
101
+
- (1) Give the repo the same name as the folder you made in the solo workflow. The two don't _have_ to have the same name, but if they don't it's easy to lose track of which folder on your computer is connected to this cloud backup.
102
+
- (2) Select _Private_ for the repo's visibiltiy. This controls whether the cloud version of the repository will be visible to everyone on the internet, or _just_ to yourself (and any GitHub users you explicitly choose).
103
+
- Leave everything else on the page exactly the same
104
+
105
+
Scroll down and click the green "Create" button:
106
+
107
+
108
+
109
+
You'll be brought to your new repository's **landing page**:
110
+
111
+
112
+
113
+
Now we need to connect our computer's repository (the "local" copy) with this repository (the "remote" copy). This process is called "**adding a remote**". Start by copying the SSH url of the repository on the landing page, as circled on the right below:
114
+
115
+
116
+
117
+
The thing you're copying should start with the text `[email protected]`. If it doesn't, try clicking the `SSH` button as circled on the left first, and then copying the text.
118
+
119
+
Now let's go over to Sublime Merge. Click the "Push" button in the top-right, which is generally used to back up all of the commits on your personal computer to the cloud copy of the repository. It looks like an up arrow:
120
+
121
+
122
+
123
+
Because we haven't connected our computer's "my-journal" repo to the GitHub "my-journal" repo yet, Sublime Merge will ask us a few questions. It'll start with the name of the remote. Enter the name "**origin**", which by convention is the name we use for the primary copy of our repo that lives in the cloud. Type "origin" and hit enter:
124
+
125
+
126
+
127
+
Next, it'll ask for origin's url. This is the text we copied from GitHub. Paste it into the prompt and hit enter:
128
+
129
+
130
+
131
+
Now things should be all connected up. Click the push button again:
132
+
133
+
134
+
135
+
After a minute, we should see a success message like this show up:
136
+
137
+
138
+
139
+
Go back to your repo's landing page on GitHub, and refresh the page. You should see your files there!
140
+
141
+
142
+
143
+
Congratulations, your hard work is backed up to the cloud 🙂 .
144
+
145
+
# Keeping things synced
146
+
147
+
Let's open up the `readme.txt` on our computer and add another fact about ourselves to the bottom:
148
+
149
+
```plaintext
150
+
Celebrity Crush: Katya Zamolodchikova
151
+
```
152
+
153
+
Commit this change to your local repo:
154
+
155
+
156
+
157
+
Now let's go back to the remote repo on GitHub and refresh the page:
158
+
159
+
160
+
161
+
...the change didn't show up. It turns out different copies of the repository don't stay in sync automatically. We always have to manually choose to sync them.
162
+
163
+
{{% aside %}}
164
+
165
+
**⚠️⚠️This is an important point⚠️⚠️⚠️**
166
+
167
+
It's so important, let's repeat it: Changes we make on our local repo won't be reflected on the remote copy until we _push_ them to that copy.
168
+
169
+
{{% /aside %}}
170
+
171
+
This is behavior is really useful! If we screw something up on our local repository, it won't automatically screw up the cloud backup. We could just delete the folder from our computer and download the whole thing again from Git (we'll do that soon in the collaborative workflow).
172
+
173
+
Anyway, let's push our local changes. Click the push button (the up arrow) in the top-right of Sublime Merge again, and then refresh the page. We should now see our recent changes appear:
174
+
175
+
176
+
177
+
But wait, what if we change something on the _GitHub_ copy? (...can we do that?)
178
+
179
+
Click the little pencil icon on the top-right of the README box:
180
+
181
+
182
+
183
+
Add another fun fact about yourself (1) to the readme.txt file and click `Commit changes...` (2):
184
+
185
+
186
+
187
+
GitHub will ask you for a commit message. Enter something in the description box, leave the rest of the settings as-is and click the green "Commit" button:
188
+
189
+
190
+
191
+
Go back to the repo's landing page with the `<> Code` button at the top:
192
+
193
+
194
+
195
+
We'll see our latest commit reflect on the landing page. But now let's go back to Sublime Merge. Things are just as we left them before our GitHub edits:
196
+
197
+
198
+
199
+
To get those changes on our local repo, we have to **pull** them (the opposite of a push!). Click the button with the _down_ arrow (the pull button), right next to the push button we've already used:
200
+
201
+
202
+
203
+
We'll see our new commits appear in the timeline:
204
+
205
+
206
+
207
+
TODO note main vs origin/main
208
+
209
+
# What if we change something on both GitHub _and_ locally?
210
+
211
+
This is beginning to get into where Git both shines as a power tool and also gets _difficult_ to use. Let's jump into it together.
212
+
213
+
Make a commit on GitHub changing `readme.txt`, and make a _different_ change/commit to local `readme.txt`. Add your favorite color to `readme.txt` using GitHub, and add the name of the most recent book you read using your local text editor and Sublime Merge. Make sure to commit the changes in both places.
214
+
215
+
216
+
217
+
Then click the "pull" button in Sublime Merge.
218
+
219
+
You'll see an orange bar appear and an interesting thing happen to the commit timeline:
220
+
221
+
222
+
223
+
The commit log shows us that the repo's main timeline has _diverged_ into two branches 😱🙀🤯
224
+
225
+
On the one hand, we have our "normal" `main` branch showing the commit we made through Sublime Merge (adding the book we read). On the other branch, labeled `origin/main`, we have the commit from GitHub (adding our favorite color). Sublime Merge presents us with four options:
226
+
1.**Merge** - This will accept that the timelines briefly diverged, and add a new commit that "merges" them back into one authoritative timeline. This is the proper way to deal with the divergence.
227
+
2.**Rebase** - This will _rewrite_ the timeline attempting to put things in chronological order as if the commits were all originally made on the local repo. Because this alters history, we try to _avoid_ this option.
228
+
3.**Hard Reset** - This will throw the local commits away entirely, and just make our local repo's timeline look like GitHub's timeline. We don't want to throw away our hard work this time, so we'll go with Merge instead.
229
+
4.**Hide** - This allows `main` and `origin/main` to remain diverged, and any changes we make on either timeline branch will leave the other unaffected. We _really_ don't want this.
230
+
231
+
Click **Merge**, and you'll be presented with some options:
232
+
233
+
234
+
235
+
Leave everything as is, and click the green 'Merge' button.
236
+
237
+
We're almost done, but there is a conflict between versions of the file that Git doesn't know how to resolve:
238
+
239
+
240
+
241
+
We can resolve this conflict exactly the same way we resolved the conflict during the _revert_ process of the solo workflow tutorial. Go into your text editor and fix the conflicted region:
242
+
243
+
244
+
245
+
Now go back into Sublime Merge, stage the changes, and click the "Commit" button to finish the merge:
246
+
247
+
248
+
249
+
At this point, the timelines have been resolved on your local repo, but the remote copy is still lacking your local changes. Click the "push" button to push your changes to GitHub:
250
+
251
+
252
+
253
+
Congratulations, you just dealt with the most common difficult problem you'll encounter while using Git. Hopefully that wasn't so bad! Regardless, you will be come more comfortable with it with practice 🙂.
Copy file name to clipboardExpand all lines: content/solo/_index.md
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -124,7 +124,7 @@ Now we have a journal folder containing our personal profile and our favorite re
124
124
125
125
126
126
127
-
To view the difference between two commits that aren't next to each other in time, hold the control key and select the two commits you want to compare (TODO: command on mac?). Notice the `Diffing from` line in the summary, indicating the point in the timeline we're "comparing" against. Put another way: by selecting multiple commits, the diff view will show us all of the changes that happened between those points in the timeline:
127
+
To view the difference between two commits that aren't next to each other in time, hold the control key (or on MacOS, the command key) and select the two commits you want to compare. Notice the `Diffing from` line in the summary, indicating the point in the timeline we're "comparing" against. Put another way: by selecting multiple commits, the diff view will show us all of the changes that happened between those points in the timeline:
0 commit comments