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: quarto_course/skills/paper_planes_git.qmd
+18-41Lines changed: 18 additions & 41 deletions
Original file line number
Diff line number
Diff line change
@@ -12,8 +12,7 @@ Our proxy for work will be small paper planes, made from post-it notes. You can
12
12
13
13
We will set up a table like in the image below, with two spaces for each person: their "working area" (right in front of them) and their "repository" (just further in front).
Git stores full versions of our working areas. This means all the files and folders in our source code project. Git stores full copies of work as it was. In our exercise we will use a folded piece of paper as a proxy. Think of it like a tray on which all our work sits. We will have lots of copies of these workspaces.
18
17
19
18
In this exercise we will be making lots of copies. And that is, fundamentally, how git works. For this reason it is really important that you take the time to make the needed copies.
@@ -24,37 +23,50 @@ Our commit will be a creased piece of paper, with a paper plane on it, together
24
23
25
24
## Sequential work
26
25
27
-
Our first scenario will be sequential work, meaning that the Originator works, then Improver1, then Improver2, but noone working at the same time.
28
-
26
+
Our first scenario will be sequential work, meaning that the Originator works, then Improver1, then Improver2, but none working at the same time.
1. The originator creates a commit, with a basic plane. Mark this with a name (e.g., `VKKF` or `VEDS`) and a comment (e.g., `My first attempt`). Store this in front of you (in your "repository").
2. Improver1 makes a copy of the whole repository (we call this a "clone") into the space in front of them. This means making a copy of the single commit.
3. Improver1 does a "checkout" on that commit. This means making another copy of the commit (including the name, but not the comment) and the paper plane, as a starting point for work.
5. Check this new version into your repository. Cross out the copied version name (just a single line, keep it readable) and write a new name below it (e.g., `VGDU`). That crossed out name now shows the parent. Place this commit to the right of your repository.
11. Improver2 can then commit that work back into their repository. Cross out the existing name (`VGDU`) and create a new name (e.g., `VFFD`), add a comment about the work that you've done.
14. Improver1 should then synchronize with the Originator by making a pull (make a full copy of the new last commit in Originator's repo, and place it in their own repository).
@@ -108,38 +120,3 @@ There are a few ways that projects handle this situation:
108
120
2. "Voting". They group votes and majority rules (the Originator follows the overall wishes)
109
121
3. Configuration. They make the software complex enough to have a run-time configuration setting so that everyone can determine for themselves how it will work.
110
122
4. The project splits ... Improver1 is upset that their change wasn't accepted, they schism and now we have two, incompatible projects out in the world (sometimes called a "hard fork" or an "unfriendly fork".)
111
-
112
-
## Images from earlier (hopefully stil useful)
113
-
114
-
1. Originator invents the paper plane by telling Folder1 what to do. They name it as Version 0.
115
-
116
-

117
-
118
-
2. Improver 1 loves it and asks for one copy. The originator send a copy to Improver 1. 
119
-
120
-
3. Improver 1 invents an improvement, making Version 1. 
121
-
122
-
4. Improver 1 sends their improvement to Originator. Originator make it official.
123
-
124
-
5. Improver 2 gets that improvement along with the original.
125
-
126
-
6. Improver sends their improvement back to Originator, who accepts it, making Version 2 the official version. Now everyone can can work off that version, for future improvements.
127
-
128
-
Everything is hunky dory until Improver 2 takes Version 2 and suggests adding a single flap to each wing, while simultaneously Improver 1 is also working with Version 2 and suggests adding two flaps to each wing.
129
-
130
-

131
-
132
-

133
-
134
-
Originator receives these improvements, sees that they are incompatible.
135
-
136
-

137
-
138
-
Now what?
139
-
140
-
- choose only one to be Version 3 (benevolent dictator choice).
141
-
- make flap number into a configuration variable.
142
-
143
-
Version 3 is released with configuration variable. New improvements start coming in. Some are not problematic, such as wing-tips turned up. But some only work for the one flap config, so the project gets pretty complicated. Originator changes their mind and says that, actually, everything has to be single flap from now on.
144
-
145
-
The double flappers can either adapt or they can take the codebase, and start a new central "clearinghouse" for improvements. A project schism.
0 commit comments