diff --git a/.gitkit-cspell.txt b/.gitkit-cspell.txt
index 840d6ba..3e826b8 100644
--- a/.gitkit-cspell.txt
+++ b/.gitkit-cspell.txt
@@ -1,5 +1,4 @@
automations
-devenv
farmdata
foss
gitkit
@@ -9,7 +8,6 @@ halign
HFOSSedu
inclusivity
kitclient
-nbsp
opensource
POGIL
Runestone
diff --git a/README.md b/README.md
index 3c71d5c..7729e19 100644
--- a/README.md
+++ b/README.md
@@ -2,7 +2,9 @@
This repository contains the pretext source for the GitKit Runestone texts.
-If you are interested in using the GitKit Text please see the Instructor Guide in the text on Runestone by using one of the following link: [GitKit](https://runestone.academy/ns/books/published/gitkitlinux/the-gitkit-book.html?mode=browsing)
+If you are interested in using the GitKit Text please see the Instructor Guide in the text on Runestone by using one of the following links:
+- [GitKit (Linux Desktop Edition)](https://runestone.academy/ns/books/published/gitkitlinux/the-gitkit-book.html?mode=browsing) - students work in a full Linux desktop environment in this edition.
+- [GitKit (VSCode Edition)](https://runestone.academy/ns/books/published/gitkitvscode/the-gitkit-book.html?mode=browsing) - students work within the VSCode IDE in this edition.
## Licensing
@@ -299,19 +301,76 @@ An `` containing ``s can be used to create a question with multi
Note:
- Fill-in questions are not currently suported within a ``. A [free response question](https://runestone.academy/ns/books/published/PTXSB/rune-20.html) (with [source](https://runestone.academy/ns/books/published/PTXSB/rune-20.html)) should be used instead. Note that the free response box only renders when running in Runestone. This is because free response must be hand graded and cannot be auto checked in a static web deploy. See [Using a fill in the blank exercise in a task](https://groups.google.com/g/pretext-support/c/VWLb_W0AT18) for updates on this issue.
-#### Text Versions
+#### Adding Version Specific Content
-There are 3 versions of the text that can be built:
+There are 10 versions of the text that can be built:
-- `web` - An HTML version of the text. This will some but not all of the interactive Runestone question types.
-- `print` - A PDF version of the text.
-- `runestone` - The version built to be served by Runestone Academy.
+- `student-web-linux` and `student-print-linux` - The Linux KitClient book as students will see it.
+- `student-web-vscode` and `student-print-vscde` - The VSCode KitClient book as students will see it.
+
+- `instructor-web-linux` and `instructor-print-linux` - The Linux KitClient book including notes to the instructor (see below).
+- `instructor-web-vscode` and `instructor-print-vscode` - The VSCode KitClient book including notes to the instructor (see below).
+
+- `web` and `print` - same as the instructor Linux version. This is included for the CodeChat preview.
##### Building a Specific Version
Any of these versions can be built using "Build another target..." option on the `PreTeXt` menu or by using terminal commands similar to:
```text
-pretext build web
-pretext view web
-```
\ No newline at end of file
+pretext build instructor-web-linux
+pretext view instructor-web-linux
+```
+
+##### Adding KitClient Specific Content
+
+Content specific to a given kit client is indicated by adding a `component` attribute to to divisions/elements as follows:
+
+```
+
+ This text appears only in the Linux Kit Client versions.
+
+
+
+ This text appears only in the VSCode Kit Client versions.
+
+```
+
+- If a division/element will appear only in the `linux` or `vscode` version of the text its `xml:id` should have a suffix indicating its version.
+- If two divisions/elements provide alternate content for the `linux` and `vscode` versions their `xml:ids` will be the same except for the suffix.
+
+##### Instructor Version Content
+
+A `commentary` element with the `component="instructor"` attrribute is used to add instructor guide information directly to the source text as follows:
+
+```xml
+
+
+
+
+
+
+ Instructor Note:: Information for the instructor appears here.
+
+
+
+
+
+```
+
+Note:
+- The `` is included to place all comments for the instructor into a box.
+
+##### Defining a Version
+
+The available versions are defined by the ``s in the `project.ptx` file. Each `` references a `.ptx` file in the `publication` folder that indicates the content that will appear in the version.
+
+##### Publishing a Version
+
+Runestone does not currently support the publication of different versions of a text from a single repository. Instead, the solution is to create a fork of this repository. Then in that repository change the `publication` file that is the `target` of the `runestone` target to point to the `publication` file for the version that you would like to publish. Then create a new Runestone text using that repository.
+
+See the [GitKit-VSCode Repository](https://github.com/HFOSSedu/GitKit-VSCode) for an example. That repository also includes information about how to update it from this repository when edits are made.
diff --git a/materials/images/GitKit-Text-Soure-Images.pptx b/materials/images/GitKit-Text-Soure-Images.pptx
index cfd38e2..54728fd 100644
Binary files a/materials/images/GitKit-Text-Soure-Images.pptx and b/materials/images/GitKit-Text-Soure-Images.pptx differ
diff --git a/materials/slides/Ch5-MergeConflicts.pptx b/materials/slides/Ch5-MergeConflicts.pptx
index e3099ca..f6e8aab 100644
Binary files a/materials/slides/Ch5-MergeConflicts.pptx and b/materials/slides/Ch5-MergeConflicts.pptx differ
diff --git a/project.ptx b/project.ptx
index 3f2fabc..a930d8c 100644
--- a/project.ptx
+++ b/project.ptx
@@ -2,10 +2,27 @@
-
-
+
+
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/publication/publication-instructor-linux.ptx b/publication/publication-instructor-linux.ptx
new file mode 100644
index 0000000..f07770e
--- /dev/null
+++ b/publication/publication-instructor-linux.ptx
@@ -0,0 +1,141 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/publication/publication-instructor-vscode.ptx b/publication/publication-instructor-vscode.ptx
new file mode 100644
index 0000000..4b85f3e
--- /dev/null
+++ b/publication/publication-instructor-vscode.ptx
@@ -0,0 +1,141 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/publication/publication-linux.ptx b/publication/publication-linux.ptx
new file mode 100644
index 0000000..6e00d3c
--- /dev/null
+++ b/publication/publication-linux.ptx
@@ -0,0 +1,140 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/publication/publication-runestone.ptx b/publication/publication-runestone-linux.ptx
similarity index 96%
rename from publication/publication-runestone.ptx
rename to publication/publication-runestone-linux.ptx
index ee1f54c..f8600a2 100644
--- a/publication/publication-runestone.ptx
+++ b/publication/publication-runestone-linux.ptx
@@ -34,6 +34,7 @@
+
@@ -88,8 +89,12 @@
diff --git a/publication/publication-runestone-vscode.ptx b/publication/publication-runestone-vscode.ptx
new file mode 100644
index 0000000..7ff25c8
--- /dev/null
+++ b/publication/publication-runestone-vscode.ptx
@@ -0,0 +1,125 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/publication/publication-example.ptx b/publication/publication-student-linux.ptx
similarity index 97%
rename from publication/publication-example.ptx
rename to publication/publication-student-linux.ptx
index 913a4e4..fe0593b 100644
--- a/publication/publication-example.ptx
+++ b/publication/publication-student-linux.ptx
@@ -21,7 +21,7 @@
-
+
@@ -34,6 +34,7 @@
+
@@ -60,7 +61,7 @@
-
+
@@ -69,7 +70,7 @@
-
+
diff --git a/publication/publication-student-vscode.ptx b/publication/publication-student-vscode.ptx
new file mode 100644
index 0000000..e2c843d
--- /dev/null
+++ b/publication/publication-student-vscode.ptx
@@ -0,0 +1,141 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/publication/publication-vscode.ptx b/publication/publication-vscode.ptx
new file mode 100644
index 0000000..d6aaf27
--- /dev/null
+++ b/publication/publication-vscode.ptx
@@ -0,0 +1,140 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/publication/publication.ptx b/publication/publication.ptx
index 2168e70..913a4e4 100644
--- a/publication/publication.ptx
+++ b/publication/publication.ptx
@@ -21,7 +21,7 @@
- DRAFT FOR REVIEW ONLY
+
@@ -60,7 +60,7 @@
-
+
@@ -69,7 +69,7 @@
-
+
@@ -104,8 +104,12 @@
diff --git a/source/ch-communities-and-collaboration/ch-communities-and-collaboration.ptx b/source/ch-communities-and-collaboration/ch-communities-and-collaboration.ptx
index 616af94..9622b73 100644
--- a/source/ch-communities-and-collaboration/ch-communities-and-collaboration.ptx
+++ b/source/ch-communities-and-collaboration/ch-communities-and-collaboration.ptx
@@ -19,7 +19,7 @@
-
+
diff --git a/source/ch-communities-and-collaboration/images/DevEnv-Blank-Ready.png b/source/ch-communities-and-collaboration/images/DevEnv-Blank-Ready.png
deleted file mode 100644
index f63c3f7..0000000
Binary files a/source/ch-communities-and-collaboration/images/DevEnv-Blank-Ready.png and /dev/null differ
diff --git a/source/ch-communities-and-collaboration/images/DevEnv-Request-PAT.png b/source/ch-communities-and-collaboration/images/DevEnv-Request-PAT.png
deleted file mode 100644
index 8ab2171..0000000
Binary files a/source/ch-communities-and-collaboration/images/DevEnv-Request-PAT.png and /dev/null differ
diff --git a/source/ch-communities-and-collaboration/sec-cloning-your-origin.ptx b/source/ch-communities-and-collaboration/sec-cloning-your-origin.ptx
index b0cff98..173309f 100644
--- a/source/ch-communities-and-collaboration/sec-cloning-your-origin.ptx
+++ b/source/ch-communities-and-collaboration/sec-cloning-your-origin.ptx
@@ -1,724 +1,520 @@
-
+Cloning Your Origin
-
- The next step in the basic FOSS workflow is to ensure that you have a clone of your origin repository in your development environment as shown in .
- Having a clone of your origin in your development environment will allow you to edit the files to fix the issue that you have been assigned and add those changes to the repository.
+
+ The next step in the basic FOSS workflow is to ensure that you have a clone your origin repository in your development environment as shown in . Having a clone of your origin in your development environment will allow you to edit the files to fix the issue that you have been assigned and add those changes to the repository.
-
-
Cloning your origin repository from your GitHub space to your development environment.
+
+
+ Cloning your origin repository from your GitHub space to your development environment.
+
-
- Creating a clone of your origin repository creates a copy of it in your development environment.
- This copy is your local copy.
+ Creating a clone of your origin repository creates a copy of it in your development environment. This copy is your local copy.
-
-
-
- Clone URL
-
-
- In order to clone a repository into your development environment you will need the clone URL for that repository.
- The steps in this section will help you find the clone URL for your origin repository.
+
+ In some development environments cloning the origin requires that you use a command like git clone <originURL>.git to create the clone.
-
-
-
-
-
-
- Visit the GitHub page for your origin repository.
-
-
-
-
-
- You can find the URl of your origin (i.e.
- your fork of the GitKit FarmData2 upstream) in your answer to .
-
-
-
-
-
-
-
- Find and click the green "Code" button.
-
-
- The green "Code" button in GitHub.
-
-
-
-
-
-
-
-
-
- Open the "Local" and "HTTPS" tabs as shown here:
-
- The GitHub dialog showing the clone URL.
-
-
- The URL in the "Clone using the web URL" box is the clone URL that you will need to clone your origin repository.
-
-
-
-
-
-
-
- Copy and paste the clone URL that you will use to clone your origin as your answer to this exercise.
-
-
-
-
-
-
-
-
-
- Thank you.
-
-
-
-
-
-
- It looks like you might be trying to use the upstream repository instead of your origin.
-
-
-
-
-
-
- It looks like you might be trying to use the upstream repository instead of your origin.
-
-
-
-
-
-
- The clone URL should have the format https://github.com/yourGitHubUsername/theRepoName.git.
-
-
-
-
-
-
- Be sure you are using your GitHub origin repository (see ).
- This clone URL should contain your GitHub username and end in .git.
-
-
-
-
-
-
-
-
-
- <c>git clone</c>
-
-
- The git clone command will make a copy of your fork on GitHub and make the Local Copy on your computer (in your development environment).
- Refer to Figure.
-
-
-
- Now that you have the clone URL for your origin repository, use the steps in this section to clone your origin into your development environment.
-
-
-
-
-
-
-
-
- The git clone <URL> command is used to clone your origin repository into your development environment.
-
-
- Give a command that will clone your origin into your development environment.
+
+ However, the development environment you have opened in GitPod simplifies this process for you. Recall, that you provided the URL of your origin repository when opening the development environment in . When you did that, a clone of your origin was automatically created for you in your development environment.
-
-
-
-
-
-
-
- Thank you.
-
-
-
-
-
-
- It looks like you might be trying to use the upstream repository instead of your origin.
-
-
-
-
-
-
- It looks like you might be trying to use the upstream repository instead of your origin.
-
-
-
-
-
-
- Be sure to replace <URL> with the clone URL you found in . The clone URL should have the format https://github.com/yourGitHubUsername/theRepoName.git.
-
-
-
-
-
-
- Execute your command from in your terminal.
-
-
-
-
-
-
- Which of the following appear in the output from entering the command from ?
-
- Look for a line in the output that begins with "Cloning into".
-
-
-
-
-
-
-
- Use the ls command to confirm that the directory you identified in now exists.
-
-
-
- If it it does not, check the output in for error messages and try again.
-
-
-
-
-
-
-
- Exploring Your Cloned Repository In Your Development Environment
-
-
- In this section you will briefly explore the GitKit FarmData2 repository that you have cloned into your development environment.
-
-
-
-
-
-
-
- Use the cd command in the Terminal to change into the directory containing your clone of the GitKit FarmData2 repository.
-
-
-
- See for the name of the directory.
-
-
-
+
-
-
-
- Use the ls -a command to display the names of all of the files and directories in your clone of the GitKit FarmData2 repository.
-
+
+
+
-
- Compare these files and directories to those in your origin repository on GitHub.
-
-
- Check all files and directories that do not appear both locally and on GitHub.
-
-
-
-
+
+
+ In order to clone a repository into your development environment you will need the clone URL for that repository. The steps in this exercise will help you find the clone URL for your origin repository.
+
+
- .
+ Visit the GitHub page for your origin repository.
-
-
-
-
+
- ..
+ You can find the URl of your origin (i.e. your fork of the GitKit FarmData2 upstream) in your answer to .
-
-
-
-
+
+
+
- .git
+ Find and click the green "Code" button.
+
+
+
+ The green "Code" button in GitHub.
+
+
-
-
-
+
+
- README.md
-
-
-
+ Open the "Local" and "HTTPS" tabs as shown here:
-
-
-
- .kit
-
-
-
-
-
-
- .vscode
+
+
+ The GitHub dialog showing the clone URL.
+
+
+
+ The URL in the "Clone using the web URL" box is the clone URL that you will need to clone your origin repository.
-
-
-
-
-
-
-
-
-
-
-
-
-
- <c>git remote</c>
-
-
- In this section you will see that your clone keeps track of the location of your origin repository.
- It does this using a piece of information called a remote, which Git uses to store the URLs of remote repositories in the cloud (e.g.
- on GitHub).
-
-
-
- The command git remote on its own will show you the names of the remotes that git knows about, but not their URLS.
-
-
-
- If you want to have git display the URLs of the remotes as well, you will need to add the -v or --verbose flag: git remote -v
-
+
+
-
-
-
-
-
- Which command will show you the URL(s) of the remote(s) that git knows about?
-
+
+
+
+ Copy and paste the clone URL that you will use to clone your origin as your answer to this exercise.
+
+
+
+
-
-
-
-
- git remote -v
-
-
-
+
+
+
+
+
+
+ Thank you.
+
+
+
+
+
+
+ It looks like you might be trying to use the upstream repository instead of your origin.
+
+
+
+
+
+
+ It looks like you might be trying to use the upstream repository instead of your origin.
+
+
+
+
+
+
+ The clone URL should have the format https://github.com/yourGitHubUsername/theRepoName.git.
+
+
+
+
+
+
+ Be sure you are using your GitHub origin repository (see ). This clone URL should contain your GitHub username and end in .git.
+
+
-
+
+
+
+ Now that you have the clone URL for your origin repository, use the tasks in this exercise to clone your origin into your development environment.
+
+
+
- git remote
+ Use the following command in the Terminal to clone your origin repository into your development environment:
-
-
-
-
-
- git remote -url
+ git clone <clone URL>
-
-
-
-
-
- git url
+ Be sure to replace <clone URL> with the clone URL you found in .
-
-
-
-
-
- You are asking git remote to give you more information.
-
-
-
-
-
-
-
- Execute the command git remote -v in your terminal. How can you tell from that output that your clone knows about your origin?
-
-
-
-
-
+
+
-
- The "origin" lines have a URL with your GitHub username in them.
-
+ Copy and paste the output from your command in as your answer here.
-
-
-
+
+
+
+ Examine the output in . Into which directory in your development environment was your GitKit FarmData2 origin cloned?
+
+
+
- There are lines that say "origin".
+ Look for a line in the output that begins with "Cloning into".
-
-
-
-
+
+
+
- The "origin" lines have a URL that points to GitHub.
+ Use the ls command to confirm that the directory you identified in now exists.
-
-
-
-
-
- It is not possible to tell from the output.
+ If it it does not, check the output in for error messages and try again.
-
-
-
-
-
- Look closely at the "origin" URLs.
-
-
-
+
+
-
-
-
- How is the origin remote that you see in the output of the command represented in ?
-
-
+
+
+
+ The the output in should contain a message from the Kit-tty. What is the Kit-tty?
+
+
+
+
+
+ The "Kit-tty" introduces itself using the line
+ "😺💻 Meow, Kit-tty here!" Read the description of the "Kit-tty" that follows this line.
+
+
+
+
+ Be sure to keep your eyes open for messages from the Kit-tty as you work on the GitKit exercises. The Kit-tty will help you to stay on track and may save you a lot of time by preventing you from going down an incorrect path.
+
-
-
+
+
+
+ Use the final line of output in that begins with "IMPORTANT" to complete this exercise.
+
+
+
- The orange dotted arrow from the clone to the origin repository.
+ What does the "IMPORTANT" line ask you to do?
-
-
-
+
+
+
+
+ Close the terminal and open a new one.
+
+
+
+
+
+
+ Take the Kit-tty for a walk.
+
+
+
+
+ I'm sure the Kit-tty would like that, but its not the correct answer.
+
+
+
+
+
+
+ Use the git clone command.
+
+
+
+
+
+
+ Delete some unnecessary files.
+
+
+
+
+
+
- The orange dotted arrow from the origin to the upstream repository.
+ If you haven't already, close the Terminal you are currently using and open a new one.
-
-
-
-
-
- The orange dotted arrow from the clone to the upstream repository.
+ There is a technical reason for having to close your current Terminal and open a new. But the details for why this is necessary are unimportant.
-
+
+
-
+
+
+
+ In this exercise you will briefly explore the GitKit FarmData2 repository that you have cloned into your development environment.
+
+
+
- The blue "Clone" arrow from the origin to the cloned repository.
+ Use the cd command in the Terminal to change into the directory containing your clone of the GitKit FarmData2 repository.
-
-
-
-
+
- The origin remote is not represented in the figure.
+ See for the name of the directory.
-
-
-
-
-
-
- Which arrow would represent the clone knowing the location of the origin?
-
-
-
-
-
-
-
- Which step of the basic FOSS workflow requires that your clone know the location of your origin repository?
-
-
-
-
-
-
+
+
+
- Pull request
+ Use the ls -a command to display the names of all of the files and directories in your clone of the GitKit FarmData2 repository.
-
-
-
-
-
- Fork
+ Compare these files and directories to those in your origin repository on GitHub. Are there any differences? If so describe them here.
-
+
+
+
-
-
-
- Clone
-
-
-
+
+
+
+
+ The development environment displays the files and directories contained in your clone in the "Explorer" panel at the left of the window. You can also see a list of these files and directories by using the ls -a command in the Terminal.
+
+
+ Compare these files and directories to those in your origin repository on GitHub. Are there any differences? If so describe them here.
+
+
+
+
-
+
+
+
+
+ In this exercise you will see that your clone keeps track of the location of your origin repository. It does this using a piece of information called a remote, which Git uses to store the URLs of remote repositories in the cloud (e.g. on GitHub).
+
+
+
- Edit
+ Use the following command to ask Git to display a list of the remote repositories (i.e. those on GitHub) that it knows about:
-
-
-
-
-
- Push
+ git remote -v
-
-
-
-
-
-
- Think about which step of the basic FOSS workflow will need to send information from the clone back to the origin.
-
- You cloned your GitKit-FarmData2 respitory into a folder in your development environment with the command in .
-
-
-
- But, you need to reopen your development environment in that folder to take advantage of all of the features that the KitClient provides for you.
-
-
-
-
-
-
-
-
- Open the GitKit-FarmData2 folder.
-
-
- You can do this by going to the "hamburger" (≡) menu in the upper left of your development environment window.
-
-
- Choose File > Open Folder...
-
-
- Select the GitKit-FarmData2 folder and click OK.
-
-
- You will see Setting up your Codespace, and then your terminal will show a message from the Kit-tty.
-
-
-
-
-
-
-
- The the output in should contain a message from the Kit-tty.
- What is the Kit-tty?
-
-
-
-
-
- Your personal virtual assistant.
+ Copy and paste the output of the git remote -v command here.
-
+
+
-
+
- A terminal.
+ Examine the output in . How can you tell from that output that your clone knows about your origin?
-
+
+
+
+
+ The "origin" lines have a URL with your GitHub username in them.
+
+
+
+
+
+
+ There are lines that say "origin".
+
+
+
+
+
+
+ The "origin" lines have a URL that points to GitHub.
+
+
+
+
+
+
+ It is not possible to tell from the output.
+
+
+
+
+
+ Look closely at the "origin" URLs.
+
+
-
+
- A teletypewriter.
+ How is the origin remote that you see in the output of the command represented in ?
-
+
+
+
+
+ The orange dotted arrow from the clone to the origin repository.
+
+
+
+
+
+
+ The orange dotted arrow from the origin to the upstream repository.
+
+
+
+
+
+
+ The orange dotted arrow from the clone to the upstream repository.
+
+
+
+
+
+
+ The blue "Clone" arrow from the origin to the cloned repository.
+
+
+
+
+
+
+ The origin remote is not represented in the figure.
+
+
+
+
+
+ Which arrow would represent the clone knowing the location of the origin?
+
+
-
-
+
+
- A pet kitten.
+ Which step of the basic FOSS workflow requires that your clone know the location of your origin repository?
-
-
-
-
- The "Kit-tty" introduces itself using the line "😺💻 Meow, Kit-tty here!" Read the description of the "Kit-tty" that follows this line.
-
-
-
-
-
-
- Be sure to keep your eyes open for messages from the Kit-tty as you work on the GitKit exercises.
- The Kit-tty will help you to stay on track and may save you a lot of time by preventing you from going down an incorrect path.
-
- You have been assigned an issue to work on and you have created a fork of the upstream GitKit FarmData2 repository into your GitHub space.
+ You now have been assigned an issue to work on and yuu have created a fork of the upstream GitKit FarmData2 repository into your GitHub space.
- To work on your issue you will need to setup a development environment. The development environment is where you will create your clone of the repository, where you will edit files, and where you will use Git commands to add your changes to your clone and push those changes to your origin.
+ To work on your issue you will need to setup your development environment. Your development environment is where you will create your clone of the repository, where you will edit files, and where you will use `git` commands to add your changes to to your clone and push those changes to your origin.
- Many FOSS contributors will setup the development environment on their personal machines. However, because student machines vary greatly the GitKit provides a browser based development environment that you will access using your web browser. This development environment is guaranteed to be the same for everyone that uses it. It includes a code editor, development tools, and a few features designed specifically to help you stay on track when completing the GitKit's hands-on exercises.
-
-
- In this section you will create a new development environment, learn how to stop and restart the development environment, and do some necessary configuration of Git.
+ Many FOSS contributors will setup the development environment on their personal machines. Because student machines vary greatly the GitKit provides a browser based development environment, called a KitClient. This development environment runs in the cloud and you will access it using your web browser. This development environment includes standard development tools but also has a few features designed specifically to help you stay on track when completing the GitKit's hands-on exercises.
-
- Creating the Development Environment
+
+ Starting the Development Environment
- The development environment will run in the cloud using a service called GitHub Codespaces, and you will access it using your web browser.
+ In this section you will learn how to start, configure, stop, and restart your development environment.
+ Your development environment will run in the cloud using a service called GitPod. Visit and login using the “Continue with GitHub” button and providing your GitHub username and password.
+
- The following tasks will guide you through the process of creating the development environment.
+ The following tasks will guide you through the process of starting and configuring your development environment.
- Click this link to create the Development Environment.
+ Choose "Terminal" as the "Editor - Browser" and "Standard" as the machine "Class" as shown here:
+
+
+ Creating the local development environment in GitPod.
+
+
-
-
+
- Click the "Create new codespace" button on the page that appears.
+ Click the "Continue" button and wait for a few minutes until output that is similar to that shown here to appear:
+
+
+ *********************************************************************************
+ *********************************************************************************
+ Connect to the KitClient with your browser at:
+ https://6901-hfossedu-kitclientlinux-kkguybiovbj.ws-us115.gitpod.io
+ *********************************************************************************
+ *********************************************************************************
- Wait for the development environment to be created. Your browser window will refresh and change a few times during the creation process. Please be patient as this can take a few minutes.
-
-
- After a few minutes, your browser window will look similar to including the prompt asking you to paste your GitHub Personal Access Token (PAT).
-
-
-
-
- The GitKit development environment prompting for a GitHub PAT during creation.
-
-
-
- The GitKit Development Environment prompting for a GitHub PAT during creation.
-
-
-
-
-
- If you do not see the prompt asking you to paste your PAT after a few minutes try:
-
-
-
- Reloading your browser tab.
-
-
-
-
- Clearing your browser cache and reloading your browser tab.
-
-
-
-
- Checking that your browser is fully supported by Codespaces.
-
-
-
+ Click the link in your output that is similar to the one that is shown above.
-
+ xml:id="ex-create-kit-client-linux-e"
+ label="ex-create-kit-client-linux-e">
- Paste the PAT that you created in and press enter. Note, for security reasons your PAT is not displayed when it is pasted.
+ Click the "Connect" button that appears in your browser.
+
- If you have lost or did not save your PAT, revisit and create a new one.
+ After clicking the "Connect" button your development environment should open in the browser. It will appear similar to the window shown in .
-
-
-
-
- After pasting your PAT, the development environment will finish being created. When the development environment is fully created your browser window will look similar to including the "Kit development environment is ready for use" message.
+
+
+ The development environment.
+
+
+
+ The development environment window displaying a Linux desktop.
+
+
+
-
-
-
- The GitKit development environment with the "Kit development environment is ready for use" message.
-
-
-
- The GitKit Development Environment with the "Kit development environment is ready for use" message.
-
-
-
-
-
-
- Stopping the Development Environment
-
-
- At some point you will complete an assignment or want to take a break and do other things. When you do so, you should stop the development environment. This will ensure that you do not consume more of your free Codespaces time than necessary.
-
- Use the following steps to practice stopping the development environment.
+ There are a few additional things that you can to to make working in your development environment more convenient.
-
+
- Click on the word "Codespaces" in the bottom left of the browser window.
-
+ Use the following steps to make the development environment fill and resize with your browser window.
+
+
+
+ Open the "noVNC Menu" by clicking the little tab at the left edge of the development environment window. shows the "noVNC Menu" opened.
+
+
+ Click "Gear Icon" to open the "noVNC Settings". shows the "noVNC Settings" open.
+
+
+ Set the "Scaling Mode" to "Remote Resizing".
+
+
-
+
- Select "Stop Current Codespace" from the menu that appears in the top center of the browser window.
+ To simplify pasting answers into this text, it is recommended that you open the text using the Firefox browser within the local development environment.
-
-
-
-
- Close the browser tab containing the development environment.
+ Copy and paste within the development environment can be done via an application's "Edit" menu, the "right click" menu, or keyboard shortcuts. This tutorial on Copy and Paste on Linux may be helpful if you are not a Linux user.
+
+
+ Copy and paste between your host machine and the development environment can be done, but it requires that you paste the content into the "Clipboard" on the "noVNC Menu".
-
-
-
- Re-starting the Development Environment
-
-
- When you return to work after stopping the development environment, you will need to restart it.
-
- Use the following steps to restart the development environment.
+ The following tasks will guide you through the process of starting and configuring your development environment.
-
+
+
- Click here to open your development environment.
+ Click this link to
+ Launch KitClient in GitPod.
- Click the "Resume this codespace" button.
+ Paste the URL of your GitKit FarmData2 repository from into the text box and press "Enter".
+
+
+
+
+
- Do not click the "Create a new one" button because a new development environment will not contain any of your prior work.
+ Choose "VS Code..." as the "Editor - Browser" and "Standard" as the machine "Class" as shown here:
+
+
+
+ Creating the development environment in GitPod.
+
+
- Please be patient as this can take a few minutes. When the development environment is ready you will see the message "Kit development environment is ready for use" and your browser window will look similar to .
+
+ Click the "Continue" button and wait for the development environment to open in the browser. It will appear similar to the window shown in .
+
+
+
+ The development environment.
+
+
+
+ The development environment window showing the VS Code interface.
+
+
+
+
+
+
-
-
- The GitKit Development Environment. The development environment is ready when you see the "Kit development environment is ready for use" message.
-
-
-
- The GitKit Development Environment. The development environment is ready when you see the "Kit development environment is ready for use" message.
-
-
-
+
+
+
+ A message box may appear in the lower right corner of the development environment asking if you would like to reopen the project in "VS Code Desktop". If this happens you can click the "X" to close the box, or ignore it and it will go away on its own.
+
+
+
+
+
+ In the "TERMINAL" tab at the bottom of the window you should see "😺💻 Meow, Kit-tty here!" in the output. Read the associated text.
+
+ What is the Kit-tty?
+
+
+
+
+ Everything you need to know about Kit-tty for now is in the text that appears in the "TERMINAL" tab.
+
+
+
-
- The Git Client
+
+ Configuring the Git Client
Your development environment includes a Git client. The Git client is the tool that you will use to interact with Git repositories, such as the GitKit FarmData2 repository.
- There are lots of different Git clients. Some are graphical and some use a text interface. These exercises, introduce you to Git using the text-based Git command line interface (CLI). This is the most general way to interact with Git and will provide a conceptual foundation for using any other Git client that you might encounter.
+ There are lots of different Git clients. Some are graphical and some use a text interface. These exercises, introduce you to Git using its text-based command line interface (CLI). This is the most general way to interact with Git and will provide a conceptual foundation for using any other Git client that you might encounter.
- The Git CLI is accessed by using the git command in the terminal.
+ You will interact with Git using its command line interface via a Terminal. Use the following steps to open a Terminal.
- Using the git command without any additional arguments displays information about how to use git.
+ Click the "Terminal" icon at the bottom of the development environment window to open a new Terminal.
+
+
+
+
- Enter the command git into the terminal in the development environment and press enter.
+ Enter your name at the prompt and press enter. This will customize the Terminal prompt for you.
+
+
+
+
+
+
+ You will interact with Git using its command line interface via a Terminal. Use the following steps access the Terminal.
+
+
+ Click on the "TERMINAL" tab near the bottom of the development environment window to make the Terminal active.
+
+
+
+
+
+ You can learn about the git command by running it without any additional arguments.
+
+ xml:id="ex-git-version-a"
+ label="ex-git-version-a">
- Use the output from the git command in to determine which of the following commands will cause, git to "Show the working tree status."
+ Enter the command git into the Terminal.
-
-
+
+
- git status
+ Give a git command that will cause ,git to display its version.
+
-
+
- The git status command causes git to display the status of the working tree.
+ Use the output from to determine what flag to pass to git.
-
-
-
+
+
+
- git tree
+ What version of the git command line client is installed in your development environment?
+
-
+
- Check the output of the git command.
+ Use the command that you identified in to determine the git version.
-
-
-
+
+
+
+
+
+
+
+ Recall from class that Git repositories maintain a complete history of all changes, including who made each change. To do this, Git needs to know a little bit of information about you.
+
+
+ Git identifies the author of each change using two pieces of information: A name and an e-mail. For name, you might decide to your full name, or a nickname, or your GitHub username. Just keep in mind that whatever name you use will be associated with all of the changes you make. For e-mail, you can again use any valid e-mail associated with you.
+
+
+ The tasks in this exercise will guide you through the process of configuring the Git client in your development environment.
+
+
+
- git working-tree
+ Use the following command to set the name that Git will associate with your changes:
-
-
- Check the output of the git command.
+ git config --global user.name "<name>"
-
-
-
+
+ Replace "<name>" with the name you wish to use and be sure not to include the < and >.
+
+
+
+
- git show
+ Use the following command to set the e-mail that Git will associate with your changes:
+
+
+ git config --global user.email "<e-mail>"
+
+
+ Replace "<e-mail>" with the name you wish to use and be sure not to include the < and >.
-
+
+
+
- Check the output of the git command.
+ Use the following command to display Git's global configuration including the two new settings you just added:
-
-
-
-
- Check the output of the git command for the command that will "Show the working tree status."
+ git config --global --list
-
+
+ Give the output of this command as your answer for this task.
+
+
+
-
- Configuring the Git Client
+
+ Adjusting some GitPod Settings
- Git repositories maintain a complete history of all changes, including who made each change. To do this, Git needs to know a little bit of information about you.
-
-
- Git identifies the author of each change using two pieces of information: A name and an email. For name, you might decide to use your full name, or a nickname, or your GitHub username. Just keep in mind that whatever name you use will be associated with all of the changes you make. For email, you can use any valid e-mail associated with you.
-
-
- The exercises in this section will guide you through the process of configuring your name and email in the Git client in the development environment.
+ There are a few GitPod settings that you can change that will make working with your development environment more convenient.
-
-
-
-
-
-
- The git config --global user.name "<name>" command sets the name that Git will associate with your changes.
-
-
- Give a command that will set the name you want to have associated with your changes by replacing <name> with the name you wish to use.
-
-
-
-
-
-
-
-
-
-
- This command will set the name associated with your changes in git.
-
-
-
-
-
-
- You should not include the < and > in your command.
-
-
-
-
-
-
- Be sure to use quotation marks around your name.
-
-
-
-
-
-
- Reread the question and check the format of your command.
-
-
-
-
-
-
-
-
-
-
- The git config --global user.email "<email>" command sets the email address that Git will associate with your changes.
-
-
- Give a command that will set the email you want to have associated with your changes by replacing <email> with the email address you wish to use.
-
-
-
-
-
-
-
-
-
-
- This command will set the email associated with your changes in git.
-
-
-
-
-
-
- Be sure you have entered a valid email address.
-
-
-
-
-
-
- You should not include the < and > in your command.
-
-
-
-
-
-
- Be sure to use quotation marks around your email.
-
-
-
-
-
-
- Reread the question and check the format of your command.
-
-
-
-
-
-
-
+
-
-
- Enter your commands from and into the Terminal.
-
- Then use the command git config --global --list to display the Git configuration. Examine the output and select all of the Git configuration keys that have values assigned to them.
+ Use the following steps to adjust your GitPod settings.
-
-
-
+
+
- user.name
+ Open your GitPod workspaces in a browser by visiting .
-
+
+
+
- user.name should be set to the name you used above.
+ Choose "Rename" from the "⋮" (three vertical dots) menu to the right of the KitClient workspace and rename the workspace to be "GitKit Dev Env" or something else that you will remember easily.
-
-
-
+
+
+
- user.email
+ Click the "Pushpin" icon, or choose "Pin" from the "⋮" (three vertical dots) menu to the right of the "GitKit Dev Env" workspace.
+
+
+ This will Pin your GitKit workspace making it easier to find, and will also prevent it from becoming inactive or being deleted if you don't use it for a few days.
-
+
+
+
- user.email should be set to the email you used above.
+ Open your GitPod preferences in a browser by visiting .
-
-
-
+
+
+
- core.editor
+ Set your “Timeout” to 10 minutes. This will stop your development environment if you are away from it for more than 5 minutes. This will help to ensure that your free GitPod credits are not accidentally used up if you forget to stop your development environment.
+
+
+ If your development environment times out and stops you can restart it using the steps in .
-
+
+
+
+
+
+
+ Stopping your Development Environment
+
+
+ At some point you will complete this assignment or want to take a break and do other things. When you do so, you should stop your development environment.
+
+
+
+
+
+
+
+ You can stop your development environment using the following steps.
+
+
+
+
- core.editor should be set to the nano editor.
+ Open your GitPod workspaces in a browser by visiting
-
-
-
+
+
+
- git.user
+ Choose "Stop" from the "⋮" (three vertical dots) menu to the right of the "GitKit Dev Env" workspace.
-
+
+
+
+
+
+
+ Re-starting your Development Environment
+
+
+ When you already have a GitKit development environment and want to continue working on the GitKit exercises, you will need to restart it.
+
+
+
+
+
+
+
+ Restart your development environment using the following steps.
+
+
+
+
- git.user is not a setting.
+ Open your GitPod workspaces in a browser by visiting
-
-
-
+
+
+
- gitkit.class
+ Click the name of your "GitKit Dev Env" workspace or choose "Open" from the "⋮" (three vertical dots) menu to the right of its name.
-
+
+
+
- gitkit.class is not a setting.
+ Wait for the text similar to that in to appear and click the link.
- Make sure you are giving the URL for your fork, not the project's URL. Review for information on how to fork a repository on GitHub.
-
+ Review for information on how to fork a repository on GitHub.
+
-
+ label="ex-extra-practice-clone-linux"
+ component="linux-kit-client">
+
+
+ Clone your origin (i.e. your fork) for the project you selected into your development environment.
+
- Pick and order the commands to change to your home directory, clone your fork of the project you chose and check its remotes.
+ Copy and paste the Git commands that you used and their output here.
-
-
- cd ~
-
-
- git clone <URL>
-
-
- cd <dir>
-
-
- git remote -v
-
-
- ls
-
-
- git config
-
-
- copy <URL>
-
-
+
+ Review for information about how to clone your origin repository.
+
+
+
+
+
+
+
+ Clone your origin (i.e. your fork) for the project you selected by creating a new development environment (i.e. workspace) for it in GitPod. Recall that creating a new GitPod workspace automatically clones the origin repository into the development environment.
+
- Review for information about how to clone your origin repository.
+ Briefly describe how you created the the development environment, and thus cloned your origin, for the project you have chosen.
+
+
+
+ Review for information about how to create a new GitPod workspace (i.e. development environment).
-
-
- In your terminal enter the commands from .
-
-
- Which of the following do you see in the output of the git remote -v command?
-
-
-
-
-
-
-
- origin followed by the URL that you entered in
-
-
-
-
-
- origin followed by the URL in
-
-
-
-
-
- upstream followed by the URL in
-
-
-
-
-
- upstream followed by the URL that you entered in
-
-
-
-
-
- fork followed by the URL in
-
-
-
-
-
- fork followed by the URL that you entered in
-
-
-
-
-
- The origin URL should be the one from your git clone command.
-
-
-
+
+
+ Use the Git command that displays the remotes that your local repository knows about.
+
+
+ Copy and paste the Git commands that you used and their output here.
+
+
+
+
+ Review for information about how to display the remotes.
+
+
diff --git a/source/ch-communities-and-collaboration/sec-forking-the-upstream.ptx b/source/ch-communities-and-collaboration/sec-forking-the-upstream.ptx
index 163f862..f62dfe1 100644
--- a/source/ch-communities-and-collaboration/sec-forking-the-upstream.ptx
+++ b/source/ch-communities-and-collaboration/sec-forking-the-upstream.ptx
@@ -51,7 +51,7 @@
-
+
Thank you.
@@ -72,13 +72,6 @@
-
-
-
- Looks like you might be trying to use the example above. That was just for illustration. Be sure to use the URL that your instructor has given you.
-
-
-
@@ -89,12 +82,7 @@
-
- Check the course materials from your instructor. It should provide the URL of the GitKit FarmData2 repository that was created for your course.
-
-
- The URL should include something that refers to your course name, not your GitHub username.
-
+ Check the course materials from your instructor. It should provide the URL of the GitKit FarmData2 repository that was created for your course.
@@ -135,7 +123,7 @@
>
- Click the “Fork” button to create your own fork of the upstream repository. Be sure to pick the GitHub username that is at the end of the URL you used in in the "Choose an owner" box so that your fork will be created in your GitHub space.
+ Click the “Fork” button to create your own fork of the upstream repository. Be sure to pick the GitHub username you used in in the "Choose an owner" box so that your fork will be created in your GitHub space.
@@ -156,7 +144,7 @@
-
+
Thank you.
@@ -177,13 +165,6 @@
-
-
-
- Looks like you might be trying to use the example above. That was just for illustration. Be sure to use the URL that your instructor has given you.
-
-
-
@@ -194,9 +175,7 @@
-
- The URL you give here should contain your GitHub username. Be sure you are looking the copy of the GitKit FarmData2 repository that is in your GitHub space.
-
+ The URL you give here should contain your GitHub username. Be sure you are looking the copy of the GitKit FarmData2 repository that is in your GitHub space.
@@ -214,38 +193,14 @@
xml:id="ex-upstream-ref-from-origin-a"
label="ex-upstream-ref-from-origin-a"
>
-
+
- Visit your origin repository on GitHub. There is a link on that page that corresponds to the orange dashed arrow in . What appears before the link?
+ Visit your origin repository on GitHub. There is some text and a link on that page that corresponds to the orange dashed arrow in . Copy and paste that text and link here.
-
-
-
-
-
- forked from
-
-
-
-
-
-
- The Octokitty (GitHub) logo
-
-
-
-
-
-
- Fork your own copy of (in the Fork drop-down)
-
-
-
-
+
+
-
- This text and link will be near the repository name in the upper left corner of the window.
-
+ This text and link will be near the repository name in the upper left corner of the window.
@@ -296,65 +251,24 @@
-
- Think about which step of the basic FOSS workflow needs to send information back to the main project.
-
+ Think about which step of the basic FOSS workflow needs to send information back to the main project.
-
- But, it did not make a copy of the issue tracker and its issues into your GitHub space.
-
-
- Why do you think the designers of GitHub decided that the issue tracker should not be copied into the fork?
+ Did it also make a copy of the issue tracker and its issues into your GitHub space? What reasons can you think of for why the designers of GitHub decided that the issue tracker should not be copied into the fork?
-
-
-
-
- Because it would be hard for the maintainers of the original project to find issues entered in forks.
-
-
-
-
-
-
- Because contributors would not know which issue tracker to enter new issues into.
-
-
-
-
-
-
- Because it would be hard to keep issue descriptions and discussions up-to-date across multiple issue trackers.
-
-
-
-
-
-
- Because only the maintainers of the original project should be allowed to add new issues.
-
-
-
-
-
-
- Why would it be confusing to have multiple issue trackers for a project?
-
-
+
diff --git a/source/ch-communities-and-collaboration/sec-foss-communities.ptx b/source/ch-communities-and-collaboration/sec-foss-communities.ptx
index b3495bb..01640a0 100644
--- a/source/ch-communities-and-collaboration/sec-foss-communities.ptx
+++ b/source/ch-communities-and-collaboration/sec-foss-communities.ptx
@@ -234,7 +234,7 @@
FOSS Community Roles
- There are a number of roles that tend to exist in FOSS communities. Some of these include Users, Requestors, Contributors, Maintainers and Leaders. Not all communities will have all of these roles and often community members will take on multiple roles simultaneously or move between roles over time.
+ There are a number of roles that tend to exist in FOSS communities. Some of these included Users, Requestors, Contributors, Maintainers and Leaders. Not all communities will have all of these rolls and often community members will take on multiple roles simultaneously or move between roles over time.
diff --git a/source/ch-communities-and-collaboration/sec-git-command-summary.ptx b/source/ch-communities-and-collaboration/sec-git-command-summary.ptx
index c2b9a65..56628d1 100644
--- a/source/ch-communities-and-collaboration/sec-git-command-summary.ptx
+++ b/source/ch-communities-and-collaboration/sec-git-command-summary.ptx
@@ -40,7 +40,7 @@
- git clone <URL>
+ git clone <clone URL>
Create a copy of the origin repository in your development environment.
diff --git a/source/ch-communities-and-collaboration/sec-github-account.ptx b/source/ch-communities-and-collaboration/sec-github-account.ptx
new file mode 100644
index 0000000..335196e
--- /dev/null
+++ b/source/ch-communities-and-collaboration/sec-github-account.ptx
@@ -0,0 +1,60 @@
+
+
+
+ GitHub Account
+
+
+ You will be using GitHub in many of the exercises in this text. In order to use GitHub it is necessary that you have an account.
+
+
+
+
+
+
+
+
+ If you do not have a GitHub account, or would like to have a separate account just for this course, you can create a GitHub account here: https://github.com/signup.
+
+
+ If you already have a GitHub account that you would like to use for this class, skip to the next exercise.
+
+
+
+
+
+
+
+ Give the full URL to your GitHub profile, for example https://github.com/yourUsername
+
+
+
+
+
+
+
+
+
+
+ Thank you.
+
+
+
+
+
+
+ Please give the full URL using the format indicated in the question.
+
- You will be using GitHub in many of the exercises in this text.
- In order to use GitHub it is necessary that you have an account and a Personal Access Token.
- You will also configure your GitHub Codespaces to help conserve your free useage time.
-
-
-
-
-
- GitHub Account
-
-
-
-
-
- If you do not have a GitHub account, or would like to have a separate account just for this course, you can create a GitHub account here: https://github.com/signup.
-
-
-
- When you have a GitHub account to use for this class, move on to the next exercise.
-
-
-
-
-
-
-
- Give the full URL to your GitHub profile, for example https://github.com/yourUsername
-
-
-
-
-
-
-
-
-
- Thank you.
-
-
-
-
-
-
- Please give the full URL using the format indicated in the question.
-
-
-
-
-
-
-
-
- GitHub Personal Access Token
-
- When starting your development environment for the first time (in ) you will be asked to enter a Personal Access Token (PAT) from GitHub.
-
-
- A PAT is like a password but has some security benefits.
- In particular, you can have multiple different PATs.
- Each one can have different limits on what can be done with it and each one can be revoked individually without affecting the others.
-
-
-
-
-
-
- Follow GitHub's instructions for creating a (classic) personal access token: Creating a Personal Access Token (classic).
-
-
-
- When doing so be sure to:
-
-
-
- Choose “repo” for the “scopes and permissions.”
-
-
-
-
-
- Be sure to copy and paste your PAT somewhere safe – maybe e-mail it to yourself.
- You will not be able to retrieve it again after you leave the page.
-
-
-
-
-
-
-
-
-
-
-
- What are the first 4 characters of your GitHub PAT?
-
- The GitKit development environment runs in GitHub Codespaces. GitHub provides you with approximately 60 hours per month of free Codespaces use. By default the GitKit development environment will timeout after 30 minutes of inactivity. It is recommended that you reduce this timeout to 15 minutes to avoid accidentally consuming your allotted free useage.
-
-
-
-
-
-
-
- Use the following steps to adjust the timeout for your Codespaces, including the GitKit developent environment.
-
-
-
-
-
- Open your GitHub Codespaces settings by visiting .
-
-
-
-
-
-
- Scroll down to the section labeled "Default idle timeout", adjust the timeout to 15 minutes, and click "Save".
-
- FOSS projects often use an issue tracker to maintain a list of bugs to be fixed, features to be added and other tasks to be completed.
- Thus, the issue tracker is a good place to go in order to find something to work on in a FOSS project.
- The exercises in this section will guide you through interaction with the GitKit FarmData2 issue tracker as shown in .
- By the end of the section you will have found an issue to work on.
+ FOSS projects often use an issue tracker to maintain a list of bugs to be fixed, features to be added and other tasks to be completed. Thus, the issue tracker is a good place to go in order to find something to work on in a FOSS project. The exercises in this section will guide you through interaction with the GitKit FarmData2 issue tracker as shown in . By the end of the section you will have found an issue to work on.
-
-
The GitKit FarmData2 issue tracker in GitHub.
+
+
+ The GitKit FarmData2 issue tracker in GitHub.
+
The GitHub issue tracker displaying issues from the GitKit FarmData2 repository.
@@ -23,217 +28,188 @@
-
Exploring the Issue Tracker
-
-
-
-
-
- The tasks in this exercise will help you to find the issue tracker for the GitKit FarmData2 repository that you will be using.
-
-
-
-
-
-
-
- Visit the URL that your instructor provided for the GitKit FarmData2 repository that you will be using as the upstream repository for your course.
-
-
-
-
-
-
-
+
+
+
- Click the "Issues" tab near the top of the page to go to the issue tracker.
- This will take you to a page similar to the one shown in .
+ The tasks in this exercise will help you to find the issue tracker for the GitKit FarmData2 repository that you will be using.
-
-
-
+
-
-
-
- Use the issue tracker in the GitKit FarmData2 repository to complete the following tasks.
-
-
+
+
+
+ Visit the URL that your instructor provided for the GitKit FarmData2 repository that you will be using as the upstream repository for your course.
+
+
+
+
+
+
+ Click the "Issues" tab near the top of the page to go to the issue tracker. This will take you to a page similar to the one shown in .
+
+
+
+
-
-
+
+
- Every issue has a number and a title.
- What is the title of issue #10?
+ Use the issue tracker in the GitKit FarmData2 repository to complete the following tasks.
-
-
-
-
-
-
-
- Add Missing "that"
-
-
-
-
-
-
-
- Seeding Report: Allows Invalid Inputs
-
-
-
-
-
-
-
- Seeding Input: Duplicates appearing in Area Dropdown
-
-
-
-
-
-
-
- Dickinson College Farm Link
-
-
-
-
+
-
-
+
+
+
+ Every issue has a number and a title. What is the title of issue #10?
+
+
+
+
+
+
+ Add Missing "that"
+
+
+
+
+
+
+ Seeding Report: Allows Invalid Inputs
+
+
+
+
+
+
+ Seeding Input: Duplicates appearing in Area Dropdown
+
+
+
+
+
+
+ Dickinson College Farm Link
+
+
+
+
+
Be sure you are looking at issue #10.
-
-
-
-
-
-
-
-
- Each issue can have tags that can be used to sort and categorize issues.
- Select all of the tags that are associated with issue #8?
-
-
-
+
+
+
+
+ CONTRIBUTING.md
+
+
+
+
+ LICENSE.md
+
+
+
+
+ Be sure you are looking at issue #11.
+
+
-
-
-
-
- Match issue tracker sort orders on the left to a reason for sorting in that order on the right.
-
-
-
-
- You can do it! Try again!
-
-
-
-
-
- Created on
- Find issues you have not seen before
-
-
- Last updated
- Check if any issues you have been assigned to have had their requirements changed
-
-
- Total comments
- Find which issues are being most actively worked on
-
-
-
-
- Choose the best match.
-
-
-
-
-
+
+
+
+ Pick one of the sort orders that can be used with issues and briefly explain why it might be useful to sort the issues in that order.
+
+
+
+
+ Think about why it might bue useful for a requestor, contributor or maintainer to find the types of issues that would be at the top of the sorted list.
+
+
+
+
-
Claiming an Issue
-
Because projects often have many people working asynchronously many will have a process by which contributors can claim an issue that they are interested in working on and have that issue assigned to them in the issue tracker.
@@ -331,218 +286,162 @@
The following exercises will guide you through the process of claiming an issue to work on in the GitKit FarmData2 issue tracker.
-
-
-
-
-
- Examine the GitKit FarmData2 issue tracker.
- How can you tell which issue have already been assigned?
-
-
-
-
-
-
-
- The avatar of the assigned user appears to the right of the issue title.
-
-
+
-
-
- The issue no longer appears in the issue tracker.
-
-
-
-
-
- The username of assigned user appears next to the issue title.
-
-
-
-
-
- The issue is moved to a separate list of assigned issues.
-
-
-
-
-
- The issue tracker does not show any indication that an issue has been assigned.
-
-
-
-
-
-
- Look for some lines for issues that look different than the others and hover your mouse over the different parts.
-
-
-
-
-
- In the GitKit FarmData2 issue tracker, contributors interested in working on an issue can request that it be assigned to them by commenting on the issue with the exact message:
-
-
-
- I would like to work on this please!
-
-
-
- The first person who comments on an unclaimed issue with this message will receive a response from the project maintainers.
- This messages will indicate that the issue has been assigned to them and the issue tracker will update to show this as you saw in .
-
-
-
-
-
- Use the GitKit FarmData2 issue tracker to complete the following tasks.
-
-
-
-
-
+
- Choose an unassigned issue with a "Round 1" tag.
+ Examine the GitKit FarmData2 issue tracker.
+ How can you tell which issue have already been assigned?
-
+
+
+
+ The avatar of the assigned user appears to the right of the issue title.
+
+
+
+
+ The issue no longer appears in the issue tracker.
+
+
+
+
+ The username of assigned user appears next to the issue title.
+
+
+
+
+ The issue is moved to a separate list of assigned issues.
+
+
+
+
+ The issue tracker does not show any indication that an issue has been assigned.
+
+
+
-
- See for information about identifying assigned and unassigned issues.
-
-
-
-
-
-
-
-
- Comment on the issue that you chose using the message above to claim it.
-
-
+ Look for some lines for issues that look different than the others and hover your mouse over the different parts.
+
+
-
-
- Click on the issue title to open the issue and use the "Add a comment" box at the bottom of the page.
-
-
- Remember you must type the message exactly as shown.
-
-
-
+
+ In the GitKit FarmData2 issue tracker, contributors interested in working on an issue can request that it be assigned to them by commenting on the issue with the exact message:
+
+
+
+ I would like to work on this please!
+
+
+ The first person who comments on an unclaimed issue with this message will receive a response from the project maintainers. This messages will indicate that the issue has been assigned to them and the issue tracker will update to show this as you saw in .
+
-
-
+
+
- Reload the issue tracker and check that you received a response and that the issue has been assigned to you.
+ Use the GitKit FarmData2 issue tracker to complete the following tasks.
-
-
-
- If you did not receive a response, wait a few minutes and reload the issue tracker page again.
- Sometimes it takes a few minutes for your comment to be noticed and the issue to be assigned.
- If you still do not receive a response check that you typed the message correctly.
-
-
-
- If you received a response telling you that you were not assigned the issue, someone else slipped a comment in just ahead of you and was assigned the issue.
- If this happens, just try again.
-
-
-
-
-
-
-
-
- Give the full URL to the issue that you have been assigned, for example https://github.com/my-class/GitKit-FarmData2/issues/2
-
-
-
-
-
-
-
-
-
- Thank you.
-
-
-
-
-
-
- Please give the full URL using the format indicated in the question.
-
-
-
-
-
-
-
-
- It is worth noting that different projects will have different processes for claiming and assigning issues, and some projects may not assign issues at all.
- What are some advantages and disadvantages of assigning issues to specific individuals?
-
-
- Select each of the statements that describe an advantage of assigning issues.
-
-
-
-
- You can do it! Try again!
-
-
-
-
+
+
- To prevent wasting effort by having two developers work on the same issue.
+ Choose an unassigned issue with a "Round 1" tag.
-
-
+
+
+ See for information about identifying assigned and unassigned issues.
+
+
+
+
+
- Assigning issues can help prevent people from duplicating work.
+ Comment on the issue that you chose using the message above to claim it.
-
-
-
+
+
+ Click on the issue title to open the issue and use the "Add a comment" box at the bottom of the page.
+
+
+
+
- Allow a developer to "hold on" to an issue, even if they are not currently working on it.
+ Reload the issue tracker and check that you received a response and that the issue has been assigned to you.
-
-
- Holding onto an issue that is not being worked on may prevent someone else from working on it.
-
-
-
-
-
+
- To plan in advance who will be working each issue.
+ If you did not receive a response, wait a few minutes and reload the issue tracker page again. Sometimes it takes a few minutes for your comment to be noticed and the issue to be assigned. If you still do not receive a response check that you typed the message correctly.
-
-
- Assigning issues could work like creating a ToDo list for core project contributors.
+ If you received a response telling you that you were not assigned the issue, someone else slipped a comment in just ahead of you and was assigned the issue. If this happens, just try again.
-
-
-
-
-
+
+
+
+
+
+
+
+ Give the full URL to the issue that you have been assigned, for example https://github.com/my-class/GitKit-FarmData2/issues/2
+
+
+
+
+
+
+
+
+
+
+ Thank you.
+
+
+
+
+
+
+ Please give the full URL using the format indicated in the question.
+
+
+
+
+
+
+
+
+
+
+ It is worth noting that different projects will have different processes for claiming and assigning issues, and some projects may not assign issues at all. What are some advantages and disadvantages of assigning issues to specific individuals?
+
+
+
+
Think about this from both the individual developer's perspective and from the overall project's perspective.
-
-
-
-
+
+
+
diff --git a/source/ch-instructor-guide/ch-instructor-guide.ptx b/source/ch-instructor-guide/ch-instructor-guide.ptx
index da11ef3..ce23b58 100644
--- a/source/ch-instructor-guide/ch-instructor-guide.ptx
+++ b/source/ch-instructor-guide/ch-instructor-guide.ptx
@@ -7,23 +7,28 @@
- The GitKit provides an introduction to the fundamental skills and concepts used in collaborative Free and Open Source Software (FOSS) development. It introduces Git and GitHub basics, and gives learners the experience of using the forking workflow to contribute to a FOSS project.
+ The GitKit provides an introduction to the fundamental skills and concepts used in collaborative Free and Open Source Software (FOSS) development.
+ It introduces Git and GitHub basics, and gives learners the experience of using the forking workflow to contribute to a FOSS project.
-
- If at any point you have questions about the GitKit, need help getting setup to use it in a class, or have feedback for us, please chat with us on Discord.
-
-
-
GitKit Use
-
The GitKit is designed for use as a module within a traditional course to provide a first exposure to Git and GitHub.
- It includes classroom materials, hands-on activities for labs or homework, project artifacts (repository, code, documentation, issues) captured from a genuine FOSS project, and a cloud-based development environment. The classroom materials focus on the introduction of concepts and terminology. The hands-on activities reinforce the in-class material while guiding learners through the forking workflow in the context of an authentic FOSS project. The activities are structured such that each new Git command and GitHub operation is introduced as the need for it arises in the forking workflow.
+ It includes classroom materials, hands-on activities for labs or homework, project artifacts (repository, code, documentation, issues) captured from a genuine FOSS project, and a cloud-based development environment.
+ The classroom materials focus on the introduction of concepts and terminology.
+ The hands-on activities reinforce the in-class material while guiding learners through the forking workflow in the context of an authentic FOSS project.
+ The activities are structured such that each new Git command and GitHub operation is introduced as the need for it arises in the forking workflow.
- The GitKit minimizes prerequisite knowledge and hardware requirements. Learners are expected to have basic familiarity with files, directories and the Unix/Linux command line (e.g. cd and ls). Hands-on activities focus on small changes to documentation in markdown files, and require no prior knowledge of markdown or any programming language. The cloud-based development environment requires an internet connection and a modern web browser.
+ The GitKit minimizes prerequisite knowledge and hardware requirements.
+ Learners are expected to have basic familiarity with files, directories and the Unix/Linux command line (e.g.
+ cd and ls). Hands-on activities focus on small changes to documentation in markdown files, and require no prior knowledge of markdown or any programming language.
+ The cloud-based development environment requires an internet connection and a modern web browser.
+
+
+ If you have questions about the GitKit, need help getting setup to use it in a class, or have feedback for us, please chat with us on Discord.
+
diff --git a/source/ch-instructor-guide/images/deployer-done.png b/source/ch-instructor-guide/images/deployer-done.png
deleted file mode 100644
index 176817b..0000000
Binary files a/source/ch-instructor-guide/images/deployer-done.png and /dev/null differ
diff --git a/source/ch-instructor-guide/images/deployer-kitscript.png b/source/ch-instructor-guide/images/deployer-kitscript.png
deleted file mode 100644
index 9b72963..0000000
Binary files a/source/ch-instructor-guide/images/deployer-kitscript.png and /dev/null differ
diff --git a/source/ch-instructor-guide/images/linux-kitclient.png b/source/ch-instructor-guide/images/linux-kitclient.png
new file mode 100644
index 0000000..5b33921
Binary files /dev/null and b/source/ch-instructor-guide/images/linux-kitclient.png differ
diff --git a/source/ch-instructor-guide/images/codespace-kitclient.png b/source/ch-instructor-guide/images/vscode-kitclient.png
similarity index 100%
rename from source/ch-instructor-guide/images/codespace-kitclient.png
rename to source/ch-instructor-guide/images/vscode-kitclient.png
diff --git a/source/ch-instructor-guide/sec-instructor-communities.ptx b/source/ch-instructor-guide/sec-instructor-communities.ptx
index 77644ed..ca6ba5e 100644
--- a/source/ch-instructor-guide/sec-instructor-communities.ptx
+++ b/source/ch-instructor-guide/sec-instructor-communities.ptx
@@ -174,32 +174,35 @@
-
-
+
+
+
+
+
- Some students will give the URL of the upstream GitKit-FarmData2 repository for the course instead of their origin repository. A few may even give the URL of a real FarmData2 upstream repository.
+ Some students will try to clone the upstream GitKit-FarmData2 repository instead of their origin repository. A few may even attempt to clone the real FarmData2 repository. The Kit-tty should prevent this and provide a helpful tip.
-
+
- Some students will try to clone the upstream GitKit-FarmData2 repository for the course or even give the URL of a real FarmData2 upstream repository.
+ Checking the origin remote that is given as the answer to this question will confirm that the student has correctly cloned their origin. Again, the Kit-tty should prevent them doing this incorrectly, but if somehow it did not catching and correcting this early is important.
-
+
- Checking the origin remote that is given as the answer to this question will confirm that the student has correctly cloned their origin. Again, the Kit-tty should prevent them doing this incorrectly, but if somehow it did not catching and correcting this early is important.
+ The answer to this question will reasonably differ depending upon when students complete the exercise. There are initially 3 issues that are pre-assigned to the user that deployed the GitKit. Students who complete the exercise early are likely to all identify these issues. As additional students claim issues, other students will identify those claimed issues as well.
- For questions or assistance with GitKit, you can chat with us on Discord.
+ For help with GitKit, you can chat with us on Discord.
@@ -28,18 +28,26 @@
Create a Runestone course using the
- GitKit text.
+ GitKit (Linux Desktop Edition) or the
+ GitKit (VSCode Edition).
+
+
+ Note that you are currently viewing the
+ GitKit (Linux Desktop Edition)
+ GitKit (VSCode Edition)
+ .
Copy the Course Pack for the GitKit from the
- gitkit
+ gitkitlinux
+ gitkitvscode
base course into your course if you would like to use the provided assignments.
- Note that the reading assignments in the course pack include sections that allow students to elect to participate in a research project aimed at (1) understanding what they think and know about open source tools and techniques and (2) assessing the effectiveness of the GitKit. The inclusion of these sections is optional and they may be removed at the discretion of the instructor. See for additional information.
+ Note that the reading assignments in the course pack include sections that allow students to elect to participate in a research project aimed at (1) understanding what they think and know about open source tools and techniques and (2) assessing the effectiveness of the GitKit. The inclusion of these sections is option and may be removed at the discretion of the instructor. See for additional information.
@@ -49,10 +57,10 @@
- Click to deploy the GitKit FarmData2 repository to use as the upstream.
+ Click to Deploy the GitKit FarmData2 repository to use as the upstream.
- One deploy of the GitKit FarmData2 repository can support up to 32 students. Perform as many deploys as necessary for your course. Be sure to give each deploy a distinct name when prompted by the deployer.
+ One deploy of the GitKit FarmData2 repository can support up to 32 students. Perform as many deploys as necessary for your course. Be sure to give each deploy a distinct name.
@@ -62,7 +70,7 @@
- Please consider clicking the link to the brief survey that is included in the output of the GitKit deployer. Your feedback helps us to better understand where and how the GitKit is being used. This survey can also be accessed here.
+ Please consider clicking the link to the brief survey that is included in the output of the GitKit deployer. Your feedback helps us to better understand where and how the GitKit is being used. This survey can also be accessed here.
@@ -103,7 +111,7 @@
- Read to learn about the development environment that students use with the GitKit.
+ Read to learn about the two development environments that can be used with the GitKit and select one for use in your course.
@@ -114,7 +122,7 @@
- Consider doing the GitKit for yourself as described in . This is by far the best way to prepare to deliver the GitKit to a class.
+ Consider doing the GitKit for yourself as described in . It is by far the best way to prepare to deliver the GitKit to a class.
@@ -124,7 +132,7 @@
- Follow the steps in to deploy the upstream repository needed to use GitKit in your course.
+ Follow the steps in to deploy the GitKit for use in your course.
@@ -134,7 +142,7 @@
- Refer to for information about contributing to the GitKit including where to report typos, errors, suggested improvements, feature requests or bugs.
+ Refer to for information about contributing to the GitKit including where to report typos, errors, suggested improvements or bugs.
@@ -146,7 +154,7 @@
Delivering GitKit
- The GitKit content is broken into 4 chapters (See ). Each chapter of the text contains the set of hands-on exercises to be completed by the students. These exercises are not intended to stand alone. Each requires some prior introduction to the concepts and terminology that they use. A separate set of slides are provided for each topic that instructors can use or adapt to introduce the necessary concepts and terminology before students complete each set of hands-on exercises.
+ The GitKit content is broken into 4 chapters (See ). Each chapter of the text contains the set of hands-on exercises to be completed by the students. These exercises are not intended to stand alone. They require some prior introduction to the concepts and terminology that they use. A separate set of slides are provided that instructors can use or adapt to introduce the necessary concepts and terminology before students complete the hands-on exercises.
@@ -159,18 +167,18 @@
- Students complete the hands-on activities contained in each chapters of this text as 2-3 hours of homework or during assigned lab periods.
+ Students complete the hands-on activities contained in the chapters of this text as 2-3 hours of homework or during an assigned lab period.
- While the GitKit was designed for nominal delivery in four 50-75-minute periods with 2-3 hours of additional hands-on work by the students, instructors have found the GitKit to be adaptable to different educational settings, student experience levels and learning objectives. Some examples include:
+ While the GitKit was designed for nominal delivery in four 50-75-minute periods with 2-3 hours of additional hands-on work by the students, instructors have found the GitKit to be adaptable to different educational settings, student experience levels and learning objectives.
- Limited Coverage: The first two GitKit topics form a cohesive unit and can be completed without continuing onto the final two topics.
+ Limited Coverage: The first two GitKit topics form a cohesive unit and can be completed without continuing onto the final two topics. Two examples of how this can be used include:
@@ -180,12 +188,12 @@
- A One Day Workshop: An organization has delivered the GitKit as a one-day workshop for students from low-income, first-generation, underrepresented minority backgrounds. This workshop covered just the first two GitKit topics.
+ A One Day Workshop: An organization delivered the GitKit as a one-day workshop for students from low-income, first-generation, underrepresented minority backgrounds. This workshop covered just the first two GitKit topics.
- Students with Prior Git Experience: An instructor with students who have had prior exposure to Git fundamentals (but not GitHub or the forking workflow) have skipped most of the class materials and used the hands-on activities as in-class lab activities rather than homework.
+ Students with Prior git Experience: An instructor with students who have had prior exposure to git fundamentals (but not GitHub or the forking workflow) have skipped most of the class materials and used the hands-on activities as in-class lab activities rather than homework.
@@ -202,7 +210,7 @@
GitKit Content
- The content of the GitKit is broken into the chapters below.
+ The content of the GitKit is broken into the chapters below. For each chapter the key topics and activities are outlined and links are given to the slides, the chapter of the text containing the hands-on exercises and instructor notes for the chapter.
@@ -227,7 +235,7 @@
- Introduces feature branches, commits, and pull requests as part of the forking workflow.
+ Introduces feature branches, commits, and pull requests as part of the forking workflow.
@@ -267,7 +275,7 @@
- Provides practice with understanding merge conflicts, merging main into a feature branch, using a basic merge tool, and updating a pull request.
+ Provides practice with understanding merge conflicts, merging main into a feature branch, using a graphical merge tool and updating a pull request.
@@ -281,46 +289,87 @@
Student Development Environments
- The GitKit provides a cloud based development environment that students use to complete the hands-on GitKit activities. This development environment, which we call a KitClient, runs on GitHub Codespaces. It provides all of the tools and configuration necessary to complete the activities. The development environment also includes the Kit-tty Virtual Assistant (See and a set of automations that simulate aspects of an open source project community (See ).
+ The GitKit provides a cloud based development environment that students use to complete the hands-on GitKit activities. This development environment is called a KitClient. A KitClient is a pre-configured containerized development environment that provides all of the tools and configuration necessary to complete the activities. The KitClient also includes the Kit-tty Virtual Assistant (See and a set of automations that simulate project community (See ).
- shows the development environment where students complete the hands-on activities.
-
-
-
- The KitClient development environment running in Codespaces.
-
-
-
- Screenshot showing the KitClient development environment running in GitHub Codespaces.
-
-
-
-
+ There are currently two KitClients that can be used with GitKit and the instructor may choose the KitClient to use based on the needs of their course and students.
+
+
+
+ Linux Desktop KitClient: shows the Linux KitClient where students complete the hands-on activities in a complete Linux virtual desktop environment.
+
+
+
+ The Linux KitClient development environment.
+
+
+
+ The Linux KitClient development environment window displaying the Linux desktop.
+
+
+
+
+
+
+
+ VSCode KitClient: shows the VSCode KitClient in which students complete the hands-on activities in the VSCode interface.
+
+
+
+ The VSCode development environment.
+
+
+
+ The VSCode development environment window showing the VS Code interface.
+
+
+
+
+
+
+
+ Both of these KitClients run remotely within GitPod Workspaces and students interact with them through a Web browser. To run a KitClient, students will need will need to have a free GitPod account, which they will created as a part of the activities.
+
+
+
+ There is a different edition of this text for each of the KitClients. The texts provide an equivalent experience, but adapt content to the specifics (e.g. user interface elements) of the KitClient as necessary. The instructor will adopt the text for the KitClient that has been chosen for the course (see ).
+
+
- Note: If you are familiar with GitHub Codespaces, you will find that the interface familiar. However, the KitClient works slightly differently than a standard Codespace. In particular, when students open the KitClient no repository will be opened. Instead they are given a blank development environment into which they git clone the repository they will be using for the GitKit. This make explicit the important concept of a clone, which Codespaces hide.
+ You are currently viewing the
+ GitKit (Linux Desktop Edition)
+ GitKit (VSCode Edition)
+ of the text. You can use the following link to find the
+ GitKit (Linux Desktop Edition)
+ GitKit (VSCode Edition) if you would like to review it.
+ .
The Kit-tty Virtual Assistant
- The Kit-tty (a play on Kit and TTY), pronounced kitty, is a virtual assistant built into the development environment. The Kit-tty has been designed to catch and correct student errors that were frequently observed in early uses of the GitKit. Many of the errors caught by the Kit-tty are those that would not be discovered until students progress several steps further into the activity, at which point they can be difficult to undo.
+ The Kit-tty (a play on Kit and TTY), pronounced kitty, is a virtual assistant built into the development environments (i.e. KitClients) that catches common student errors and provides hints on how to perform activity steps correctly. The Kit-tty has been designed to catch and correct student errors that were frequently observed in early uses of the GitKit. Many of the errors recognized by the Kit-tty are those that typically are not discovered until students progress several steps further into the activity, at which point they require more advanced git skills to undo.
For example, the Kit-tty intervenes when a student attempts to:
- commit to the main branch (an action that should not happen in the forking workflow).
+ commit to the main branch (an action that should not happen in the forking workflow).
- merge a feature branch into main (instead of vice versa).
+ merge a feature branch into main (instead of vice versa).
@@ -352,7 +401,7 @@
- Students claim an issue by adding a comment to its ticket in the issue tracker. An automation notices this comment and assigns the issue to the student (if it hasn't already been assigned to someone else). The automation then also responds personally as a maintainer might: "Great! I assigned you (@TheirUsername) to the issue. Have fun working on it!"
+ When claiming an issue by adding a comment to its ticket in the issue tracker. An automation notices this comment, assigns the issue to the student (if it hasn't already been assigned to someone else). The automation then also responds personally as a maintainer might: "Great! I assigned you (@TheirUsername) to the issue. Have fun working on it!"
@@ -372,7 +421,7 @@
- The captured repository is from an earlier version of FarmData2. Current active development work on FarmData2 is occurring in the FarmData2 Organization on GitHub.
+ Current development work on FarmData2 is occurring in the FarmData2 Organization on GitHub.
@@ -380,7 +429,7 @@
Creating a Runestone Course using the GitKit Text
- The GitKit text is an e-text that is available on Runestone Academy. It contains a large number of interactive elements, (nearly) all of which are auto-graded and provide immediate feedback to students as they work through the GitKit. If you are not familiar with Runestone Academy it is recommended that you read the first 6 sections of the Using eBooks with Runestone Academy guide to familiarize yourself with it.
+ The GitKit text is an e-text that is available on Runestone Academy. It contains a large number of interactive elements, many of which are auto-graded and provide instant feedback to students as they work through the GitKit. If you are not familiar with Runestone Academy it is recommended that you read the first 6 sections of the Using eBooks with Runestone Academy guide to familiarize yourself with it.
@@ -389,23 +438,30 @@
Create a Runestone course using the
- GitKit text.
+ GitKit (Linux Desktop Edition) or the
+ GitKit (VSCode Edition)
+ of the text.
+
+
+ Note that you are currently viewing the
+ GitKit (Linux Desktop Edition)
+ GitKit (VSCode Edition)
+ .
You can either create assignments for your students from the GitKit sections and exercises, or you can Copy the Course Pack for the GitKit from the
- gitkit base course into your course.
+ gitkitlinux
+ gitkitvscode
+ base course into your course.
- The course pack includes a reading assignment and a problem assignment for each of the chapter of the GitKit text (except ). The provided reading assignment for each chapter includes all sections of the chapter and is auto-graded based on student interaction with each of he chapter's sections. The provided problem assignment for each chapter includes every interactive exercise in the chapter. Exercises are auto-graded graded using % Correct and the students last answer.
-
-
- If you adopt the course pack you can modify the sections and questions that are included in the assignments, how they are graded and also add your own questions. See the Working with Assignments section of the Using eBooks with Runestone Academy guide for more details.
+ The course pack includes a reading assignment and a problem assignment for each of the chapter of the GitKit text (except ). The provided reading assignment for each chapter includes all sections of the chapter and is auto-grading based on student interaction with each of he chapter's sections. The provided problem assignment for each chapter includes every interactive exercise in the chapter. Every exercise that can be auto-graded is graded using % Correct and the students last answer. If you adopt the course pack you can modify the sections and questions that are included in the assignments, how they are graded and also add your own questions. See the Working with Assignments section of the Using eBooks with Runestone Academy guide for more details.
- Note: The reading assignments in the course pack include sections that allow students to elect to participate in a research project aimed at (1) understanding what they think and know about open source tools and techniques and (2) assessing the effectiveness of the GitKit. In addition, there are surveys at the end of each chapter by which students can provide feedback to help improve the GitKit for future students.
+ The reading assignments in the course pack include sections that allow students to elect to participate in a research project aimed at (1) understanding what they think and know about open source tools and techniques and (2) assessing the effectiveness of the GitKit. In addition, there are surveys at the end of each chapter by which students can provide feedback to help improve the GitKit for future students.
@@ -414,7 +470,7 @@
- also allows students to consent to providing the GitKit authors with their responses to all of the GitKit exercises. If you would like to provide the GitKit authors with exercise responses from students in your course who consented please contact Dr. Braught (braught@dickinson.edu) Professor of Computer Science at Dickinson College for additional information.
+ The also allows students to consent to providing the GitKit authors with their responses to all of the GitKit exercises. If you would like to provide the GitKit authors with exercise responses from students in your course who consented please contact Dr. Braught (braught@dickinson.edu) Professor of Computer Science at Dickinson College for additional information.
@@ -461,7 +517,7 @@
- Review the Slide Notes for the chapter for helpful instructor tips.
+ Review the Slide Notes for the chapter.
@@ -533,29 +589,7 @@
- Click this link to deploy the GitKit FarmData2 repository .
-
-
-
-
- Click the green "Create new codespace" button.
-
-
-
-
- Creating the codespace requires a few minutes. When it is complete will see the prompt in .
-
-
-
- The deployer prompting for the new repository name.
-
-
-
- Screenshot showing the deployer prompting for the new repository name.
-
-
-
+ Click this link to Deploy the GitKit FarmData2 repository .
@@ -569,7 +603,7 @@
- The GitHub username or the name of a GitHub organization to which you have write permission as the location to deploy the upstream repository.
+ You GitHub username to deploy into your GitHub space, or the name of a GitHub organization to which you have write permission to deploy into that organization's GitHub space.
@@ -582,26 +616,18 @@
- Wait for the deployer to complete. This typically takes several minutes because the deployer must create the issues in the issue tracker slowly to avoid being rate-limited by the GitHub API.
+ Wait for the deployer to complete. This typically takes several minutes because the deployer must create the issues in the issue tracker slowly to avoid being rate-limited by the GitHub API.
- When the deployer completes it will generate output similar , which shows the URL of your deployed GitKit FarmData2 repository.
-
-
-
- The deployer showing the URL of the deployed GitKit FarmData2 repository.
-
-
-
- Screenshot of the deployer showing the URL of the deployed GitKit FarmData2 repository.
-
-
-
+ When the deployer completes it will generate output similar to the following that shows the URL of your deployed GitKit FarmData2 repository.
-
+
+Your new repository is ready. Give the URL below to your students.
+https://github.com/someLocation/GitKit-FarmData2
+
+
Copy the URL of the repository and distribute it to your students using e-mail, LMS or whatever means is convenient for you.
@@ -616,7 +642,7 @@
- Please consider visiting the link to the brief survey that is included in the output of the GitKit deployer. Your feedback helps us to better understand where and how the GitKit is being used. This survey can also be accessed here.
+ Please consider clicking the link to the brief survey that is included in the output of the GitKit deployer. Your feedback helps us to better understand where and how the GitKit is being used. This survey can also be accessed here.
@@ -707,7 +733,7 @@
- For any kind of question, difficulty, suggestion, or suspected bug, chatting with us on Discord is the place to start.
+ For any kind of question, difficulty, suggestion, or suspected bug, chatting with us on Discord is a great place to start.
@@ -715,7 +741,7 @@
- Active work on the deployer and the KitClient takes place in the HFOSSedu Github Organization. Work on HFOSS Kits more generally occurs in Kits section of the HFOSSedu GitLab Organization.
+ Active work on the deployer and the KitClients takes place in the Kits section of the HFOSSedu GitLab Organization.
\ No newline at end of file
diff --git a/source/ch-instructor-guide/sec-instructor-merge-conflicts.ptx b/source/ch-instructor-guide/sec-instructor-merge-conflicts.ptx
index 1cd61ae..2fc641f 100644
--- a/source/ch-instructor-guide/sec-instructor-merge-conflicts.ptx
+++ b/source/ch-instructor-guide/sec-instructor-merge-conflicts.ptx
@@ -7,10 +7,10 @@
Merge Conflicts Instructor Notes
- At the start of this chapter students will have made pull requests for the "Round 2" issues. Initially GitHub will report that these PRs can be merged automatically. However, the instructor will begin this topic by introducing changes to the upstream main that create merge conflicts with the fixes to each of the "Round 2" issues. Students will then observe that their PRs go from being able to be merged automatically to containing conflicts.
+ At the start of this chapter students will have made pull requests for the "Round 2" issues. Initially GitHub will report that these PRs can be merged automatically. However, the instructor will begin this topic by introducing changes to the upstream main that create merge conflicts with the fixes to each of the "Round 2" issues. Students will then observe that their PRs go from being able to be merged automatically to containing conflicts.
- This chapter then focuses on the resolution of merge conflicts. The concepts of merge commits, common ancestors, best common ancestor, and non-conflicting and conflicting changes are introduced. The topic then covers the process of merging main into a feature branch, git's raw conflict information and the use of a basic merge tool. The hands-on activity concludes with the students having resolved the merge conflict in their "Round 2" pull request. Note that these PRs are never merged into the upstream as part of the GitKit activities.
+ This chapter then focuses on the resolution of merge conflicts. The concepts of merge commits, common ancestors, best common ancestor, and non-conflicting and conflicting changes are introduced. The topic then covers the process of merging main into a feature branch, git's raw conflict information and the use of graphical merge tool. The hands-on activity concludes with the students having resolved the merge conflict in their "Round 2" pull request. Note that these PRs are never merged into the upstream as part of the GitKit activities.
The exercises in this chapter have the students perform the following major tasks:
@@ -32,7 +32,7 @@
- Use VS Code's basic merge tool to resolve the conflict.
+ Use the VS Code merge tool to resolve the conflict.
@@ -137,23 +137,15 @@
- Slide 21
+ Slides 21-23
- Shows the basic graphical merge tool that is built into VS Code. The exercises guide the students through use this tool to resolve the conflicts in their PRs for their "Round 2" issues.
+ Shows the graphical merge tool that is built into VS Code. The exercises guide the students through use this tool to resolve the conflicts in their PRs for their "Round 2" issues.
- Slide2 22-24
-
-
- These slides are hidden by default. They show a more advanced graphical merge tool that is also built into VS Code. The exercises do not use this merge tool, but some instructors may wish to show or demonstrate it.
-
-
-
-
- Slide 25-26
+ Slide 24-25
Here for review and reference and not much time needs to be spent on these slides. The final slide collects into one diagram everything that is a part of the forking workflow. It has a lot going on, but by this point students should be able to make sense of each of the actions that are illustrated.
@@ -195,30 +187,37 @@
- -
+ -
- In these exercises there are no conflicting changes and the merge would be able to be completed automatically. However, if all of the non-conflicting changes are merged into the result the program will not produce the correct result. The point being that automatic merges can check for structural conflicts, but not logical or semantic conflicts and thus caution should be used when performing merges.
+ In this exercise there are no conflicting changes and the merge would be able to be completed automatically. However, if all of the non-conflicting changes are merged into the result the program will not produce the correct result. The point being that automatic merges can check for structural conflicts, but not logical or semantic conflicts and thus caution should be used when performing merges.
-
+
- Inevitably some students will be behind on their work and will complete their sync with upstream main after you have merged the PR for the addRound2Conflicts branch. In these cases, their pull requests will not create a conflict to be resolved.
+ Inevitably some students will be behind on their work and will complete their sync with upstream main after you have merged the PR for the addRound2Conflicts branch. In these cases, their pull requests will not create a conflict to be resolved. These students should follow the instructions given in . These directions have them pull the mergeConflictPractice branch and create a pull request for it. That PR will then contain conflicts with the changes in the addRound2Conflicts branch that was merged into main. They will then complete the activity using the mergeConflictPractice branch as it it were their feature branch. Students not in this situation, but who would like additional practice can also pull and use the mergeConflictPractice branch at the end of the activity.
+
+
+
+
+ .
+
+
- These students should follow the instructions given in . These directions have them pull the mergeConflictPractice branch and create a pull request for it. That PR will then contain conflicts with the changes in the addRound2Conflicts branch that was merged into main. They will then complete the activity using the mergeConflictPractice branch as it it were their feature branch. Students not in this situation, but who would like additional practice can also pull and use the mergeConflictPractice branch at the end of the activity.
+ By default, VS Code does not display the best common ancestor in its merge tool. The steps given in these questions has the students change the VS Code configuration such that it includes the best common ancestor.
- This set of materials may be a little short for a 75-minute class period. The remaining class time can be used to help students who had difficulties creating a PR, whose PR's cannot be merged automatically or are missing the "Closes" or "Fixes" lines.
+ This set of materials may be a little short for a 75-minute class period. The remaining class time can be used to help students who had difficulties creating a PR, who's PR's cannot be merged automatically or are missing the "Closes" or "Fixes" lines.
Working Locally and Upstreaming Changes Instructor Notes
- This chapter focuses on the upstreaming process. Students learn about feature branches, staging and committing changes, pushing feature branches to their origin repository, and making a pull request. At the end of the hands-on activity each student will have experienced the full forking workflow, resulting in a pull request to the upstream GitKit-FarmData2 repository for changes that fix the "Round 1" issue that they were assigned. The "Round 1" issues have been created such that they do not conflict with each other. Thus, all of the student pull requests should be able to be merged automatically. The instructor will typically perform these merges as a demonstration at the start of the class introducing .
+ This chapter focuses on the upstreaming process. Students learn about feature branches, staging and committing changes, pushing feature branches to their origin repository, and making a pull request. At the end of the hands-on activity each student will have experienced the full forking workflow, resulting in a pull request to the upstream GitKit-FarmData2 repository for changes that fix the "Round 1" issue that they were assigned. The "Round 1" issues have been created such that they do not conflict with each other. Thus, all of the student pull requests should be able to be merged automatically. The instructor will typically perform these merges as a demonstration at the start of .
The exercises in this chapter have the students perform the following major tasks:
@@ -138,11 +138,11 @@
-
+
- If a student is seeing commit dates, usernames and messages that differ from the correct answers then it is likely that they created their fork after PRs were merged at the start of . Other than difficulty answering these questions this will not cause an issue with continuing with this chapter. Issues will arise with the exercises in and . Each of those locations provide the students with instructions for resolving the issues at the point where they arise.
+ If a student is seeing commit dates, usernames and messages that differ from the correct answers then it is likely that they created their fork after PRs were merged at the start of . Other than difficulty answering these questions this will not cause an issue with continuing with this chapter. Issues will arise with the exercises in and . Each of those chapters provide the students with instructions for resolving the issues at the point where they arise.
@@ -155,6 +155,16 @@
The git status command here should show one untracked file with modifications and that file should agree with the file that they identified in .
+
+
+
+
+
+
+
+ This question is a good checkpoint to ensure that they have done things correctly to this point. The most recent commit in the git log output should show that they committed changes to the correct file (i.e. the one from ) and that they have used a meaningful commit message.
+
- This chapter focuses on merge conflicts, why they arise and how they can be resolved. We saw that maintainers are regularly merging changes from contributor's pull requests into the upstream main branch. If those changes are merged after you created your feature branch, it is possible for a merge conflict to arise. If your changes and those merged into main affect different parts of the project, then the maintainers will still be able to merge your changes automatically. However, if the changes merged into main and the changes in your feature branch alter the same code or documentation, then a merge conflict will occur. Usually, you as the contributor and the expert on your work, will be asked to resolve the merge conflict so that the maintainers can merge your pull request automatically. In completing the most previous chapter, you will have created a pull request that, after other work was merged into the upstream main branch, has resulted in a merge conflict. This set of activities takes you through the process of resolving that merge conflict.
+ This chapter focuses on merge conflicts, why they arise and how they can be resolved. We saw that maintainers are regularly merging changes from contributor's pull requests into the upstream main branch. If those changes are merged after you created your feature branch, it is possible for a merge conflict to arise. If your changes and those merged into main affect different parts of the project, then the maintainers will still be able to merge your changes automatically. However, if the changes merged into main and the changes in your feature branch alter the same code or documentation, then a merge conflict will occur. Usually, you as the contributor and the expert on your work, will be asked to resolve the merge conflict so that the maintainers can merge your pull request automatically. We saw that this can be done by manually editing the raw merge conflict information or by using a graphical merge tool. In completing the most previous chapter, you will have created a pull request that, after other work was merged into the upstream main branch, has resulted in a merge conflict. This set of activities takes you through the process of resolving that merge conflict.
-
diff --git a/source/ch-merge-conflicts/images/basic-merge-tool-options.png b/source/ch-merge-conflicts/images/basic-merge-tool-options.png
deleted file mode 100644
index 9610331..0000000
Binary files a/source/ch-merge-conflicts/images/basic-merge-tool-options.png and /dev/null differ
diff --git a/source/ch-merge-conflicts/images/conflicting-upstream-changes.png b/source/ch-merge-conflicts/images/conflicting-upstream-changes.png
index 3ed481c..d0e7bf2 100644
Binary files a/source/ch-merge-conflicts/images/conflicting-upstream-changes.png and b/source/ch-merge-conflicts/images/conflicting-upstream-changes.png differ
diff --git a/source/ch-merge-conflicts/images/github-pr-conflict.png b/source/ch-merge-conflicts/images/github-pr-conflict.png
deleted file mode 100644
index 048ed15..0000000
Binary files a/source/ch-merge-conflicts/images/github-pr-conflict.png and /dev/null differ
diff --git a/source/ch-merge-conflicts/images/github-pr-no-conflict.png b/source/ch-merge-conflicts/images/github-pr-no-conflict.png
deleted file mode 100644
index a9d3c6c..0000000
Binary files a/source/ch-merge-conflicts/images/github-pr-no-conflict.png and /dev/null differ
diff --git a/source/ch-merge-conflicts/images/mergetool-settings.png b/source/ch-merge-conflicts/images/mergetool-settings.png
new file mode 100644
index 0000000..466b22b
Binary files /dev/null and b/source/ch-merge-conflicts/images/mergetool-settings.png differ
diff --git a/source/ch-merge-conflicts/images/mergetool-window-new-settings.jpg b/source/ch-merge-conflicts/images/mergetool-window-new-settings.jpg
new file mode 100644
index 0000000..8b59fb0
Binary files /dev/null and b/source/ch-merge-conflicts/images/mergetool-window-new-settings.jpg differ
diff --git a/source/ch-merge-conflicts/images/mergetool-window.jpg b/source/ch-merge-conflicts/images/mergetool-window.jpg
new file mode 100644
index 0000000..6f2401a
Binary files /dev/null and b/source/ch-merge-conflicts/images/mergetool-window.jpg differ
diff --git a/source/ch-merge-conflicts/images/placeholder.txt b/source/ch-merge-conflicts/images/placeholder.txt
new file mode 100644
index 0000000..4ecebfd
--- /dev/null
+++ b/source/ch-merge-conflicts/images/placeholder.txt
@@ -0,0 +1 @@
+Can delete this if images are added.
\ No newline at end of file
diff --git a/source/ch-merge-conflicts/images/synching-with-upstream-with-conflict.png b/source/ch-merge-conflicts/images/synching-with-upstream-with-conflict.png
deleted file mode 100644
index 945675e..0000000
Binary files a/source/ch-merge-conflicts/images/synching-with-upstream-with-conflict.png and /dev/null differ
diff --git a/source/ch-merge-conflicts/images/vscode-launch-mergetool.png b/source/ch-merge-conflicts/images/vscode-launch-mergetool.png
new file mode 100644
index 0000000..e9f415f
Binary files /dev/null and b/source/ch-merge-conflicts/images/vscode-launch-mergetool.png differ
diff --git a/source/ch-merge-conflicts/sec-appendix-a.ptx b/source/ch-merge-conflicts/sec-appendix-a.ptx
index 2bdfd73..2d5020c 100644
--- a/source/ch-merge-conflicts/sec-appendix-a.ptx
+++ b/source/ch-merge-conflicts/sec-appendix-a.ptx
@@ -22,7 +22,7 @@
Ensure that you are in your local repository in a Terminal. Use the following commands to restore your main branch to the state before the conflicts were introduced:
- While you were working on your Round2 issue your instructor, playing the role of a maintainer, merged some changes into the upstream main. These changes were merged after you created the feature branch for your Round2 issue. This situation is illustrated in .
-
-
-
-
-
Conflicting Upstream Changes.
-
-
- Changes were merged into the upstream main branch that could conflict with changes in the pull request feature branches.
-
-
-
-
-
-
- The changes that your instructor merged were specifically designed to create a conflict with the change that you made when you fixed your Round2 issue. Thus, the pull request you made in now contains a conflicting change and therefore cannot be merged automatically.
-
-
-
- The activities in the remainder of this section will reinforce your understanding of how the conflict arose, confirm that your main branch is out of synch with the upstream, and that your pull request cannot be merged automatically.
-
-
-
-
-
-
-
-
-
- Complete the following tasks that ask about the current situation, which is illustrated in .
-
-
-
-
-
-
- Which of the following commits (i.e. which color) in did the instructor add to the upstream main branch after you created the feature branch for your Round2 issue?
-
-
-
-
-
-
- Dark Blue
-
-
-
-
- Correct.
-
-
-
-
-
-
- Lime Green
-
-
-
-
- The lime green commit is not in the upstream main branch.
-
-
-
-
-
-
- Brown
-
-
-
-
- The brown commit is not in the upstream main branch.
-
-
-
-
-
-
- Light Blue
-
-
-
-
- The light blue commit was added to the upstream main before the contributors created their feature branches.
-
-
-
-
-
-
- Yellow
-
-
-
-
- The yellow commit was added to the upstream main before the contributors created their feature branches.
-
-
-
-
-
-
- Look at which commits are in upstream main branch that are not in the contributors' main branches.
-
-
-
-
-
-
-
- Which of the following commits (i.e. which color) in did you create that will create a merge conflict with the upstream main branch?
-
-
-
-
-
-
- Dark Blue
-
-
-
-
- The dark blue commit is already in the upstream main branch.
-
-
-
-
-
-
- Lime Green
-
-
-
-
- The lime green commit might create a merge conflict, but it is not your commit.
-
-
-
-
-
-
- Brown
-
-
-
-
- Correct!
-
-
-
-
-
-
- Light Blue
-
-
-
-
- The light blue commit is already in the upstream main branch.
-
-
-
-
-
-
- Yellow
-
-
-
-
- The yellow commit is already in the upstream main branch.
-
-
-
-
-
-
- Look for a commit in your local repository that might contain changes that could conflict with the changes in the dark blue commit.
-
-
-
-
-
-
-
-
- If everything is as we saw above, then the pull request that you created for your Round2 issue will contain a merge conflict with the upstream main branch. Let's confirm that it does before going on.
-
-
-
-
-
- Visit the upstream repo on GitHub, click on the "Pull requests" tab.
-
-
-
-
-
-
- Find and click on your Round2 pull request.
-
-
-
-
-
-
- Scroll down toward the bottom of the pull request.
-
-
-
-
-
-
- Which of the following messages do you see?
-
-
-
-
-
-
-
-
- GitHub message indicating that merging can be performed automatically.
-
-
-
-
-
-
- IMPORTANT: You should be seeing that your pull request cannot be merged automatically. Follow the instructions in to fix this problem.
-
-
- When your pull request cannot be merged automatically, return to this question and continue. See your instructor if you cannot resolve this problem.
-
-
-
-
-
-
-
-
- GitHub message indicating that there are merge conflicts that must be resolved.
-
-
-
-
-
-
- Excellent. Everything is as it should be. Please continue to the next exercise.
-
-
-
-
-
-
- I don't see either of the other messages.
-
-
-
-
- If you see a message about GitHub checking if the merge can be performed automatically, wait a few moments for one of the other messages to appear.
-
-
-
-
-
-
-
-
-
-
- We now know that your Round2 pull request contains a merge conflict and cannot be merged automatically. Place the following actions into an order which could have created this merge conflict.
-
-
-
-
-
-
- You created a feature branch.
-
-
-
-
- Changes were merged into upstream main.
-
-
-
-
- You fixed your Round2 issue.
-
-
-
-
- You made your Round2 PR.
-
-
-
-
-
- For a conflict to occur the upstream main branch must contain changes that are not in your feature branch.
-
-
-
-
- When would you have to create your feature branch for the upstream main branch to contain changes that are not in your feature branch.
-
- To do the extra practice you'll need to have your development environment running.
-
-
- Click here to open your development environment.
+ The upstream repository contains a branch created just for this practice. Use the following command to get this feature branch from the upstream into your local repo:
+
+
+
+ git fetch upstream merge-conflict-practice
+
+
+
- Please be patient as this can take a few minutes. When the development environment is ready you will see the message "Kit development environment is ready for use." and your browser window will look similar to the following:
+ The merge-conflict-practice branch was created so that it contains some conflicts with the upstream main branch. When you have fetched this branch, think of it as if you had created it from main, then made some changes that resulted in conflicts with the upstream main branch. This leaves you at the point where you are trying to merge main into this feature branch and resolve the conflicts (e.g. like in ).
-
-
-
- The GitKit Development Environment. The development environment is ready when you see the "Kit development environment is ready for use" message.
-
-
-
-
+
+
+
+
+ I have fetched the branch
+
+
+
-
-
-
- The upstream repository contains a branch created just for this extra practice. This branch was created so that it contains some pre-made conflicts with the upstream main branch.
-
-
-
-
-
- Use the following command to get this feature branch from the upstream into your local repo: git fetch upstream merge-conflict-practice
-
-
-
-
-
-
- Run the git branch -a command in the terminal to list all of the branches known to your local repository.
-
-
- Which of the following branches are listed?
-
-
-
-
-
-
- main
-
-
-
-
- Correct.
-
-
-
-
-
-
- remotes/upstream/merge-conflict-practice
-
-
-
-
- Correct.
-
-
-
-
-
-
- development
-
-
-
-
- Are you sure this branch exists?
-
-
-
-
-
-
- beta
-
-
-
-
- Are you sure this branch exists?
-
-
-
-
-
-
-
- If you do not see the remotes/upstream/merge-conflict-practice branch, try the git fetch command again.
-
-
+
+
+
+ I have not fetched the branch
+
+
+
+
+ Do not make continue until you have the merge-conflict-practice branch set up.
+
+
+
+
-
- At this point you should think of the merge-conflict-practice branch as a feature branch that you created from your main and then made some changes that resulted in conflicts with the upstream main branch. Thinking of the merge-conflict-practice branch this way leaves you at the point where you are trying to merge the modified upstream main into your feature branch as you did in ).
-
-
- Assuming that your main branch is active, select and order statements that will make the merge-conflict-practice branch active and then merge the main branch into it. Note: not all commands will be used.
+ Make the merge-conflict-practice branch active and try to merge main into it. Give the commands that you used and their output here.
-
-
-
- git switch merge-conflict-practice
-
-
-
-
- git merge main
-
-
-
-
- git merge merge-conflict-practice
-
-
-
-
- git switch main
-
-
-
-
-
- Review for how to merge main into a feature branch.
-
-
+
-
-
+
+
- Merging the main branch into the merge-conflict-practice branch will create some conflicts for you to resolve.
+ The merge-conflict-practice branch contains a few conflicts so the merge you attempted in should fail. Resolve the conflicts by accepting the changes from the merge-conflict-practice branch and all of the non-conflicting changes from the main branch.
-
-
-
-
- Execute the commands you selected in to perform the merge.
-
-
- In which file were the merge conflicts created?
-
-
-
-
-
-
- README.md
-
-
-
-
- Correct.
-
-
-
-
-
-
- ONBOARDING.md
-
-
-
-
- Check the hint.
-
-
-
-
-
-
- INSTALL.md
-
-
-
-
- Check the hint.
-
-
-
-
-
-
- LICENSE.md
-
-
-
-
- Check the hint.
-
-
-
-
-
-
- CONTRIBUTING.md
-
-
-
-
- Check the hint.
-
-
-
-
-
-
- The file containing the conflicts should have opened in the editor automatically when you performed the git merge operation.
-
-
-
+
+
+
+
+
+ I have resolved the conflicts
+
+
+
-
-
-
- How many merge conflicts were created?
-
-
-
-
-
-
- 1
-
-
-
-
- Correct.
-
-
-
-
-
-
- 2
-
-
-
-
- Check the hint.
-
-
-
-
-
-
- 3
-
-
-
-
- Check the hint.
-
-
-
-
-
-
- More than 3.
-
-
-
-
- Check the hint.
-
-
-
-
-
-
- Examine the README.md file that opened when you performed the merge operation. Look for places where raw merge conflict information appears.
-
-
-
+
+
+
+ I have not resolved the conflicts
+
+
+
+
+ Do not make continue until you resolve the conflicts.
+
+
+
+
-
+
- Choose and order the steps below to describe the sequence of things that you will do to resolve the merge conflicts that were created.
+ Save your changes and commit them to resolve the conflicts to your feature branch. Be sure to use a meaningful commit message. Give the commands that you used and their output here.
-
-
-
- Edit the merge conflict information.
-
-
-
-
- git stage README.md
-
-
-
-
- git commit -m "<message>"
-
-
-
-
- git push origin merge-conflict-practice
-
-
-
-
- Create a pull request to the upstream.
-
-
-
+
-
+
- Carry out the steps you identified above in and give a link to your pull request.
-
-
-
+ Push the merge-conflict-practice branch to your origin and create a pull request to the upstream. Give a link to your pull request.
-
-
-
-
-
-
- Thank you.
-
-
-
-
-
-
- Be sure that your URL is from your pull request to the upstream repository.
-
-
-
-
-
-
-
- Review sections and .
-
-
+
+
diff --git a/source/ch-merge-conflicts/sec-git-command-summary.ptx b/source/ch-merge-conflicts/sec-git-command-summary.ptx
index 93d8196..7837ddf 100644
--- a/source/ch-merge-conflicts/sec-git-command-summary.ptx
+++ b/source/ch-merge-conflicts/sec-git-command-summary.ptx
@@ -22,34 +22,18 @@
- git switch <branch>
- Change the active branch.
+ git merge <target>
+ Merge changes from source branches into a target branch
- git pull upstream main
- Synchronize the local main branch with the upstream main branch.
+ git merge --abort
+ Undo a merge that failed due to conflicts
- git push origin main
- Synchronize the origin main branch with the local main branch.
+ git mergetool
+ Launch the configured graphical merge tool
-
- git merge <source>
- Add changes to source branch into the active branch
-
-
- git stage <file>
- Indicate that changes to a file should be included in the next commit.
-
-
- git commit -m "<message>"
- Add staged changes to the active branch.
-
-
- git push origin "<branch>"
- Copy the named branch to your origin repository.
-
-
+
Note that the tasks listed are in approximately the same order as they appear in the sections of this chapter.
diff --git a/source/ch-merge-conflicts/sec-merging-the-main-branch-into-a-feature-branch.ptx b/source/ch-merge-conflicts/sec-merging-the-main-branch-into-a-feature-branch.ptx
index f0dbb6e..7d0d980 100644
--- a/source/ch-merge-conflicts/sec-merging-the-main-branch-into-a-feature-branch.ptx
+++ b/source/ch-merge-conflicts/sec-merging-the-main-branch-into-a-feature-branch.ptx
@@ -8,383 +8,147 @@
- Your local and origin main branches now contain the changes that were made to the upstream main branch. The next step is to merge the changes from the main branch into your feature branch.
+ Your local main branch now contains the changes that were made to the upstream main branch. The next step is to merge the changes from the main branch into your feature branch. This is like the example from class, which is illustrated in .
+
+
+ shows the main branch in the right panel, the contributor's feature branch in the left panel, and the common ancestor in the middle.
+
+
+
+
Merge main into feature branch
+
+
+ main branch timeline with feature branch merge
+
+
+
-
- Branch Vocabulary
-
-
- shows the merge example from the class slides.
-
+
+
-
-
-
Merging the main branch into a feature branch.
-
-
- Illustration of the main branch being merged into a feature branch.
-
-
-
-
-
-
- When two branches are merged the branch containing the changes to be merged is called the source branch, and the branch into which the changes are merged is called the target branch.
-
-
- When the changes in the source and target branches have been successfully merged a merge commit containing the merged changes is added to the target branch.
-
-
-
-
-
+
+
+
+ If you are going to merge the changes from the main branch into your feature branch, which branches will be the source branches? Which branch will be the target branch?
+
+ The git merge <branch name> command will attempt to merge the changes in the active branch with the changes in <branch name> (i.e. the source branches) into a merge commit in the currently active branch (i.e. the target branch).
+
+
+
- Match the branch names to the appropriate term below.
+ To use the merge command as just described your feature branch (i.e. the target branch) must be the active branch. Switch to your feature branch and confirm that it is now the active branch.
- Read the introduction to this section.
+ What were the commands you used? And their output? You can copy your work into the provided textbox.
-
-
-
+
+
+
+
- Which commit (i.e. which color) in is the merge commit created by merging the main branch into the hadPig branch?
+ Use the merge command to try to merge the changes contained in the main branch and in your feature branch into your feature branch.
-
-
-
-
-
- Dark blue with a brown ring.
-
-
-
-
- Correct. The dark blue commit in main was merged with the brown commit in the hadPig branch.
-
-
-
-
-
-
- Dark blue
-
-
-
-
- The dark blue commit is a commit in the main branch.
-
-
-
-
-
-
- Brown
-
-
-
-
- The brown commit is a commit in the hadPig branch.
-
-
-
-
-
-
- Pink
-
-
-
-
- The pink commit is a commit in the main branch.
-
-
-
-
-
-
- Light blue with a white ring.
-
-
-
-
- The light blue with a white ring is a merge commit in main. Likely from merging a pull request.
-
-
-
-
-
- Read the introduction to this section and examine .
+ What were the commands you used? And their output? You can copy your work into the provided textbox.
-
-
-
-
-
-
- The <c>git merge</c> Command.
-
-
- The command git merge <branch name> will attempt to merge the changes in the active branch with the changes in <branch name>.
-
-
-
-
-
+
+
+
+
+
+
+
+
+ The output from should indicate that the automatic merge failed due to a conflict. If your merge command did not fail due to a conflict, return to and follow the instructions from there again.
+
+
+
- Imagine that the main branch is the active branch. Select and arrange statements from those listed below such that the main branch will be merged into the hadPig branch as in . Note: Not all statements will be used.
+ In which file is the conflict located?
-
-
-
- git switch hadPig
-
-
-
-
- git merge main
-
-
-
-
- git merge hadPig
-
-
-
-
- git switch main
-
-
-
-
-
-
-
-
- To merge the main branch into your feature branch, your feature branch must be the active branch. Let's ensure that your feature branch is the active branch.
-
-
-
-
-
- Use the git switch <branch> command to make your feature branch the active branch.
-
-
-
-
-
-
- Use the git status command to check that your feature branch is now the active branch.
-
-
-
-
-
-
+
+
+
- Now that your feature branch is the active branch, give a command that will merge the main branch into your feature branch.
+ Use the cat command to display the file containing the conflict.
-
+ Find the part of the file that contains the raw conflict information and copy and paste it here. Be sure to include the chevrons at the top and bottom of the conflict information.
-
-
-
-
-
- Correct.
-
-
-
-
-
-
- You want to merge the main branch into your feature branch, which is the active branch.
-
-
-
-
-
-
- Review the format of the git merge command above.
-
-
-
-
-
-
- The command you want is in .
-
-
-
-
-
-
- Be sure you are using your GitHub origin repository (see ). This clone URL should contain your GitHub username and end in .git.
-
+
+
-
+
- Now let's try top merge the changes in the main branch into your feature branch.
+ Answer the following questions by copying the appropriate portion of the output that you gave in .
-
+
- Run your merge command from in the terminal.
+ What is the part of the output that is the Best Common Ancestor?
+
-
+
- Which of the following statements best describes what happened when you ran your merge command?
+ What is the part of the output that shows the changes that the maintainers merged into the main branch after you made your feature branch?
-
-
-
-
- The terminal displays a message indicating "Automatic merge failed; fix conflicts and then commit the result."
-
-
-
-
- Excellent! Because there is a merge conflict between the main branch and your feature branch, this is what we expect. Continue to the next exercise.
-
-
-
-
-
-
- The "GNU nano" editor opens with the first line of text being "Merge branch 'main' into" your feature branch.
-
-
-
-
- Uh Oh! Something went wrong. Let's try to fix it.
-
-
Press Ctrl-x to exit the nano editor.
-
Run the command git revert --hard HEAD~1
-
Go back to and ensure that your pull request contains a conflict.
-
Then try your merge command again.
-
-
-
-
-
-
-
- Something else happened.
-
-
-
-
- Double check that your merge command from is correct and that you typed it into the terminal correctly.
-
-
-
-
+
-
+
- Which of the following things also happened when you ran your merge command?
+ What is the part of the output that shows your changes?
-
-
-
-
- The terminal displays a message indicating that there is a "Merge conflict in README.md."
-
-
-
-
- Correct.
-
-
-
-
-
-
- The README.md file is opened in the editor.
-
-
-
-
- Correct.
-
-
-
-
-
-
- The conflict is automatically resolved.
-
-
-
-
- The conflict cannot be automatically resolved because there is a conflict.
-
-
-
-
-
-
- The development environment plays a sad song because there is a conflict.
-
-
-
-
- That would be fun, but unfortunately not.
-
-
-
-
-
-
- Look at the output in the terminal and the file that is open in the development environment.
-
-
+
-
+
+
+
+
+
+ Sometimes when you try to merge, and it fails due to a conflict you may want to undo the attempted merge. The git merge --abort command will undo a failed merge.
+
+
+ Undo the merge that you started in and use the cat command to display the file that contains the conflict again.
+
+
+ Briefly explain how you can tell from the output of cat that the failed merge has been undone?
+
- Image illustrating changes merged into the upstream that conflict with a local branch.
+ Cloud image of the changes merged into the upstream that conflict with a local branch
- This section will walk you through the process of resolving the merge conflict. In you merged the main branch into your feature branch. This created a merge conflict. In this section you will edit the raw merge conflict information to resolve the conflict and then you will stage and commit the merged changes.
+ This section will walk you through the process of resolving the merge conflict using a graphical merge tool. The flow of this process is illustrated in Figure 3. You will switch to your feature branch, perform the merge, use the graphical merge tool to resolve the resulting conflict, and then stage and commit the merged content.
-
- Raw Merge Conflict Information
-
-
- After completing the README.md file should be open in your editor and the raw merge conflict information should be displayed.
-
-
- If you are not seeing the README.md file open it from the EXPLORER pane. If you are not seeing the merge conflict information, scroll through the README.md file to the location where you made your change. The raw merge conflict information should appear there. If it does not, return to and try to correct the issue.
-
-
+
+
-
-
+
+
+
+ Ensure that you are on your feature branch. Then issue the command to merge the main branch into your feature branch (like you did in ). The merge should once again fail because of the conflict. Use the cat command to confirm that the raw merge conflict information now appears in the conflicted file again.
+
+
+
+
+ As you have seen when a merge fails git places the raw merge conflict information into the conflicted files. You could simply edit that file to resolve the merge conflict. However, in practice it is usually easier to use a mergetool.
+
-
-
+
+ Opening the MergeTool:
+
+
+ The KitClient you are using has been configured so that the git mergetool command will launch the the VSCode graphical merge tool, which you can use to resolve the conflict.
+
+
+ The KitClient you are using has configured VS Code's Merge Editor as a mergetool.
+
+
+
+
+
+ The git mergetool command will launch the VSCode merge tool so that you can use it to resolve the conflict.
+
+
+ To open a file in VS Code's Merge Editor:
+
+
+
+
- The editor window for the README.md file displays the raw conflict information that has resulted from the merge. The following tasks ask you some question about this information.
+ Issue the git mergetool command.
-
-
-
-
- Match the terms below to the descriptions based upon what is displayed in the editor.
-
-
-
-
- Feature branch contents
-
- Appears with a green highlight at the top of the conflict information.
-
-
-
- Best common ancestor
-
- Appears with a gray highlight in the middle of the conflict information.
-
-
-
- main branch contents
-
- Appears with a blue highlight at the bottom of the conflict information.
-
-
-
-
-
-
-
- Match the terms below to the descriptions based upon what is displayed in the editor.
-
-
-
-
-
- Left Chevrons <<<<<<<
-
-
- Indicate the start of the merge conflict information.
-
-
-
-
- Vertical Bars |||||||
-
-
- Separate the feature branch content from the best common ancestor.
-
-
-
- Equal Signs =======
-
- Separate the best common ancestor from the main branch content.
-
-
-
-
- Right Chevrons >>>>>>>
-
-
- Indicate the end of the merge conflict information.
-
-
-
-
-
-
-
-
-
- Resolving the Merge Conflict
-
-
- Recall that the merge conflict that you are seeing arose because your feature branch and the upstream main branch contain changes to the same part of the file. In this situation, Git is not able to automatically decide which changes to keep or how to combine the changes. This decision must be made by a developer, in this case... by you!
-
-
- It is possible to resolve merge conflicts by editing the raw merge information, including removing the chevrons and dividers. However, most development environments, including the one you are using, provide special tools to help with the resolution of merge conflicts.
-
-
- The basic merge tool in your development environment provides four options to assist with resolving merge conflicts. These options appear in the editor just above the merge conflict information as shown in .
-
-
-
-
The basic merge tool options.
-
-
- Image illustrating the basic merge tool options of "Accept Current Change", "Accept Incoming Change", "Accept Both Changes", "Compare Changes".
-
-
-
-
-
-
-
-
-
- Match the option you would choose to perform each of the indicated operations.
+ When VS Code's Merge Editor is first opened, it will open a window containing three panes (LOCAL, REMOTE and Result). The content that you see will be different, but the window that you see should be similar to the one shown in .
-
-
-
-
- Accept Current Change
-
-
- Accept the changes in your feature branch.
-
-
-
-
- Accept Incoming Change
-
-
- Accept the changes in the main branch.
-
-
-
-
- Compare the terms used in the merge tool options to the information displayed in the first and last lines of the merge conflict information.
+
+
Merge Editor Window (example)
+
+
+ merge editor window
+
+
+
-
-
-
-
+
+
+
- Click the option that will accept the changes in your feature branch.
+ Open the conflicted file, and click the "Resolve in Merge Editor" ( ) button in the lower right corner of the editor pane.
- Choose the description below that best describes What happens?
+
+
Conflicting Upstream Changes.
+
+
+ VS Code's "Resolve in Merge Editor" button
+
+
+
-
-
-
-
-
- Only the changes from the feature branch remain.
-
-
-
-
- Correct.
-
-
-
-
-
-
- Only the changes from the main branch remain.
-
-
-
-
- Check the editor contents after you click "Accept Current Change".
-
-
-
-
-
-
- The changes from the main branch and the chevrons remain.
-
-
-
-
- Check the editor contents after you click "Accept Current Change".
-
-
-
-
-
-
- The changes from the feature branch and the chevrons remain.
-
-
-
-
- Check the editor contents after you click "Accept Current Change".
-
-
-
-
-
- Click "Accept Current Change" and check the editor contents.
+ When VS Code's Merge Editor is first opened, it will open a window containing three panes (LOCAL, REMOTE and Result). The content that you see will be different, but the window that you see should be similar to the one shown in .
-
-
-
-
-
-
- If you would like to try out the other merge options you can undo your changes by opening the Hamburger menu (☰), clicking on "Edit" and choosing "Undo".
-
-
- This basic merge tool is helpful for resolving small uncomplicated merge conflicts. Most development environments also provide more advanced merge tools for working with more complex conflicts. The use of those tools is beyond the goals of this chapter.
-
-
-
-
-
- Committing the Merged Changes
-
-
-
-
- At this point you have resolved the merge conflict, but the resulting changes have not been committed to your feature branch. In this section you will commit those changes to your feature branch.
-
-
-
-
- Run the git status command in the terminal and use its output to answer the following questions.
+
+
Merge Editor Window (example)
+
+
+ merge editor window
+
+
+
-
-
-
-
- Which of the following appear in the output of the git status command and indicate that your merged changes have not yet been committed to your feature branch?
-
-
-
-
-
-
- You have unmerged paths.
-
-
-
-
- Correct.
-
-
-
-
-
-
- both modified: README.md
-
-
-
-
- Correct.
-
-
-
-
-
-
- no changes added to commit
-
-
-
-
- Correct.
-
-
-
-
-
-
- All conflicts fixed
-
-
-
-
- Check the output again.
-
-
-
-
-
-
- Your branch is behind 'origin'
-
-
-
-
- Check the output again.
-
-
-
-
-
-
- Run the git status command and read the output carefully.
-
-
-
-
-
-
-
- Imagine that after you completed the merge you realize that you didn't merge the changes the way you had intended. Which Git command could you use to undo your merge?
-
-
-
-
-
-
- git merge --abort
-
-
-
-
- Correct.
-
-
-
-
-
-
- git merge --undo
-
-
-
-
- Close. Check the output again.
-
-
-
-
-
-
- git undo merge
-
-
-
-
- Check the output again.
-
-
-
-
-
-
- git merge revert
-
-
-
-
- Check the output again.
-
-
-
-
-
-
- Run the git status command and read the output carefully.
-
-
-
-
-
-
- Feel free to try out the git merge --abort command. After you run it, the raw merge conflict information will reappear in the README.md file. Be sure to re-merge the changes from your feature branch before moving on.
-
-
-
+
+
+
- From you can see that you now have uncommitted changes. Those changes are the changes you made when resolving the merge conflict. The next step is to commit your changes.
+ Changing a few of the default settings will make the use of the merge tool easier to understand by displaying the Best Common Ancestor and both non-conflicting and conflicting changes.
- Choose and order the commands that you would use to commit your changes to your local repository. Note: Not all commands will be used.
+ Use the "…" menu in the upper right of the merge tool window and check the "" and "" options as shown in .
- Run the first command from in the terminal. Then run the git status command and examine its output.
+ With these options enabled, the merge tool window should now contain 4 panes (LOCAL, Base, REMOTE and Result) and look similar to the one shown in .
- What does git status tell you to do to conclude the merge?
+
+
Merge Editor Window (example) with new settings
+
+
+ merge editor window with new settings
+
+
+
-
-
-
-
- use "git commit" to conclude merge
-
-
-
-
- Correct. You already knew that, but its good to know that git status provides helpful tips. Use it often!
-
-
-
-
-
-
- use "git pull" to conclude merge
-
-
-
-
- git pull performs a different function and will not conclude the merge.
-
-
-
-
-
-
- use "git push" to conclude merge
-
-
-
-
- git push performs a different function and will not conclude the merge.
-
-
-
-
-
-
- use "git restore" to conclude merge
-
-
-
-
- git restore performs a different function and will not conclude the merge.
-
-
-
-
-
+
+
+
- Run the git status command and read the output carefully.
+ Do you have your merge tool window showing four panes and their content?
-
-
-
-
+
+
+
+ Do not make changes until you have your merge tool set up.
+
+
+
+
- Run the second command from in the terminal. Be sure to replace the <message> placeholder with a meaningful commit message. Then use git status and examine the output.
+ Using your answer to , compare the Result pane to the Best Common Ancestor. How are they different? Why?
+
+
+
+
+
+
+
+
+ When using the merge tool, you resolve conflicts by modifying the Result pane so that it appears as desired. You can use the point-and-click "Accept ..." and "Remove ..." options provided by the merge tool to move content into or out of the Result pane or you can edit the Result pane directly.
+
+
+ Use the merge tool to resolve the conflict so that the Result contains:
+
+
+ your changes where there is a conflict.
+
+
+ all of the non-conflicting changes from the main branch.
+
+
+
+
+ Copy your final merged result here.
+
+
+
+
+
+
+
+
+ Save your changes in the merge tool and close the merge tool window.
+
+
+ Then issue a git status command.
+
+
+
+
- What does git status tell you that indicates that your changes have been committed?
+ Copy the text for your command and its output. Be sure that your output shows the names of any files containing changes that need to be committed.
-
-
-
-
- nothing to commit, working tree clean
-
-
-
-
- Correct.
-
-
-
-
-
-
- merge complete
-
-
-
-
- True, but that's not the message that is displayed.
-
-
-
-
-
-
- changes successfully merged
-
-
-
-
- True, but that's not the message that is displayed
-
-
-
-
-
+
+
+
+
- Run the git status command and read the output carefully.
+ Briefly explain why the output you see in makes sense based on what you have done.
-
-
-
-
-
+
+
+
+
+
+
+
+
+ From you can see that you now have uncommitted changes. Those changes are all of the changes you made to the Result panel when performing the merge in the merge tool.
+
+
+ Commit the changes you made in resolving the conflict. Be sure to use a meaningful commit message.
+
+
+ Copy the commands that you used and their output.
+
- From the previous section you know that there is a merge conflict between the upstream main branch and your feature branch. Before you can resolve this conflict you will need to get the changes from the upstream main branch into your local and origin main branches.
+ shows the main branch has committed changes that conflict with what the local branch wants to commit.
- The process you learned for synchronizing with the upstream in ( and ) will copy the changes in the upstream main branch into your local and origin main branches. This process is illustrated in .
-
-
-
-
-
Synchronizing with the upstream.
-
+
+
Conflicting Upstream Changes.
+
- Using pull and push to synchronize the local and origin main branches with the upstream main branch.
+ Cloud image of the changes merged into the upstream that conflict with a local branch
-
- The exercises in the remainder of this section will help you to synchronize your local and origin main branches with the upstream main branch.
+ In class we saw that the maintainers had merged some changes into the upstream main after you had created your feature branch. The changes that were merged were specifically designed to conflict with the changes required for each of the Round2 issues. Thus, the pull request that you made at the end of the previous activity will now contain conflicts that prevent it from being merged automatically. This situation is shown in , where the maintainers have merged the dark blue commit into the main branch.
+
+
+ The activities in the remainder of this section will have you confirm that you are out of synch with the upstream and that your pull request cannot be merged automatically. It will then have you synch the main branch in your local and origin repos with the upstream, so that you can resolve the merge conflict.
+
+ Like the last activity, you will be working within the KitClient for this activity.
+
+
+
+
+
+
+ Restart your KitClient based on the instructions in
+
+
+
+
+
+
+
+ Answer the following based on .
+
+
-
+
- To do the synchronization you'll need to have your development environment running.
-
-
- Click here to open your development environment.
-
-
- Please be patient as this can take a few minutes. When the development environment is ready you will see the message "Kit development environment is ready for use." and your browser window will look similar to the following:
+ Which of the commits (i.e. which colors) in might contain merge conflicts after the dark blue commit was merged?
-
-
-
- The GitKit Development Environment. The development environment is ready when you see the "Kit development environment is ready for use" message.
-
-
-
-
-
+
+
+
+
+ Dark Blue
+
+
+
-
+
- Assuming your feature branch is currently the active branch, arrange the the commands below into the order they would be used to synchronize your main branches with the upstream main branch. Note: Not all commands will be used.
+ Lime Green
-
-
-
- git switch main
-
-
-
-
- git pull upstream main
-
-
-
-
- git push origin main
-
-
-
-
- git pull origin main
-
-
-
-
- git push upstream main
-
-
-
-
+
+
+
+
- Review and for how to synchronize with the upstream main.
+ Brown
-
-
+
+
-
+
- Run the commands that you identified in in the terminal.
+ Green
-
+
+
+
+
+
+
+ Look at which commits are new in upstream that are not part of the local repository's main or feature branch.
+
+
+
+
+
+
+
+
+ Visit the main page for your origin repo on GitHub and make sure that the main branch is active. You should be able to tell from this page that there have been changes to the upstream main branch that you have not yet synched (i.e. you are behind).
+
+
+ How many commits behind the upstream are you?
+
+
+
+
+
+
+
+
+ Now find your pull request in the upstream repo on GitHub. You should see that your pull request cannot be merged automatically.
+
+
If GitHub indicates that your pull request can be merged automatically follow the instructions in at the end of this activity sheet and then return to this question when you have a pull request that cannot be merged automatically.
+
Do not continue unless your pull request on GitHub shows that it cannot be merged automatically.
+
+
+
+
+
+
+ Does your pull request on GitHub show that it cannot be merged automatically?
+
+
+
+
+ If you don't have a merge conflict, you can't do the rest of the exercises in this section.
+
+
+
+
+
+
+ Briefly explain in a sentence or two of your own words, what happened that made your pull request go from being able to be merged automatically to now not being able to be merged automatically.
+
+
+
+
+
+ Think !
+
+
+
+
-
+
+
+
+ Use what you learned in the prior chapter to synch the main branch of your local and origin repos with the upstream. Don't forget to switch to your main branch first!
+
+
+
- Let's, confirm that your origin main branch is now synchronized with the upstream main branch.
+ What are the commands you used?
+
+
+
+
+
- Visit your origin repository and ensure that the main branch is active.
+ Check that you are now synchronized:
+
+
+
+ Check that the main branch on your origin repo on GitHub "is up to date…" (See ).
+
+
+
+
+ Use git status to check that the main branch in your local repo is up to date with your origin.
+
+
+
- Near the top of the page, you should see a message that is similar to one of the following. Select the message that is most similar to what you see.
+ If the main branch in your local or origin repos are not up to date, double check your synchronization commands in part and try again.
-
-
-
-
- This branch is up to date with <the upstream>.
-
-
-
-
- Excellent. Just as it should be. Continue on to the next exercise.
-
-
-
-
-
-
- This branch xx commits behind <the upstream>.
-
-
-
-
- Uh Oh. It doesn't look like your synchronization worked. Try running the commands from again.
-
- The exercises in this section provide practice in identifying merge conflicts and resolving them.
+ The exercises in this section provide practice in identifying merge conflicts and their resolutions.
-
- Merge Example 1
+
+
+
+
+ shows the main branch in the right panel, the contributor's feature branch in the left panel, and the common ancestor in the middle.
+
+
+
+
Example merge conflicts with Best Common Ancestor.
+
+
+ Three panels of code (feature branch, common ancestor, main branch)
+
+
+
+
+
+
+
+
- Consider . This figure shows a feature branch (in the left panel) that is to be merged into the current main branch (in the right panel). The center panel shows the best common ancestor from which both the feature branch and main branch have diverged.
-
-
- The current main branch contains changes, merged by the maintainers, to fix several bugs that existed in the best common ancestor. The feature branch has been changed to use more descriptive variable names, but has not fixed the bugs.
-
-
-
-
Example merge conflicts with Best Common Ancestor.
-
-
- Three panels of code (feature branch, best common ancestor, main branch)
-
-
-
+ Consider the merge shown in . As shown in the right-hand panel, the maintainers have merged commits into the main branch that fix several bugs that existed in the program. The left-hand panel shows a contributor's feature branch with has been changed to use more descriptive variable names but that has not fixed the bugs. The center panel shows the best common ancestor of the feature and main branches.
-
-
-
-
+
- Study the program shown in the main branch of . Then choose the statement below that best describes the computation the program is trying to perform. Note: The Feature Branch and the Best Common Ancestor both contain bugs.
+ Study the program in the main branch and then describe in a sentence the computation that the program is trying to perform. Note: The Feature Branch and the Best Common Ancestor both contain bugs.
-
-
-
-
- Find the average of a list of numbers.
-
-
-
-
- Correct.
-
-
-
-
-
-
- Find the total of a list of numbers.
-
-
-
-
- Consider the last line in the main branch.
-
-
-
-
-
-
- Count how many numbers the user enters.
-
-
-
-
- What does the program do besides count the numbers?
-
-
-
-
-
-
- None of these.
-
-
-
-
- One of the other answers is correct.
-
-
-
-
-
+
+
-
-
+
+
- When both the feature branch being merged and the main branch that it is being merged into contain changes with respect to the best common ancestor, those changes can be non-conflicting or conflicting.
+ Highlight (by clicking, or by circling) all of the lines that are non-conflicting changes in the feature branch or the main branch. Use the example in the slides as a guide for highlighting.
-
-
-
-
- Select the statement below that best describes a non-conflicting change.
-
-
-
-
-
-
- A non-conflicting change occurs when a part of the code changes in the feature branch or in the main branch but not in both.
-
-
-
-
- Correct.
-
-
-
-
-
-
- A non-conflicting change occurs when a part of the code changes in both the feature branch and the main branch.
-
-
-
-
- Review the definitions of non-conflicting and conflicting changes in the class slides.
-
-
-
-
-
-
- A non-conflicting change occurs when the best common ancestor is modified.
-
-
-
-
- The best common ancestor cannot be changed, all changes are either in the feature branch or the main branch.
-
-
-
-
-
-
- A non-conflicting change occurs when part of the feature branch contains only one change.
-
-
-
-
- You need to consider changes to both the feature branch and the main branch to determine if a change is non-conflicting.
-
-
-
-
-
-
-
-
-
- Select the statement below that best describes a conflicting change.
-
-
-
-
-
-
- A conflicting change occurs when a part of the code changes in the feature branch or in the main branch but not in both.
-
-
-
-
- Review the definitions of non-conflicting and conflicting changes in the class slides.
-
-
-
-
-
-
- A non-conflicting change occurs when a part of the code changes in both the feature branch and the main branch.
-
-
-
-
- Correct.
-
-
-
-
-
-
- A conflicting change occurs when the best common ancestor is modified.
-
-
-
-
- The best common ancestor cannot be changed, all changes are either in the feature branch or the main branch.
-
-
-
-
-
-
- A conflicting change occurs when a part of the feature branch contains multiple changes.
-
-
-
-
- You need to consider changes to both the feature branch and the main branch to determine if a change is conflicting.
-
-
-
-
-
-
+
+
+
+
+ Feature Branch
+ Best Common Ancestor
+ main Branch
+
+
+ total=0
+ tot=0
+ tot=0
+
+
+ count=0
+ count=0
+ count=0
+
+
+ read n
+ read n
+ read n
+
+
+ while count > n:
+ while count > n:
+ while count < n:
+
+
+ read m
+ read m
+ read m
+
+
+ total=total+m
+ tot=tot+m
+ tot=tot+m
+
+
+ count--
+ count--
+ count++
+
+
+ average=count total
+ ave=count tot
+ ave=tot count
+
+
+
+
+
+ Merge conflicts occur when both source branches change the same line.
+
+
+
-
-
+
+
+
- The questions below will now ask you to identify the non-conflicting and conflicting changes that exist in the merge from .
+ Highlight (by clicking, or by circling) all of the lines that are conflicting changes in the feature branch and the main branch as shown in . Use the example in the slides as a guide for highlighting.
-
-
-
-
- Highlight (by clicking) all of the lines in the main branch and the feature branch that contain non-conflicting changes. Use the example in the course slides as a guide.
-
-
-
-
-
-
- Feature Branch
- Best Common Ancestor
- main Branch
-
-
- total=0
- tot=0
- tot=0
-
-
- count=0
- count=0
- count=0
-
-
- read n
- read n
- read n
-
-
- while count > n:
- while count > n:
- while count < n:
-
-
- read m
- read m
- read m
-
-
- total=total+m
- tot=tot+m
- tot=tot+m
-
-
- count--
- count--
- count++
-
-
- average=count total
- ave=count tot
- ave=tot count
-
-
-
-
-
- Non-conflicting changes occur when a part of the code changes in either the feature branch or the main but not both.
-
-
-
+
+
+
+
+ Feature Branch
+ Best Common Ancestor
+ main Branch
+
+
+ total=0
+ tot=0
+ tot=0
+
+
+ count=0
+ count=0
+ count=0
+
+
+ read n
+ read n
+ read n
+
+
+ while count > n:
+ while count > n:
+ while count < n:
+
+
+ read m
+ read m
+ read m
+
+
+ total=total+m
+ tot=tot+m
+ tot=tot+m
+
+
+ count--
+ count--
+ count++
+
+
+ average=count total
+ ave=count tot
+ ave=tot count
+
+
+
+
+
+ Merge conflicts occur when both source branches change the same line.
+
+
+
-
-
-
- Highlight by clicking all of the lines in the main and feature branches that contain conflicting changes. Use the example in the course slides as a guide.
-
-
-
-
-
-
- Feature Branch
- Best Common Ancestor
- main Branch
-
-
- total=0
- tot=0
- tot=0
-
-
- count=0
- count=0
- count=0
-
-
- read n
- read n
- read n
-
-
- while count > n:
- while count > n:
- while count < n:
-
-
- read m
- read m
- read m
-
-
- total=total+m
- tot=tot+m
- tot=tot+m
-
-
- count--
- count--
- count++
-
-
- average=count total
- ave=count tot
- ave=tot count
-
-
-
-
-
- Conflicting changes occur when the same part of the code is changed both the feature branch and the main branch.
-
-
-
-
+
+
+
+ Would the feature branch in be able to be merged automatically by the project maintainers? Briefly explain your answer.
+
+
+
+
-
-
-
- Select the statement below that best describes why the feature branch in would, or would not, be able to be merged automatically by the project maintainers.
-
-
-
-
-
-
- The feature branch cannot be merged automatically because there is a conflicting change.
-
-
-
-
- Correct. The last line contains changes in both main and the feature branch.
-
-
-
-
-
-
- The feature branch can be merged automatically because there all of the changes are non-conflicting.
-
-
-
-
- Are you sure there are no conflicting changes?
-
-
-
-
-
-
- The feature branch cannot be merged automatically because there are non-conflicting changes.
-
-
-
-
- Non-conflicting changes can (usually) be merged automatically.
-
-
-
-
-
-
- It is not possible to tell if the feature branch can be merged automatically.
-
-
-
-
- If there are conflicting changes then the feature branch will not be able to be merged automatically.
-
-
-
-
-
-
- The feature branch cannot be merged automatically because there are changes both in main and in the feature branch.
-
-
-
-
- Close. What type of changes prevent automatic merges?
-
-
-
-
-
+
+
+
+ Highlight the correct lines that give a Merged Result of the program in that combines the feature branch and the main branch such that the result both performs the desired computation and uses the more descriptive variable names.
+
- Use the table below to indicate how the feature branch would be merged into the main branch. Each line that contains a change is shown in boldface. Click the change the feature branch or the main branch to indicate the version of the line that will appear in the merged result. The merged result should include all non-conflicting changes and should resolve the conflicting change. The resulting program must perform the desired computation as identified in
-
-
-
-
-
-
- Feature Branch
- Best Common Ancestor
- main Branch
-
-
- total=0
- tot=0
- tot=0
-
-
- count=0
- count=0
- count=0
-
-
- read n
- read n
- read n
-
-
- while count > n:
- while count > n:
- while count < n:
-
-
- read m
- read m
- read m
-
-
- total=total+m
- tot=tot+m
- tot=tot+m
-
-
- count--
- count--
- count++
-
-
- average=count total
- ave=count tot
- ave=tot count
-
-
-
-
-
- Select all of the non-conflicting changes and choose the conflicting change that ensures that the program will work correctly.
-
-
-
-
-
+
+ shows the main branch in the right panel, the contributor's feature branch in the left panel, and the common ancestor in the middle.
+
+
+
+
Example merge conflicts with Best Common Ancestor.
+
+
+ Three panels of code (feature branch, common ancestor, main branch)
+
+
+
+
-
- Merge Example 2
+
- shows another example of a contributor's feature branch that is to be merged into the main branch.
-
-
- As in the previous example, the right-hand panel shows commits that the maintainers have merged into the main branch to fix a bug that existed in the program. The left-hand panel shows the contributor's feature branch with changes that also fix the bug, but in a different way. The center panel shows the best common ancestor of the feature and main branches.
-
-
-
-
Example merge conflicts with Best Common Ancestor.
-
-
- Three panels of code (feature branch, best common ancestor, main branch)
-
-
-
+ Now consider the merge shown in . As shown in the right-hand panel, the maintainers have merged commits into the main branch that fix several bugs that existed in the program. The left-hand panel shows a contributor's feature branch with has been changed to use more descriptive variable names but that has not fixed the bugs. The center panel shows the best common ancestor of the feature and main branches.
+
+
+
+ Study the program in the main branch and then describe in a sentence the computation that the program is trying to perform. Note: The ** indicates exponentiation (e.g. x**2 is x squared). Note: The Common Ancestor contains a bug that is fixed in different ways by the main branch and the feature branch.
+
+
+
+
-
-
-
-
-
-
- Study the program in . Then choose the statement below that best describes the computation the program is trying to perform. gNote: The ** operator indicates exponentiation, so x**2 computes x squared.
-
-
-
-
-
-
- Compute the area of a circle.
-
-
-
-
- Correct.
-
-
-
-
-
-
- Find the circumference of a circle.
-
-
-
-
- Close. Notice the use of ** to square the radius r.
-
-
-
-
-
-
- Compute the volume of a sphere.
-
-
-
-
- Close, but that formula would use r**3.
-
-
-
-
-
-
- None of these.
-
-
-
-
- One of the other answers is correct.
-
-
-
-
-
-
- The main branch fixes the bug in a strange way. So focusing on the feature branch may be easier.
-
-
-
+
+
+
+ Highlight (by clicking, or by circling) all of the lines that are non-conflicting changes in the feature branch or the main branch as shown in . Use the example in the slides as a guide for highlighting.
+
+
+
+
+
+ Feature Branch
+ Best Common Ancestor
+ main Branch
+
+
+ r=15
+ r=15
+ r=15
+
+
+ pi = 3.1415927
+ pi = 3.14
+ pi = 3.14
+
+
+ rsq = r**2
+ rsq = r*2
+ rsq = r*2
+
+
+ a = pi*rsq
+ a = pi*rsq
+ area = pi*(rsq/2)**2
+
+
+ print a
+ print a
+ print area
+
+
+
+
+
+ Merge conflicts occur when the feature, main, and common ancestor branches are all different.
+
+
+
-
-
-
- The questions below will now ask you to identify the non-conflicting and conflicting changes that exist in the merge from .
-
-
+
+
+
+ Highlight (by clicking, or by circling) all of the lines that are conflicting changes in the feature branch and the main branch as shown in . Use the example in the slides as a guide for highlighting.
+
+
+
+
+
+ Feature Branch
+ Best Common Ancestor
+ main Branch
+
+
+ r=15
+ r=15
+ r=15
+
+
+ pi = 3.1415927
+ pi = 3.14
+ pi = 3.14
+
+
+ rsq = r**2
+ rsq = r*2
+ rsq = r*2
+
+
+ a = pi*rsq
+ a = pi*rsq
+ area = pi*(rsq/2)**2
+
+
+ print a
+ print a
+ print area
+
+
+
+
+
+ Merge conflicts occur when the feature, main, and common ancestor branches are all different.
+
+
+
-
-
-
- Highlight (by clicking) all of the lines in the main branch and the feature branch that contain non-conflicting changes.
-
-
-
-
-
-
- Feature Branch
- Best Common Ancestor
- main Branch
-
-
- r=15
- r=15
- r=15
-
-
- pi = 3.1415927
- pi = 3.14
- pi = 3.14
-
-
- rsq = r**2
- rsq = r*2
- rsq = r*2
-
-
- a = pi*rsq
- a = pi*rsq
- area = pi*(rsq/2)**2
-
-
- print a
- print a
- print area
-
-
-
-
-
- Non-conflicting changes occur when a part of the code changes in either the feature branch or the main but not both.
-
-
-
+
+
+
+ Would the feature branch in be able to be merged automatically by the project maintainers? Briefly explain your answer.
+
+
+
+
-
-
-
- Highlight (by clicking) all of the lines (if any) in the main branch and the feature branch that contain conflicting changes.
-
-
-
-
-
-
- Feature Branch
- Best Common Ancestor
- main Branch
-
-
- r=15
- r=15
- r=15
-
-
- pi = 3.1415927
- pi = 3.14
- pi = 3.14
-
-
- rsq = r**2
- rsq = r*2
- rsq = r*2
-
-
- a = pi*rsq
- a = pi*rsq
- area = pi*(rsq/2)**2
-
-
- print a
- print a
- print area
-
-
-
-
-
- Conflicting changes occur when the same part of the code is changed both the feature branch and the main branch.
-
-
-
-
+
+
+
+ Give the Merged Result to show the result of an automatic merge of the feature and main branches shown in .
+
+
+
+ r = 15
+ pi = 3.1415927
+ pi = 3.14
+ rsq = r**2
+ rsq = r*2
+ a = pi*rsq
+ area = p*rsq
+ area = pi*(rqs/2)**2
+ print a
+ print area
+ print rsq
+
+
-
-
-
- Select the statement below that best describes why the feature branch in would, or would not, be able to be merged automatically by the project maintainers.
-
-
-
-
-
-
- The feature branch can be merged automatically because there all of the changes are non-conflicting.
-
-
-
-
- Correct.
-
-
-
-
-
-
- The feature branch cannot be merged automatically because there is a conflicting change.
-
-
-
-
- Are there any conflicting changes?
-
-
-
-
-
-
- The feature branch cannot be merged automatically because there are non-conflicting changes.
-
-
-
-
- Non-conflicting changes can (usually) be merged automatically.
-
-
-
-
-
-
- It is not possible to tell if the feature branch can be merged automatically.
-
-
-
-
- If there are conflicting changes then the feature branch will not be able to be merged automatically.
-
-
-
-
-
-
- The feature branch cannot be merged automatically because there are changes both in main and in the feature branch.
-
-
-
-
- What type of changes prevent automatic merges?
-
-
-
-
-
+
+
+
+ Look carefully at your result in . Will the resulting program perform the computation correctly? Briefly explain why or why not.
+
+
+
+
-
-
-
- Imagine that the non-conflicting changes you identified in are automatically merged. Select the statement below that best describes the result.
-
-
-
-
-
-
- The merged program will not work correctly because the formula for the area will be incorrect.
-
-
-
-
- Correct.
-
-
-
-
-
-
- The merged program will work correctly because automatic merge's are guaranteed to produce a correct program.
-
-
-
-
- Look closely at the lines that define rsq and area.
-
-
-
-
-
-
- The merged program will not work correctly because an incorrect value of pi will be used.
-
-
-
-
- 3.1415927 is a valid approximation of pi.
-
-
-
-
-
-
- The merged program will work correctly because rsq is will be correctly computed as r squared instead of r*2.
-
-
-
-
- Look closely at how the area will be computed.
-
-
-
-
-
+
+
+
+ When a merge can be completed automatically, does it guarantee that the Merged Result will be correct?.
+
+
+
+
+
+
+
-
-
-
- When both the feature branch and the main branch function correctly, and the merge contains no conflicting changes then the result of an automatic merge will also be correct.
-
-
-
-
-
-
- Consider what happened with where there were no conflicting changes.
-
-
-
-
-
+
\ No newline at end of file
diff --git a/source/ch-merge-conflicts/sec-updating-your-pull-request.ptx b/source/ch-merge-conflicts/sec-updating-your-pull-request.ptx
index b33acdc..47bca8a 100644
--- a/source/ch-merge-conflicts/sec-updating-your-pull-request.ptx
+++ b/source/ch-merge-conflicts/sec-updating-your-pull-request.ptx
@@ -8,252 +8,44 @@
- At this point you have resolved the merge conflict and committed the changes to the feature branch in your local repository. What is left is to push that branch to your origin. When you do so, GitHub will automatically update your pull request to the upstream for that branch.
+ At this point you have resolved the merge conflict on the feature branch in your local repository. What is left is to push that branch to your origin. When you do so, GitHub will automatically update your pull request to the upstream for that branch.
-
-
+
- Give the command that will push your modified feature branch to your origin.
-
-
-
+ Push your modified feature branch to your origin. Give the command you used and its output here.
-
-
-
-
-
- Thank you.
-
-
-
-
-
-
- It looks like you are trying to push to the upstream. Try pushing to your origin instead.
-
-
-
-
-
-
- It looks like you are pushing the main branch. Try pushing your feature branch.
-
-
-
-
-
-
- Review the git push command in .
-
-
-
-
-
-
-
- introduced the command for pushing a feature branch to your origin.
-
-
+
-
-
+
+
+
+ Now visit the upstream repo and find your pull request. You should see that it can now be merged automatically.
+
-
+ If your PR cannot be merged automatically you have not correctly resolved the merge conflict; return to and try again.
-
-
-
-
- Use your command from to push your feature branch to your origin.
-
-
-
-
-
-
- Which of the following pieces of information appear in the terminal output from your command?
-
-
-
-
-
-
- The URL of your origin repository.
-
-
-
-
- Correct.
-
-
-
-
-
-
- The name of the feature branch that you pushed.
-
-
-
-
- Correct.
-
-
-
-
-
-
- A bunch of information about "objects".
-
-
-
-
- Correct.
-
-
-
-
-
-
- The name of the file that was changed.
-
-
-
-
- Double check the output.
-
-
-
-
-
-
- The URL of the upstream repository.
-
-
-
-
- Are you sure it's not your origin repository?
-
-
-
-
-
-
- None of these.
-
-
-
-
- Double check the command you used to push your feature branch.
-
-
-
-
-
-
- Look closely at the output from your command in the terminal.
-
-
-
+
+ !!Give a screenshot from your pull request showing that it can now be merged automatically.
+
+
+
-
-
-
+
+
- Now that you've resolved the merge conflict and pushed the result to GitHub, it should be possible for the maintainers to automatically merge your pull request. Let's check!
+ Give the URL of your pull request.
-
-
-
-
- Visit the upstream repo on GitHub, click on the "Pull requests" tab.
-
-
-
-
-
-
- Find and click on your Round2 pull request.
-
-
-
-
-
-
- Scroll down toward the bottom of the pull request.
-
-
-
-
-
-
- Which of the following messages do you see?
-
-
-
-
-
-
-
-
- GitHub message indicating that merging can be performed automatically.
-
-
-
-
-
-
- Congratulations! You successfully resolved the merge conflict! Please continue to the next exercise.
-
-
-
-
-
-
-
-
- GitHub message indicating that there are merge conflicts that must be resolved.
-
-
-
-
-
-
- Uh oh! Something didn't work. Let's try to fix it.
-
-
Run the command git revert --hard HEAD~1
-
Go back to , merge main into your feature branch and try again to resolve the conflict.
-
-
-
-
-
-
-
- I don't see either of the other messages.
-
-
-
-
- If you see a message about GitHub checking if the merge can be performed automatically, wait a few moments for one of the other messages to appear.
-
- This topic focuses on how to keep your local and origin repositories synchronized with the project's upstream repo.
+ This topic focused on how to keep your local and origin repositories synchronized with the project’s upstream repo.
In class you saw how changes contributed to the upstream via pull requests can be merged into the main branch by a project maintainer.
When your changes, and those of your classmates, were merged it left your local and origin repos out of synch with the upstream.
That is, the upstream main branch contains commits that your copies of the main branch do not.
@@ -14,8 +14,9 @@
The activities in this chapter will have you synchronize with the upstream.
Synchronizing with the upstream ensures that your local and origin copies of the main branch contain all of the same commits as the upstream main branch.
- This is something that developers do regularly to ensure that when they create a new feature branch their changes are built on the most up to date version of the project.
- Once you have synchronized your repositories you will repeat the process of upstreaming your changes by finding an issue in the issue tracker, creating a feature branch, fixing the issue and making a pull request (PR).
+ This is something that you will want to do regularly as it ensures that when you create a new feature branch your changes are built on the most up to date version of the project.
+ Once you have synchronized your repositories you will repeat the process of fixing an issue and upstreaming your changes via a pull request.
+ You will find an issue in the issue tracker, create a feature branch, fix the issue and make a pull request (PR) to the upstream for your changes.
diff --git a/source/ch-staying-synchronized/images/changes-merged-into-upstream-pull.png b/source/ch-staying-synchronized/images/changes-merged-into-upstream-pull.png
deleted file mode 100644
index 9f8573b..0000000
Binary files a/source/ch-staying-synchronized/images/changes-merged-into-upstream-pull.png and /dev/null differ
diff --git a/source/ch-staying-synchronized/sec-deleting-a-feature-branch.ptx b/source/ch-staying-synchronized/sec-deleting-a-feature-branch.ptx
index 4cfa854..9b609cb 100644
--- a/source/ch-staying-synchronized/sec-deleting-a-feature-branch.ptx
+++ b/source/ch-staying-synchronized/sec-deleting-a-feature-branch.ptx
@@ -10,433 +10,252 @@
But most developers will delete them to avoid having their repos become cluttered with old feature branches.
-
- shows the state that will result after deleting the feature branch from your local and origin repositories.
-
-
Deleting Feature Branches.
- Cloud image showing that the feature branch was deleted.
+ Cloud image of the feature branch.
- Deleting a feature branch is a two step process, first you will delete the feature branch from your local repository. Then you will push that deletion from your local branch to your origin, in order to delete it there as well.
+ shows the state that will result after deleting the feature branch from your local and origin repositories.
-
- Deleting a Feature Branch from your Local Repo
-
+
+
+
- The first step in deleting a feature branch is to delete the feature branch from your local repository.
- The exercises in this section will walk you through that process.
+ The first step is to delete the feature branch from your local repository.
+ This exercise will walk you through that process.
-
-
-
+
+
+
+ It is not possible to delete the active branch.
+ So, if you have not already, switch from your feature branch to the main branch.
+ Then give a command that lists all of the branches in your local repository.
+
+
+
+ Which command did you type to list the local branches?
+
+
-
+
+
+
- Git will not allow you to delete the active branch. So typically you will switch to the main branch before deleting a feature branch.
+ git switch
+
+
- Choose and order the commands below to switch from your feature branch to the main branch and then list all of the branches in your local repository.
- Not all commands will be used.
+ The git switch command is used to change the active branch.
+
+
+
+
+
+
+
+ git pull
-
-
-
- git switch main
-
-
-
-
- git log
-
-
-
-
- git branch
-
-
-
-
- git switch <feature branch name>
-
-
-
-
- git status
-
-
-
-
+
- You will need two commands, the first one to make the main branch active and the second to list the local branches.
+ The git pull command is used to pull changes from a remote repository to your local repository.
-
-
+
+
-
+
- Run the commands you identified in in the terminal.
+ git commit
+
+
+
+
+ The git commit command is used to commit staged changes to the repository.
+
+
+
+
+
- How can you tell from the output provided that your main branch is currently active?
+ git branch
-
-
-
-
- main an * next to it.
-
-
-
-
-
-
- main appears in green.
-
-
-
-
-
-
- main appears in bold.
-
-
-
-
-
-
- main appears in italics.
-
-
-
-
-
-
- It is not possible to tell that main is the active branch based upon the output.
-
-
-
-
-
+
- The output should clearly indicate that main is the active branch in several ways.
+ Correct! The git branch command is used to display all of branches in your local repository.
-
-
-
-
-
-
-
- The command git branch -D <branch> will delete a branch from your local repository.
-
-
-
-
-
- Give a command that will delete your feature branch.
-
-
-
-
-
-
-
-
-
-
-
- Thank you.
-
-
-
-
-
-
- Please give the full git branch command using the format indicated in the question.
- Be sure not to leave in the < and > symbols.
- Replace the word branch with your feature branch name.
-
-
-
-
-
-
-
-
-
-
- Run your command from in the terminal and examine the output.
-
-
- Which of the following looks most similar to the output you see?
-
-
-
-
-
-
- Deleted branch <branch> (was <SHA code here>)
-
-
-
-
- Correct!
-
-
-
-
-
-
- error: branch <branch> not found.
-
-
-
-
- You should not get an error. Return to and try again.
-
-
-
-
-
-
- branch deleted
-
-
-
-
- Look at your output again.
-
-
-
-
-
-
- there are no active branches
-
-
-
-
- Look at your output again.
-
-
-
-
-
-
- Look at your terminal window to see what appears in the output from the command you typed.
-
-
-
-
-
-
-
- Deleting a feature branch from your origin
+
+
+
+
+
+
+ Refer back to the section on switching branches
+
+
+
+
+
+
+
+
+ From the output provided by how do you know which is the active branch?
+
+
-
-
- In the previous exercise you deleted your feature branch from your local repository. But you have not yet deleted that feature branch from your origin repository on GitHub. The tasks in this exercise will walk you through that process.
-
-
-
-
-
-
-
-
- First, let's confirm that your feature branch still exists in your origin. How can you check if your feature branch exists in your origin repo on GitHub?
-
-
-
-
-
-
- Go to the GitHub origin repo and click on the branches button.
-
-
-
-
- Correct!
-
-
-
-
-
-
- Use the git branch command.
-
-
-
-
- This command shows the local branches.
-
-
-
-
-
-
- Use the git branch -D <branch> command.
-
-
-
-
- This command will delete a local branch
-
-
-
-
-
-
- There is no way to check for branches on GitHub.
-
-
-
-
- Take another look at the GitHub interface.
-
-
-
-
-
-
- Go to the origin repository on GitHub and look for something that you might use to see which branches exist.
-
-
-
-
-
-
-
- The Git command
- git push -d <remote> <branch>
- will delete the specified branch from the specified remote repository.
-
-
- Give a command that will delete your feature branch from your origin repository.
-
-
-
-
-
-
-
-
-
-
- Thank you.
-
-
-
-
-
-
- Please give the full git push -d command using the format indicated in the question.
- Be sure not to leave in the < and > symbols.
- Replace the word remote with origin and branch with your feature branch name.
-
-
-
-
-
-
-
-
-
+
+
- Run your command from in the Terminal and examine the output.
+ It has an * next to it.
+
+
+
+
+
- Which of the following looks most similar to the output you see?
+ It appears in green.
-
-
-
-
- [deleted] <branch>
-
-
-
-
- Correct!
-
-
-
-
-
-
- error: unable to delete '<branch>': remote ref does not exist
-
-
-
-
- Make sure you entered your feature branch name correctly.
-
-
-
-
-
-
- delete completed
-
-
-
-
- Look again at the output provided in the terminal window.
-
-
-
-
-
-
- origin updated
-
-
-
-
- Look again at the output provided in the terminal window.
-
-
-
-
-
+
+
+
+
+
+ It appears in bold.
+
+
+
+
+
+
- Examine the output of your git push command.
+ It appears in italics.
-
-
+
+
-
+
- Use your browser as you did in to confirm that your feature branch is deleted from your origin repo on GitHub.
- If it has not been deleted, revisit and and try again.
+ It is not possible to tell the active branch based upon the output provided.
-
-
+
+
+
+
+
+ Refer back to the section on switching branches
+
+
+
+
+
+
+
+ The command git branch -D <branch> will delete a branch from your local repository.
+ Use the this command to delete your feature branch.
+
+
+
+
+
+
+
+
+ How can you check if your branch was deleted? Be sure to check that it was deleted.
+ If not return to and try again.
+
+
+
+
+
+
+
+
+
+ In the previous exercise you deleted your feature branch from your local repository.
+
+
+
+
+
+
+
+ This feature branch no longer exists in your origin repo on GitHub.
+
+
+
+
+ You have only deleted the feature branch in your local repository. It still exists in your origin repository on GitHub.
+
+
+
+
+
+ Make sure you look at your repository on GitHub and click the "Branches" link.
+
+
+
+
+
+
+
+
+ Explain how you know whether the feature branch exists in your origin repo on GitHub?
+
+
+
+
+
+
+
+
+
+ You can delete your feature branch from your origin repo using the git CLI.
+ The command
+
+
+
+ git push -d <remote repo name> <branch>
+
+
+
+ will delete the specified branch from the specified remote repository.
+ Use this command to delete your feature branch from your origin repo.
+
+
+
+
-
-
+
+
+
+ Use your browser as you did in to confirm that your feature branch is deleted from your origin repo on GitHub.
+ If it has not been deleted, revisit and try again.
+
- Match the tasks on the right with the appropriate Git command listed on the left.
-
-
-
-
- Refer back to the sections in this chapter to see what each command does.
-
-
-
-
-
- git remote -v
-
-
- List your remote repos
-
-
-
-
- git remote add <remote> <URL>
-
-
- Add a new remote repo
-
-
-
-
- git push <remote> <branch>
-
-
- Synch a branch of your origin repo with your local repo
-
-
-
-
- git pull <remote> <branch>
-
-
- Synch a branch of your local repo with the upstream
-
-
-
-
- git branch -D <branch>
-
-
- Delete a feature branch from your local repo
-
-
-
-
- git push -d <remote> <branch>
-
-
- Delete a feature branch from your origin
-
-
-
-
-
- Note that the tasks listed are in approximately the same order as they appear in the sections of this chapter.
-
-
-
+
+
+
+ Match the tasks on the right with the appropriate git command listed on the left.
+
+
+
+
+ git remote -vList your remote repos
+
+ git remote add <remote repo name> <remote repo URL>Add a new remote repo
+
+ git pull --ff-only <remote repo name> <branch> Synch a branch of your origin repo with your local repo
+
+ git push <remote repo name> <branch> Synch a branch of your local repo with the upstream
+
+ git branch -D <branch> Delete a feature branch from your local repo
+
+ git push -d <remote repo name> <branch> Delete a feature branch from your origin
+
+
+ Note that the tasks listed are in approximately the same order as they appear in the sections of this chapter.
+
You’ve learned a lot about Git and GitHub.
But, to become proficient with these tools takes a lot of repetition and practice.
- The exercises in this section ask you to repeat the process of finding an issue, fixing it and creating a pull request as you did in .
- This will give you more good practice. But also, the issue you will be fixing this time has been carefully planned as a setup for the next chapter too!
+ This section asks you to go through the process of finding an issue, fixing it and creating a pull request again.
+ This is good practice but what you will be asked to do has also been carefully planned to set us up for the next chapter too!
+
+
+
+ Claiming Another Issue
-
- Process of Fixing an Issue
+
- Before you get into the work of fixing a new issue, it will be helpful to review the steps that you'll need to use and they were and how they fit together.
+ The issue tracker in the upstream FarmData2 repository being used for these tasks.
-
-
-
+
+
- The steps you carried out in are listed below in a jumbled-up order, drag them to the right to arrange them the proper order.
+ Use the label dropdown in the issue tracker to filter for issues labeled with the “Round2” tag.
+ How many issues are tagged with this label?
-
-
-
- Claim an issue
-
-
-
-
- Create a new feature branch
-
-
-
-
- Switch to the feature branch
-
-
-
-
- Edit the local files
-
-
-
-
- Stage your changes
-
-
-
-
- Commit changes to the feature branch
-
-
-
-
- Push the feature branch to your origin
-
-
-
-
- Make a pull request to the upstream
-
-
-
+
+
+
+
+
+
+ 4
+
+
+
+
+
+
+
+ 6
+
+
+
+
+
+
+
+ 35
+
+
+
+
+
+
+
+ 40
+
+
+
+
+
- Think about the full process that you worked through from claiming your Round1 issue through making a pull request for your changes.
+ ADD HINT HERE
-
-
+
+
+
+
+
+
+ Clearly there are not enough “Round2” issues for everyone to have their own as was the case with the “Round1” issues.
+ So, this time there will be multiple people working on the same issue.
+
+
+
+ Pick one of the “Round2” issues to work on and make a comment on it to indicate your interest in working on it.
+ Note it is not necessary that the issue be assigned to you this time.
+ Try to spread out across the issues so that multiple people have commented that they are working on each one.
+ Give the Issue # and title that you chose.
+
+
+
+
+
-
- Claim a Round2 Issue
-
+
+ Fixing the Issue and Upstreaming Your Changes
+
+
+
+
+ Now you will go through the process of fixing the issue and making a pull request.
+ You will use the same process that you used for your “Round1” issue earlier.
+ That process had a number of steps.
+ They are listed below in a jumbled-up order, determine the proper order.
+
+
+
+
+ Create a new feature branch
+
+
+
+
+ Switch to the feature branch
+
+
+
- Now it is time to find a new issue to work on.
+ Edit the local files
-
+
+
+
+ Stage your changes
+
+
+
+
+ Commit changes to the feature branch
+
+
+
+
+ Push the feature branch to your origin
+
+
+
+
+ Make a pull request to the upstream
+
+
+
+
+
+ HINT HERE.
+
+
+
+
+
+
+
+ Use the process that you outlined in to fix your “Round2” issue and create a pull request to the upstream for your changes.
+
+
+
+ Be sure to:
+
+
+
+ Use a descriptive name for your branch.
+
+
+
+
+
+ Use a meaningful message when committing your changes to the feature branch.
+
+
+
+
+
+ Provide a useful title and description when creating your pull request.
+
+
+
+
+
+ Include a “Closes” or “Fixes” line in your pull request description so that the associated issue number will be closed automatically if your pull request is merged.
+
+
+
+
+
-
-
-
+
+
- Go to the issue tracker in the upstream FarmData2 repository that you are using for your course.
+ Which of the following Git commands did you use for the steps indicated below.
+ The command references that you created in may also come in handy here.
- Use the "Labels" dropdown in the issue tracker to filter for issues labeled with the “Round2” tag.
+ Note that the tasks listed are in approximately the same order as they appear in the sections of this chapter.
+
+
+
+
+
+
- How many issues have the Round2 tag?
+ Which of the following would be the best name for a feature branch for issue #37 that adds a link to the NSF award in the Acknowledgements section?
-
-
+
+
+
+
- 4
+ issue37
+
- Correct.
+ This branch name doesn't provide enough information.
+ What is issue 37?
@@ -120,475 +241,217 @@
- 6
+ adding-link
+
- Be sure you have selected the "Round2" label.
+ This branch name is too generic.
-
+
+
- 35
+ adding-nsf-link-acknowledgement
+
- Be sure you have selected the "Round2" label.
+ Correct! This branch name describes the work to be done in the branch.
+
- 39
+ nsf-acknowledgement
+
- Be sure you have selected the "Round2" label.
+ This branch name doesn't specify what is being done with regard to the NSF acknowledgement.
+
- Make sure you have the Round2 tag selected in the "Labels" dropdown. The "Labels" dropdown is between the "Author" and "Projects" dropdowns.
+ Refer back to the section on creating branches for information on branch names.
-
+
-
+
+
- Clearly there are not enough “Round2” issues for everyone to have their own as was the case with the “Round1” issues.
- So, this time there will be multiple people working on the same issue.
+ Which of the following would be the best commit message for the fix for issue 38 that adds a link to the GNOME Community Engagement Challenge in the acknowledgements?
+
+
+
+
+
+
+
+
+ Added the URL for GNOME to the acknowledgements section of the REAMDE file.
+
+
+
+
+
+ Correct! This commit message briefly but completing describes the change made.
+
+
+
+
+
+
+
+ Added URL.
+
+
+
+
+
+ This commit message doesn't provide enough information about the URL added.
+
+
+
+
+
+
+
+ Updated README.
+
+
+
+
+
+ This commit message doesn't provide enough information about what has been changed in the README file.
+
+
+
+
+
+
+
+ Fixed typo.
+
+
+
+
+
+ This commit message is too generic and does not describe the change for this issue.
+
+
+
+
+
+
+
+ Refer back to the section on creating branches for information on commit messages.
+
+
+
+
+
+
+
+ Give the following information about your pull request.
+ Hint: You can revisit the prior sections to refresh your memory on the terms Base Repository, Head Repository, Base Branch and Compare Branch.
+
+
+
+
+
- Pick one of the “Round2” issues to work on and make a comment on it to indicate your interest in working on it.
- Note it is not necessary that the issue be assigned to you this time.
- Try to spread out across the issues so that multiple people have commented that they are working on each one.
+ The number of your PR
+
+
+
+
+
+
+
- Give the number of the issue you chose.
+ Full URL of your PR
+
+
+
+
+
+
-
+ Base Repository URL
-
-
-
-
-
- Thank you for selecting a Round2 issue.
-
-
-
-
-
-
- Make sure that your issue is labeled as a Round2 issue.
-
-
-
-
-
-
-
-
+
+
-
- Fix the Issue
-
-
- Now that you have an issue to work on, it is time to fix it. But before you actually start fixing the issue, let's review some of the Git commands and a few other important ideas you'll need to use to carry out the steps from .
-
-
-
-
-
-
-
-
-
-
- Match the Git commands will you use for each of the tasks indicated below.
-
-
-
-
-
- git branch <branch>
-
-
- Create your feature branch
-
-
-
-
- git switch <branch>
-
-
- Switch to your feature branch
-
-
-
-
- git stage <file>
-
-
- Stage your changes for a commit.
-
-
-
-
- git commit -m "message"
-
-
- Commit your changes to the active branch.
-
-
-
-
- git push origin <branch>
-
-
- Push your feature branch to your origin.
-
-
-
-
-
- The command reference that you created in may come in handy here.
-
-
-
-
-
-
-
-
- When creating branches you should always use name that describes what is being done in the branch, without being too long. This will help you to remember the purpose of the branch, but not make it onerous to type.
-
-
- Which of the following would be the best name for a feature branch for issue #37 that adds a link to the NSF award in the Acknowledgements section?
-
-
-
-
-
-
-
- issue37
-
-
-
-
- This branch name identifies the issue but you would have to remember what that issue is to know what the branch does.
-
-
-
-
-
-
- adding-link
-
-
-
-
- This branch sort of describes what is being done, but isn't specific enough to know what the branch really does.
-
-
-
-
-
-
- link-nsf-award
-
-
-
-
- Correct. This branch name has enough context to describe what the branch does without being excessively long.
-
- This branch name is very descriptive but seems excessively long. Can you imagine typing that over and over again?
-
-
-
-
-
-
- Refer back to for information on branch names.
-
-
-
-
-
-
-
- When writing commit messages for the git commit the message should be descriptive of what the changes in the commit do.
-
-
- Which of the following would be the best commit message for the fix for issue 38 that adds a link to the GNOME Community Engagement Challenge in the acknowledgements?
-
-
-
-
-
-
- Adds the URL for GNOME to the acknowledgements section of the REAMDE.md file.
-
-
-
-
- Correct. This commit message briefly but completing describes the change made.
-
-
-
-
-
-
- Added URL.
-
-
-
-
- This commit message doesn't provide enough information about the URL added.
-
-
-
-
-
-
- Updated README.md.
-
-
-
-
- This commit message doesn't provide enough information about what has been changed in the README.md file.
-
-
-
-
-
-
- Fixed a typo.
-
-
-
-
- This commit message is too generic and does not actually describe the changes that would be committed for this issue.
-
-
-
-
-
-
- Refer back to for information on commit messages.
-
-
-
-
-
-
-
- Upstreaming the Changes
-
-
- Now that you have fixed the issue and pushed your feature branch, the last thing to do is to make a pull request.
-
-
-
-
-
+
- Make a pull request for your feature branch to the upstream repository for your course.
+ Head Repository URL
+
+
+
+
+
+
+
- Enter the full URL of your PR below.
+ Base Branch
+
+
+
+
+
+
-
+ Compare Branch
-
-
-
-
-
- Thank you for supplying your pull request URL.
-
-
-
-
-
-
- Make sure you have the complete URL of the PR starting with https and ending with the number of your pull request.
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
- Because there were a limited number of “Round2” issues, other students in your class will have worked on the same Round2 issue as you id. Thus, they will also have made pull requests that contain changes to the same line(s) in the README.md file as you did. The tasks below will ask you some questions about this situation.
+ The line number of the README.md file that you changed.
+ Hint: use the diff you saw in the prior chapter.
-
-
-
-
-
- Assume for now that the maintainers have not merged any pull requests that fix the Round2 issue that is addressed by your pull request.
-
-
- Which of the following statements best describes this situation.
-
-
-
-
-
-
- GitHub will indicate that your PR can be merged automatically because it does not contain any conflicts with the upstream main branch.
-
-
-
-
- Correct. While your PR changes the same lines of the README.md file as the other PRs, none of those PRs have been merged into the upstream main. Thus, your PR will not contain any conflicts with the upstream main branch.
-
-
-
-
-
-
- GitHub will indicate that your PR cannot be merged automatically because it contains a conflict with the upstream main branch.
-
-
-
-
- While your PR changes the same lines of the README.md file as the other PRs, none of those PRs have been merged into the upstream main. Thus, your PR will not contain any conflicts with the upstream main branch.
-
-
-
-
-
-
- If your PR was the first one submitted for your Round2 issue, GitHub will indicate that it can be merged automatically, otherwise it will indicate that it cannot because there is a conflict with the upstream main.
-
-
-
-
- The order in which the PR's are created does not matter. A conflict will only arise after the changes in one of the PRs are merged into the upstream main. Thus, because no PRs have been merged there is no conflict between your PR and the upstream main at this point.
-
-
-
-
-
-
- GitHub will indicate that your PR can be merged automatically because it does not contain conflicts with any of the other PRs that have been submitted for your Round2 issue.
-
-
-
-
- Your PR and the others for your Round2 issue change the same lines, so in some sense your PR conflicts with the other PRs. However, none of them have been merged into the upstream main yet. Thus, there is no conflict between your PR and the upstream main at this point.
-
-
-
-
-
-
- Visit your PR in the upstream repo and see what GitHub tells you about whether it can be merged or not.
-
-
-
-
-
-
-
- Now assume that the maintainers have merged one of the other pull requests (not yours) that fix your Round2 issue.
-
-
- Which of the following statements best describes this situation.
-
-
-
-
-
-
- GitHub will indicate that your PR can be merged automatically because it does not contain any conflicts with the upstream main branch.
-
-
-
-
- Your PR will have changed the same lines in README.md as the merged PR. The changes from the merged PR are now in the upstream main branch. Thus, your feature branch will now have conflicts with the upstream main branch and will not be able to be merged automatically.
-
-
-
-
-
-
- GitHub will indicate that your PR cannot be merged automatically because it contains a conflict with the upstream main branch.
-
-
-
-
- Correct. A PR for the Round2 issue you were working on has been merged into the upstream main. Your PR contained changes that changed the same lines of the README.md file as the merged PR. Thus, your PR will have conflicts with the upstream main branch and will not be able to be merged automatically.
-
-
-
-
-
-
- If your PR for your Round2 issue was submitted before the other one was merged, GitHub will indicate that your PR can be merged automatically.
-
-
-
-
- The order in which the PR's are created does not matter. GitHub reevaluates whether there is a conflict each time you visit the PR page. Thus, because the other PR was merged, and it changed the same lines in README.md as your PR, your PR will now contain a conflict with the upstream main branch.
-
-
-
-
-
-
- GitHub will indicate that your PR cannot be merged automatically because it contain conflicts with all of the other PRs that have been submitted for your Round2 issue.
-
-
-
-
- Your PR will in some sense contain conflicts with all of the other PRs for the same Round2 issue. However, only the conflict with the upstream main branch matter here. That conflict was created when the other PR for your Round2 issue was merged.
-
-
-
-
-
-
- Visit your PR in the upstream repo and see what GitHub tells you about whether it can be merged or not.
-
-
-
-
-
+
+
+
+
+
+
+
+
+ Because there were a limited number of “Round2” issues, other students will have been simultaneously making changes to fix the same lines in the same files.
+ Describe in a few sentences how this might create a problem in the future.
+
+
+
+
+
diff --git a/source/ch-staying-synchronized/sec-overview-of-synchronizing-with-the-upstream-repository.ptx b/source/ch-staying-synchronized/sec-overview-of-synchronizing-with-the-upstream-repository.ptx
index fe742bc..d796778 100644
--- a/source/ch-staying-synchronized/sec-overview-of-synchronizing-with-the-upstream-repository.ptx
+++ b/source/ch-staying-synchronized/sec-overview-of-synchronizing-with-the-upstream-repository.ptx
@@ -4,191 +4,27 @@
Overview of Synchronizing with the Upstream Repository
-
- As you saw in , as changes from pull requests (yours and others) are merged into upstream main, the main branches in your local and origin repos will get out of synch with the upstream.
-
+ As changes from pull requests (yours and others) are merged into upstream main, the main branches in your local and origin repos will get out of synch with the upstream.
Now, recall that upstream main should be the starting point for all new work.
- So, before you can work on something new, you'll need to ensure that your main branches look like the upstream main (i.e.
+ So, before you can work on something new, you’ll want to make your main branches look like the upstream main (i.e.
you will synchronize them with the upstream).
This is a two-step process.
- First, you will pull the upstream main into your local repository and then you will push it to your origin.
- shows how pulling main from the upstream and then pushing it to your origin synchronizes the main branches.
+ You will pull the upstream main into your local repository and then you will push it to your origin.
+ shows how pulling main from the upstream and then pushing it to your origin synchs the main branches.
-
Synchronizing the local and origin main branches with the upstream.
+
Synch with Upstream.
- Cloud image showing how the main branches of the local and origin repository are synchronized with the upstream.
+ Cloud image of how upstream and the local repository are out of synch.
-
-
-
-
-
-
- Answer the following questions using
-
-
-
-
-
-
- Which action will copy changes from the upstream repository to your local repository?
-
-
-
-
-
-
- Pushing to your origin.
-
-
-
-
- The push operation copies changes from your local repository to a remote repository.
-
-
-
-
-
-
- Pulling from your origin.
-
-
-
-
- The pull operation copies changes from a remote repository to your local repo. But which remote repo do you need to copy from?
-
-
-
-
-
-
- Pushing to the upstream.
-
-
-
-
- The push operation copies changes from your local repository to a remote repository. But, recall that you do not have permission to push to upstream.
-
-
-
-
-
-
- Pulling from the upstream .
-
-
-
-
- Correct. Pulling from the upstream copies the changes that have been merged into upstream into your local repository.
-
-
-
-
-
-
- Switching to your feature branch.
-
-
-
-
- Switching branches does not move information between your local repository and a remote repository.
-
-
-
-
-
-
- Look back to at the figure to see which arrow goes from the upstream to your local repository.
-
-
-
-
-
-
-
- Which action copies changes from your local repository to your origin repository?
-
-
-
-
-
-
- Pushing to your origin.
-
-
-
-
-
- Correct. Pushing to your origin will copy changes from your local repository to your origin repository.
-
-
-
-
-
-
- Pulling from your origin.
-
-
-
-
- Pulling copies changes from a remote repository into your local repository.
-
-
-
-
-
-
- Pushing to the upstream.
-
-
-
-
- Pushing copies changes from your local repository to a remote repository. But recall that you do not have permission to push to upstream main.
-
-
-
-
-
-
- Pulling from the upstream.
-
-
-
-
- Correct. Pulling from the upstream copies changes that have been merged into the upstream to your local repository.
-
-
-
-
-
-
- Switching to your feature branch.
-
-
-
-
-
- Switching branches does not move information between your local repository and a remote repository.
-
-
-
-
-
-
- Look back to at the figure to see which arrow goes from your local repository to the origin.
-
- The next step in getting synchronized with the upstream is to pull the changes to the main branch from the upstream repo to your local repo.
-
-
-
- illustrates the state after several commits have been merged into upstream main and those changes have been pulled into the main branch in the local repo.
-
-
-
-
-
Pulling changes from upstream main branch into the local main branch.
-
-
- Cloud image illustrating changes being pulled into the local main branch from the upstream main branch.
-
-
-
-
-
-
- This section walks you through the process of pulling changes from the upstream main branch into your local main branch.
-
-
-
-
-
-
- To pull the changes from the upstream main branch into your local repo you first need to ensure that main is the active branch in your local repo.
-
-
-
-
-
- Which command can you use to check if main is the active branch?
-
-
-
-
-
-
- git log
-
-
-
-
- The git log command gives information about the commits that have been made to the active branch.
-
-
-
-
-
-
- git branch main
-
-
-
-
- The git branch main command will try to create a new branch with the name main.
-
-
-
-
-
-
- git status
-
-
-
-
- Correct! The git status command can be used to check which branch is active.
-
-
-
-
-
-
- git switch main
-
-
-
-
- The git switch main command will make main main the active branch, not check which branch is active.
-
-
-
-
-
-
- Refer to .
-
-
-
-
-
-
-
- If your active branch is not main which command could you use to make main the active branch?
-
-
-
-
-
-
- git log
-
-
-
-
-
- The git log command gives information about the commits that have been made to the active branch.
-
-
-
-
-
-
- git branch main
-
-
-
-
- The git branch main command will try to create a new branch with the name main.
-
-
-
-
-
-
- git status
-
-
-
-
- The git status command will give you information about the active branch, it does not switch branches.
-
-
-
-
-
-
- git switch main
-
-
-
-
- Correct! The git switch main command will make main the active branch.
-
-
-
-
-
-
- Refer back to the section in the previous chapter on switching branches
-
-
-
-
-
-
-
- Use the commands you have identified in the previous tasks to ensure that main is the active branch. Do not go on until your main branch is the active branch.
-
-
-
-
-
-
-
-
+
+
+
+ The next step is to pull the changes to the main branch from the upstream repo to your local repo.
+ This section walks you through that process.
+
+
+
+
- The command
- git pull <remote> <branch>
- will pull any new commits from the specified branch in the remote repo and add them onto the end of the active branch of your local repo.
- <branch> can be a name like origin.
+ To pull the changes from the upstream main branch into your local repo you first need to ensure that main is the active branch in your local repo.
+ Check the active branch in your local repo.
+ What command did you use?
+
+
+
+
+
+
+
+ git log
+
+
+
+
+
+ The git log command tells you the commits made to the active branch.
+
+
+
+
+
+
+
+ git branch main
+
+
+
+
+
+ The git branch main command will create a new branch with the name main.
+
+
+
+
+
+
+
+ git status
+
+
+
+
+
+ Correct! The git status command tells you active branch.
+
+
+
+
+
+
+
+ git switch main
+
+
+
+
+
+ The git switch main command will change the active branch to main, not check what is the active branch.
+
+
+
+
+
+
- Give a git pull command that will pull new commits from the main branch of the upstream repo and add them to your main branch.
+ Refer back to the section in the previous chapter on switching branches
+
+
+
+
+
+
-
+ If your active branch in not the main branch change the active branch now.
+ What command changes the active branch to main?
-
-
-
-
-
- Correct.
-
-
-
-
-
-
- Please give the full git pull command using the format indicated in the question.
- Be sure not to leave in the < and > symbols.
- Replace the words remote and branch with the appropriate names.
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+ git log
+
+
+
+
+
+ The git log command tells you the commits made to the active branch.
+
+
+
+
+
+
+
+ git branch main
+
+
+
+
+
+ The git branch main command will create a new branch with the name main.
+
+
+
+
+
+
+
+ git status
+
+
+
+
+
+ The git status command tells you active branch, it does not switch branches.
+
+
+
+
+
+
+
+ git switch main
+
+
+
+
+
+ Correct! The git switch main command will change the active branch to main.
+
+
+
+
+
+
+
+ Refer back to the section in the previous chapter on switching branches
+
+
+
+
+
+
- Run the command from in the terminal and examine the output.
+ The command
+
- It should not contain any error messages.
- If it does, look at the format of the command from and try again.
+ git pull --ff-only <remote repo name> <branch>
+
+
+
+ will pull any new commits from the specified branch in the remote repo and add them onto the end of the active branch of your local repo.
+ Use the git pull command above to pull and add the commits from the main branch of the upstream repo to your main branch.
+
+
+
+
+
+
- Which of the following appear in the output of the git pull command?
+ Examine the output from .
+ It should not contain any error messages.
+ If it does, return to and try again.
+ Which of the following is shown in the output of the git pull command?
+
+
@@ -232,6 +200,7 @@
+
@@ -239,6 +208,7 @@
+
@@ -246,6 +216,7 @@
+
@@ -253,6 +224,7 @@
+
@@ -261,11 +233,13 @@
+
Make sure you look at all of the lines of output and the color coding of the lines.
-
+
+
diff --git a/source/ch-staying-synchronized/sec-pushing-main-to-your-origin.ptx b/source/ch-staying-synchronized/sec-pushing-main-to-your-origin.ptx
index 5a6109f..ce8885f 100644
--- a/source/ch-staying-synchronized/sec-pushing-main-to-your-origin.ptx
+++ b/source/ch-staying-synchronized/sec-pushing-main-to-your-origin.ptx
@@ -4,120 +4,106 @@
Pushing <c>main</c> to Your Origin
-
+
+
- Your local main branch is now in synch with the upstream main branch. However, the updates that you pulled into your local main branch are not yet in your origin repository. The exercises in this section will guide you the process of getting them there.
+ Your local main branch is now in synch with the upstream main branch.
+ What’s left is to also synch the main branch in your origin repo.
-
+
+
Recall that you previously used the
- git push <remote> <branch>
- command to push your feature branch from your local repo to your origin repo.
+
- Give a git push command that will push the main branch of your local repo to your remote origin repo.
+ git push <remote repo name> <branch>
+
-
+ command to push your feature branch from your local repo to your origin repo.
+ Use the git push command to push the main branch of your local repo to your remote origin repo.
-
-
-
- Thank you.
-
-
-
+
-
-
- Please give the full git push command using the format indicated in the question.
- Be sure not to leave in the < and > symbols.
- Replace the words remote and branch with the appropriate names.
-
-
-
-
-
-
+
+
- Run the git push command you wrote in in the Terminal and examine the output.
+ Examine the output from .
+ You should see a lot of information about deltas and objects.
+ Those are terms related to the inner workings of git that we will not worry about.
+ If you don’t see this information about deltas and objects but see an error message instead, revisit and try again.
-
-
-
- Examine the output from your git push command.
- You should see a lot of information about deltas and objects. Those are terms related to the inner workings of Git that we will not worry about.
+ The last two lines of the output in part a should contain some recognizable information.
+ What do you think that these lines are telling you?
+
+
+
+
+
+
+
+ The URL of your origin on GitHub.
+
+
+
+
+
+
+
+ The name of the branch pushed to GitHub.
+
+
+
+
+
+
+
+ The URL of the upstream repository on GitHub.
+
+
+
+
+
+
+
+ A list of all the files changed in the local repository.
+
+
+
+
+
+
+
+ A list of all the branches in the local repository.
+
+
+
+
+
+
- If you don't see information about deltas and objects but see an error message instead, revisit and try again.
+ Only look at the last two lines, the one that starts with "To" and the one that starts with a SHA code.
-
-
-
-
-
-
- The last two lines of the output should contain some recognizable information. What do you think that these lines are telling you?
-
-
-
-
-
-
- The URL of your origin on GitHub.
-
-
-
-
-
-
- The name of the branch that you pushed to GitHub.
-
-
-
-
-
-
- The URL of the upstream repository on GitHub.
-
-
-
-
-
-
- A list of all the files changed in the local repository.
-
-
-
-
-
-
- A list of all the branches in the local repository.
-
-
-
-
-
-
- Only look at the last two lines, the one that starts with "To" and the one that starts with a SHA code.
-
-
-
-
-
-
-
- As with most things related to Git and GitHub, there are a number of different ways to synchronize.
- For example, you can also fetch the changes from the upstream main to your origin and then pull them from there to your local repository.
- If you are curious, you can check out this GitHub link: Syncing a fork
-
+
+
+
+
+
+ As with most things related to Git and GitHub, there are a number of different ways to synchronize.
+ For example, you can also fetch the changes from the upstream main to your origin and then pull them from there to your local repository.
+ If you are curious, you can check out this GitHub link: Syncing a fork
+
If the upstream maintainers decide that the changes in your PR (pull request) are good for the project, they will merge them into the upstream main branch.
That way they become a part of the main project, and everyone can benefit from your work.
- In class your instructor played the role of a maintainer and demonstrated how the changes contained in pull requests are merged into the upstream. shows the upstream with several new changes merged into it's main branch.
+ In class your instructor played the role of an upstream maintainer and demonstrated how the changes contained in pull requests are merged.
-
-
- illustrates the state after several commits have been merged into upstream main.
-
+
+
+ illustrates the state after several commits have been merged into upstream main.
+
+
+
+
+
Changes Merged into Upstream.
+
+
+ Cloud image of the changes merged into upstream.
+
+
+
+
+
+
+
+
+ Answer the following questions using
+
+
+
+
+
+
+
+ Which commits (give the colors) were merged into the upstream main since the contributor created the feature branch that is shown?
+
+
+
+
+
+
+
+
+ Red
+
+
+
+
+
+
+
+ Yellow
+
+
+
+
+
+
+
+ Green
+
+
+
+
+
+
+
+ Blue
+
+
+
+
+
+
+
+ Pink
+
+
+
+
+
+
+
+ Lime Green
+
+
+
+
+
+
+
+ Look at which commits are new in upstream that are not part of the local repository's main or feature branch.
+
+
+
-
-
-
Changes Merged into Upstream.
-
-
- Cloud image showing some changes merged into the upstream main branch.
-
-
-
-
-
-
+
+
+
+ Which of the commits did the managers merge from the contributor's pull request?
+
+
+
+
+
+
+
+
+ Red
+
+
+
+
+
+ Red was in main prior to the contributor creating the feature branch.
+
+
+
+
+
+
+
+ Yellow
+
+
+
+
+
+ Yellow was in main prior to the contributor creating the feature branch.
+
+
+
+
+
+
+
+ Green
+
+
+
+
+
+ Green was in main prior to the contributor creating the feature branch.
+
+
+
+
+
+
+
+ Blue
+
+
+
+
+
+ Blue was part of the contributor's feature branch.
+
+
+
+
+
+
+
+ Pink
+
+
+
+
+
+ Pink was part of another contributor's pull request.
+
+
+
+
+
+
+
+ Lime Green
+
+
+
+
+
+ Lime green was part of another contributor's pull request.
+
+
+
+
+
+
+
+ Look at which commits are in the local repository's feature branch.
+
+
+
+
+
+
+
+
+ Briefly explain how the pink commit could have gotten into the upstream main.
+
+
+
+
+
+
+
+
+ GitHub will inform you when the active branch in your origin repo is out of synch with the upstream.
+
+
+
+
+
- Answer the following questions using
+ Use your browser to visit your origin repo on GitHub and ensure that the main branch is selected.
+ Find the part of the page that indicates that your main branch is behind (i.e.
+ not the same as, or out of synch with) the upstream main.
-
-
-
-
-
- Which commits (give the colors) were merged into the upstream main after the contributor created their local feature branch?
-
-
-
-
-
-
- Red
-
-
-
-
-
-
- Yellow
-
-
-
-
-
-
- Green
-
-
-
-
-
-
- Blue
-
-
-
-
-
-
- Pink
-
-
-
-
-
-
- Lime Green
-
-
-
-
-
-
-
- Look at which commits are in the upstream main branch that are not part of the local repository's main branch.
-
-
-
-
-
-
-
- Which of the commits did the managers merge from the contributor's pull request?
-
-
-
-
-
-
- Red
-
-
-
-
- Red was in main prior to the contributor creating the feature branch.
-
-
-
-
-
-
- Yellow
-
-
-
-
- Yellow was in main prior to the contributor creating the feature branch.
-
-
-
-
-
-
- Green
-
-
-
-
- Green was in main prior to the contributor creating the feature branch.
-
-
-
-
-
-
- Blue
-
-
-
-
- Correct. Blue was part of the contributor's feature branch.
-
-
-
-
-
-
- Pink
-
-
-
-
- Pink was part of another contributor's pull request.
-
-
-
-
-
-
- Lime Green
-
-
-
-
- Lime green was part of another contributor's pull request.
-
-
-
-
-
-
- Look at which commits are in the local repository's feature branch.
-
-
-
-
-
-
-
-
- Which of the following statements explains how the pink commit might have gotten into the upstream main branch?
-
-
-
-
-
-
-
- The contributor made the pink commit to their feature branch.
-
-
-
-
- The contributor's feature branch did not contain the pink commit.
-
-
-
-
-
-
- A maintainer merged the contributor's pull request.
-
-
-
-
- The contributor's pull request contained the blue commit, not the pink commit.
-
-
-
-
-
-
-
- A maintainer merged a pull request from another contributor which contained the pink commit.
-
-
-
-
- Correct. The pink commit was part of a feature branch that another contributor submitted via a pull request.
-
-
-
-
-
-
- The pink commit is not part of the upstream main.
-
-
-
-
- The pink commit is part of the upstream main.
- It was merged after the pull request that contained the blue commit.
-
-
-
-
-
-
-
- Look at which commits are in the local repository's feature branch.
- This shows the changes made by this contributor.
- Other changes were made by other contributors and accepted by the maintainer as a pull request.
-
-
-
-
-
-
-
+
+
+
+
+ If you do not see a message that your main branch is behind the upstream main branch go to of this chapter and follow the instructions there.
+ Once you complete , return to .
+
+
+
+
+
- At this point the upstream main branch should have changes that are not contained in your origin and local main branches. That is, you are out of synch with the upstream.
-
- When your origin repository is out of synch with the upstream, GitHub will display a message that informs you. Let's investigate this message.
+ Briefly explain what has happened that caused your origin’s main branch to get behind the upstream main.
-
-
-
-
-
-
- Use your browser to visit your origin repo on GitHub and ensure that the main branch is selected.
-
-
- Which of the following messages do you see that indicates that your origin's main branch is behind the upstream main?
-
-
-
-
-
-
- This branch is x commits behind main.
-
-
-
-
- Correct! Being behind means that the upstream main branch contains changes that your origin main branch does not.
-
-
-
-
-
-
- This branch is x commits ahead of main.
-
-
-
-
- Being ahead means that your origin main branch contains changes that are not in the upstream main branch. However, right now your origin main should be behind the upstream main branch.
-
-
- You will need to fix this before continuing. Go to of this chapter and follow the instructions there. Once you complete , return to this exercise.
-
-
-
-
-
-
- I do not see either of those messages.
-
-
-
-
- Seeing no message indicates that origin main branch is up to date with (i.e. identical to) the upstream main branch.
- However, Right now your origin main should be behind the upstream main branch.
-
-
- You will need to fix this before continuing. Go to of this chapter and follow the instructions there. Once you complete , return to this exercise.
-
-
-
-
-
-
- You can find the relevant message in a box just below the branch name drop down near the top left of your origin's GitHub page.
-
-
-
-
-
-
-
- Which of the following statements describes what could have happened to cause your origin's main branch to get behind the upstream main?
-
-
-
-
-
-
- Another contributor has made a pull request to the upstream for changes that they have made.
-
-
-
-
-
- In order for this to affect the upstream main a maintainer would have to have merged their pull request.
-
-
-
-
-
-
- You have made a pull request to the upstream for a feature branch on which you have been working.
-
-
-
-
- In order for this to affect the upstream main a maintainer would have to have merged your pull request.
-
-
-
-
-
-
-
- You have committed changes to your local main branch and pushed it to your origin.
-
-
-
-
- Here your origin main branch would contain changes that are not in the upstream main branch, so your branch would be ahead, not behind.
-
-
-
-
-
-
- A maintainer merged a pull request and you have not yet updated your origin's main branch to include these changes.
-
-
-
-
- Correct. The manager merging the pull request will add changes to the upstream main branch that are not in your main branches.
-
-
-
-
-
-
- Think about how changes may been added to the upstream main after you made your feature branch, and while you were working.
-
-
-
-
+
+
+
+
diff --git a/source/ch-staying-synchronized/sec-verifying-the-upstream-remote.ptx b/source/ch-staying-synchronized/sec-verifying-the-upstream-remote.ptx
index 8a280da..3f75901 100644
--- a/source/ch-staying-synchronized/sec-verifying-the-upstream-remote.ptx
+++ b/source/ch-staying-synchronized/sec-verifying-the-upstream-remote.ptx
@@ -1,392 +1,285 @@
- Setting the Upstream Remote
+ Creating and Verifying the Upstream Remote
+ Verifying the Upstream Remote
+
+ In order to pull changes from the upstream you will need to tell your local repository where the upstream is.
+ In earlier figures, dotted orange lines were used to indicate that your local repository knew about the origin and that the origin knew about the upstream.
+ But there was no orange dotted line from your local repository to the upstream.
+ That is because, by default, your local repository isn’t aware of the upstream.
+
-
-
- Before you will be able to pull changes from the upstream you will need to tell your local repository where the upstream is.
- In earlier figures (e.g. ), there were dotted orange lines indicating that your local repository knew about your origin and that your origin knew about the upstream.
- However, there was no orange dotted line from your local repository to the upstream. That is because, by default, your local repository isn’t aware of the upstream.
-
-
- In a dotted orange line was added pointing from your local repository to the upstream. Git will need this information so that it can pull changes from the upstream into your local repository. In this section, you will be adding this information by setting the upstream remote.
-
+
+ When you open a fork in GitPod, GitPod clones its repository.
+ This creates a remote named origin that points to the repository it cloned.
+ When you clone a repository, this is typically the only remote created automatically.
+ But GitPod goes a step further.
+ It also creates upstream remote that points to the repository that your origin forked from.
+
+ Like the last activity, you will be working within the KitClient for this activity.
+
+
+
+
+
+
+ Restart your KitClient based on the instructions in
+
+
-
- Restarting the Development Environment
+
+
+ To synchronize your fork, you will need to use this upstream remote.
+ First, let's confirm that GitPod correctly created the upstream remote.
+ This exercise will walk you through that process.
+
-
-
- Like prior chapters, you will be working within your development environment for this activity.
-
+
+ In order to pull from the upstream you will first need to make your local repository aware of the upstream.
+ This is done by setting a remote for it.
+ This exercise will walk you through that process.
-
-
-
+
+
+
- Click here to open your development environment.
- Please be patient as this can take a few minutes.
- When the development environment is ready you will see the message "Kit development environment is ready for use." and your browser window will look similar to the following:
-
-
-
- The GitKit Development Environment.
- The development environment is ready when you see the "Kit development environment is ready for use" message.
-
-
+ The git remote -v command lists the names and URLs of all of the remote repositories (or just remotes for short) that your local repo knows about.
+ Run this command in the directory that contains your local repository.
-
-
-
+
+
-
- Understanding Remotes
+
+
+
+ How is the origin remote indicated in represented in ?
+
+
-
-
- A remote is a repository that is stored on GitHub, or another repository hosting sited.
-
-
- A Git remote is the URL of a remote and an associated name (e.g. origin, upstream). Git uses Git remotes to locate remote repositories. Though it can be confusing, the remote is also commonly used as a synonym for Git remote.
-
-
-
-
-
-
-
-
- The git remote -v command lists the name and URL for all of the Git remotes associated with your local repository.
-
-
- Be sure that you are in the directory containing your local repository and run the git remote -v command.
-
-
-
-
-
-
-
- Examine the output of the git remote -v command from . You should see two lines labeled origin (fetch and pull), that both show the same URL.
-
-
-
-
+
+
- Where does the URL for the origin remote point?
+ It is labeled as "origin".
-
-
-
-
- It points to the GitKit FarmData2 repository that your instructor created for the course.
-
-
-
-
- The repository that your instructor create is serving as the upstream repository.
-
-
-
-
-
-
- It points to your copy of the GitKit FarmData2 repository that you forked from the upstream.
-
-
-
-
- Correct! The origin is your fork that is contained in your GitHub space.
-
-
-
-
-
-
- It points to the repository for the live FarmData2 project.
-
-
-
-
- That repository would be the upstream if you were working on the live project.
-
-
-
-
-
+
+
- Look at the part of the origin remote's URL that comes after `github.com`. This part indicates where on GitHub the repository is located. Is it in your GitHub space?
+ Correct! The diagram shows your origin remote on the top left side with the label "origin".
-
-
+
+
-
+
- What in represents the origin Git remote that is associated with your local repository?
+ It is labeled as "upstream".
-
-
-
-
- The dotted orange arrow on the left that points from your local repository to the origin.
-
-
-
-
- Correct.
-
-
-
-
-
-
- The dotted orange arrow at the top that points from your origin repository to the upstream.
-
-
-
-
- The arrow at the top represents a Git remote associated with your origin repository, not your local repository.
-
-
-
-
-
-
- The blue cylinder at the top left of the figure.
-
-
-
-
- The blue cylinders represent remote repositories. This question is asking about the Git remote.
-
-
-
-
-
+
+
+
+
- Look at the diagram again. The origin Git remote will be associated with your local repo and will indicate where the origin repository is located.
+ It is labeled as "local".
-
-
-
-
-
-
-
- Adding the Upstream Remote
-
-
-
- Notice that the output from the git remote -v command did not include the location of the upstream repository. Thus, before you will be able to pull changes from the upstream into your local repository you will need to set the upstream remote. This will tell Git where the upstream repository is located.
-
-
- The exercises in this section will walk you through the process of setting the upstream remote.
-
-
+
+
-
-
-
-
-
- Use your browser to navigate to the GitHub page for the upstream Gitkit FarmData2 repo that you are using for this course. Hint: You can find the GitHub page for the upstream using the "forked from:" link at the top of the GitHub page for your origin repository.
-
+
+
+
+ It is labeled as "feature branch".
+
+
+
+
+
+
- Once you find the GitHub page for the upstream, you can get its URL by clicking the “Code” button and using the "Local" tab. This URL will end in .git.
+ When you issued the git remote -v command pay attention to the name given to the fetch and pull URLs.
+
+
+
+
+
+
- Enter the URL of the upstream GitKit FarmData2 you are using for your course below.
+ Confirm that upstream points to the upstream project on GitHub.
+ How did you confirm it?
+
+
+
+
+
+
+
-
+ To create a new remote that tells your local repo about the upstream you will need the URL of the upstream repo.
+ Use your browser to navigate to the upstream FarmData2 repo that you are using for this course and give its URL here.
+ Hint: You can find the upstream using the link from your origin repo in GitHub.
+ Once you find the upstream, you can get the URL by using the “Code” button in the upstream repo, it ends in .git.
-
-
-
-
-
- Looks good! But just to be sure, double check that this URL agrees with the one you gave in .
-
-
-
-
-
-
- Be sure you are copying the URL of the upstream for your class as given by your instructor.
-
-
-
-
-
-
-
-
+
+
+
+
+
- The git remote command you used to display the Git remotes is also used to add a new Git remote.
+ The git remote command can also be used to add a new remote to your local repo.
+ The format for this command is:
+
- The format for this command is: git remote add <name> <URL>
+ git remote add <remote repo name> <remote repo URL>
+
- Give a command that will create a new Git remote named upstream that points to the GitKit FarmData2 upstream repository that you are using for this course.
+ Use the above command to create a remote named upstream that points to the FarmData2 upstream repository that you are using for this exercise.
+
+
+
+
+
+
-
+ Use the git remote -v command to confirm that the new upstream remote has been added.
-
-
-
-
-
- Looks good! But just to be sure, double check that the URL you used agrees with the one you gave in .
-
-
-
-
-
-
- Double check the format of your command and the URL that you are using.
-
-
-
-
-
-
-
-
+
+
+
+
- Use the git remote -v command.
- What do you see that confirms that you have successfully added the upstream Git remote?
+ The upstream remote provides your local repo with the information it needs to find the upstream repo.
+ In git this information is represented using a URL.
+ How is this information represented in ?
-
-
-
-
- Two lines beginning with origin and giving the URL of the upstream repository.
-
-
-
-
- The lines beginning with origin are the origin remote and give the URL of your origin repository.
-
-
-
-
-
-
- Two lines beginning with upstream and giving the URL of the upstream repository.
-
-
-
-
- Correct! The URL of the upstream is where you will be pulling changes from.
-
-
-
-
-
- Neither of the above.
-
-
-
- One of the above answers is correct.
-
-
-
-
-
-
- Think about the different between origin vs.
- upstream.
-
-
-
-
-
-
-
-
- You just added the upstream Git remote to your local repository. How is this Git remote represented in ?
-
-
-
-
-
-
- The dotted orange arrow on the right that points from your local repository to the upstream.
-
-
-
-
- Correct.
-
-
-
-
-
-
- The dotted orange arrow on the left that points from your local repository to the origin.
-
-
-
-
- The arrow on the left represents the origin Git remote.
-
-
-
-
-
-
- The dotted orange arrow at the top that points from your origin repository to the upstream.
-
-
-
-
- The arrow at the top represents a Git remote associated with your origin repository, not your local repository.
-
-
-
-
-
-
- The blue cylinder at the top right of the figure.
-
-
-
-
- The blue cylinders represent remote repositories. This question is asking about the Git remote.
-
-
-
-
-
-
- Look at the diagram again. The upstream Git remote will be associated with your local repo and will indicate where the upstream repository is located.
-
-
-
-
-
- Note that you will only need to set the upstream remote once for a repository.
- Once the upstream remote is set you will be able to pull from the upstream repo as often as is necessary.
-
-
+
+
+
+
+ It is labeled as "origin".
+
+
+
+
+
+
+
+ It is labeled as "upstream".
+
+
+
+
+
+ Correct! The diagram shows your upstream remote on the top right side with the label "upstream".
+
+
+
+
+
+
+
+ It is labeled as "local".
+
+
+
+
+
+
+
+ It is labeled as "feature branch".
+
+
+
+
+
+
+
+ When you issued the git remote -v command pay attention to the name given to second set of fetch and pull URLs.
+
+
+
+
+
+
+
+
+ The upstream remote provides your local repo with the information it needs to find the upstream repo.
+ In git this information is represented using a URL.
+ How is this information represented in ?
+
+
+
+
+
+
+
+
+ It is labeled as "origin".
+
+
+
+
+
+
+
+ It is labeled as "upstream".
+
+
+
+
+
+ Correct! The diagram shows your upstream remote on the top right side with the label "upstream".
+
+
+
+
+
+
+
+ It is labeled as "local".
+
+
+
+
+
+
+
+ It is labeled as "feature branch".
+
+
+
+
+
+
+
+ When you issued the git remote -v command pay attention to the name given to second set of fetch and pull URLs.
+
+
+
+
+
+ Note that you will only need to set the upstream remote once for a repository.
+ Once the upstream remote is set you will be able to pull from the upstream repo as often as is necessary.
+
+
diff --git a/source/ch-upstreaming-changes/sec-committing-to-your-local-repository.ptx b/source/ch-upstreaming-changes/sec-committing-to-your-local-repository.ptx
index 464b3fd..6c60936 100644
--- a/source/ch-upstreaming-changes/sec-committing-to-your-local-repository.ptx
+++ b/source/ch-upstreaming-changes/sec-committing-to-your-local-repository.ptx
@@ -59,13 +59,6 @@
Fix typo
-
-
-
- Commit messages should be as specific as possible regarding the changes made.
- Something like "fix typo" is too generic as it can apply to lots of different changes.
-
-
@@ -90,180 +83,33 @@
Extend harvest logs
-
-
-
- Commit messages should be as specific as possible regarding the changes made.
- Which of the messages provides information about what is added and where?
-
-
-
+
The git commit -m "<message>" command commits all of the staged files to the currently active branch with the specified commit message.
+ Use the git commit command to commit your staged changes to your local repository with a meaningful commit message.
+
-
- Write a git commit command for the change you made in the space below.
- Be sure to include a meaningful message.
-
-
-
-
-
-
-
-
-
-
-
- Thank you.
- Your command is in the proper format, please make sure the commit message is meaningful.
-
-
-
-
-
-
-
- Double check the format of your command.
-
-
-
-
-
-
-
-
-
- Use the git commit command you wrote in to commit your staged changes to your local repository with a meaningful commit message.
-
+
+
+
+ Provide the command you entered.
+
+
+
+
-
- Look at the output produced.
-
-
-
-
-
-
-
-
- It shows the name of the file changed in the square brackets [ ].
-
-
-
-
-
- The first part of the first line is not the file name, take another look at the output.
-
-
-
-
-
-
-
- It shows the name of the feature branch that contains the change in the square brackets [ ].
-
-
-
-
-
- The first part of the first line is the feature branch name.
-
-
-
-
-
-
-
- It shows the SHA code of the commit in the square brackets [ ].
-
-
-
-
-
- The second part of the first line is the SHA code of the commit.
-
-
-
-
-
-
-
- It shows the commit message.
-
-
-
-
-
- The last part of the first line is the commit message.
-
-
-
-
-
-
-
- It shows the number of files changed.
-
-
-
-
-
- The first part of the second line is the number of files changed.
-
-
-
-
-
-
-
- It shows the number of lines inserted.
-
-
-
-
-
- The second part of the second line is the number of lines inserted.
-
-
-
-
-
-
-
- It shows every line that was inserted and/or deleted.
-
-
-
-
-
- The output should not show the individual line changes, rather a summary of the changes.
-
-
-
-
-
-
-
- There should be two lines of output.
- The first will provide 3 different pieces of information.
- The second provides what additional information?
-
-
-
-
Now use the git status command again.
- Compare your output to the output in .
+ Compare your output to the output in .
What two changes have occurred that reflect that your changes have been staged?
@@ -302,59 +148,16 @@
-
-
- You have staged and committed all modified files.
-
-
+
How do you know your changes have been committed?
-
-
-
-
-
- The git commit message showed a new SHA.
-
-
-
-
-
-
-
- The git status command does not show the files you modified for your change.
-
-
-
-
-
-
-
- The git status command shows your modified files in green.
-
-
-
-
-
-
-
- The git commit message says "no changes added to commit".
-
-
-
-
-
-
-
- There should be no modified files that are still staged and the git commit should have showed you the number of lines changed.
-
-
+
@@ -362,49 +165,12 @@
Use the git log command to show the 3 most recent commits to your branch.
- Refer back to your output from .
+ How is this output different from what you observed in Question #1? Briefly explain why? Note: Question #1 is now a multiple choice question.
+ Maybe there should be multiple choice questions here that are similar (showing that the new commit appears in the log).
+ I'm not sure I understand this - Question #1 is a parson's question.
-
-
-
-
-
-
- The top commit shown is your latest commit.
-
-
-
-
-
-
-
-
- The bottom commit shown is your latest commit.
-
-
-
-
-
-
-
- Your commit is not shown.
-
-
-
-
-
- Feedback 3
-
-
-
-
-
-
-
- The log shows the latest commits first.
-
-
+
@@ -424,12 +190,6 @@
git status
-
-
-
- git status shows what files have been changed and staged.
-
-
@@ -438,12 +198,6 @@
git stage main
-
-
-
- git stage main is not a proper command.
-
-
@@ -452,12 +206,6 @@
git branch main
-
-
-
- git branch main would try to create a new branch named main.
-
-
@@ -466,110 +214,27 @@
git switch main
-
-
-
- Correct!
-
-
-
-
-
- To change the active branch you need to switch to it.
-
-
-
+
The output of the git log command now shows the information about the commit you made.
-
-
-
- What branch are you on, the main branch or your feature branch? In which branch did you make your changes?
-
-
- The commit is not shown in the git log output because:
+ Briefly explain how you know.
-
-
-
-
-
-
- You are on the main branch and the commit is on the feature branch.
-
-
-
-
-
- Correct!
-
-
-
-
-
-
-
- You are on the feature branch and the commit is on the main branch.
-
-
-
-
-
- You should be on the main branch.
-
-
-
-
-
-
-
- The git status command should be used to show the commits.
-
-
-
-
-
- The git status command is used to see what files have been changed and staged.
-
-
-
-
-
-
-
- It only shows the first commit made, not every commit.
-
-
-
-
-
- The git log command will show multiple commits with the most recent appearing first.
-
-
-
-
-
-
-
- Commits are specific to branches.
- You must be on the proper branch to see a commit.
-
-
+
diff --git a/source/ch-upstreaming-changes/sec-creating-a-feature-branch.ptx b/source/ch-upstreaming-changes/sec-creating-a-feature-branch.ptx
index 28fac78..f616fb0 100644
--- a/source/ch-upstreaming-changes/sec-creating-a-feature-branch.ptx
+++ b/source/ch-upstreaming-changes/sec-creating-a-feature-branch.ptx
@@ -8,41 +8,23 @@
When you set out to make changes to the project you will do so by working on a feature branch.
The exercises in this section will walk you through the process of creating a feature branch on which you will fix the issue that you claimed in .
-
-
- illustrates this process. The feature branch that you will create is shown in orange.
-
-
-
-
-
Create Feature Branch.
-
-
- Cloud image of origin, upstream, and local branches.
-
-
-
-
-
+
- The git branch <name> command creates a new branch with the given name.
- When creating a branch, you should give it a short but descriptive name (e.g.
- FixTypoInReadme).
- Note: name may not have spaces, so you can use - (dashes) or CammelCaseText to divide words in your branch names.
- Remember not to include the < > when writing your own command.
+ The git status command provides the current status of your local repository.
+ Use the git status command to see the current status of your local GitKit-FarmData2 repository.
-
+
- If you want to create a new feature branch named fixTypoInName, which command should you use?
+ What part of the output tells you which branch is currently active in your repository?
@@ -51,13 +33,13 @@
- git branch fixTypoInName
+ The branch name is displayed in the first line after "On branch".
- Correct!
+ Correct! The first line specifies the current branch.
@@ -65,13 +47,14 @@
- git branch <fixTypoInName>
+ The branch name is displayed at the end of the second line.
+ It is "origin/main".
- The command should not contain < >.
+ The second line specifies the origin branch not the active branch.
@@ -79,13 +62,13 @@
- branch fixTypoInName
+ The branch name is not displayed in the output from this git command.
- The command is missing git.
+ Look again, the active branch is listed.
@@ -93,13 +76,14 @@
- git fixTypoInName
+ The branch name is displayed at the end of the last line.
+ It is "working tree".
- The command is missing branch.
+ The last line indicates if there are changes to commit.
@@ -107,252 +91,104 @@
- Look back at the format of the command in the previous description.
+ Look at the first line of the output from the git status command.
-
+
- Adapt the command from to create a branch for the issue you claimed.
- Type that command now.
-
-
-
- What output was produced when you typed the git branch command?
+ Your output should contain the text “Your branch is up to date with 'origin/main'.” What do you think it means that your branch is “up to date”?
+
+
-
-
-
-
- No output was provided.
-
-
-
-
-
- Correct!
-
-
-
-
-
-
-
- It said the branch was created.
-
-
-
-
-
- Look at the terminal window again.
-
-
-
-
-
-
-
- It gave an error statement.
-
-
-
-
-
- Your branch was not created.
- Make sure your branch name does not contain spaces and < >
-
-
-
-
-
-
-
- The current branch is <branch name>.
-
-
-
-
-
- Look at the terminal window again.
-
-
-
-
-
-
+
+
- Look back at the format of the command and make sure you type it correctly.
+ Your output should contain the text “nothing to commit, working tree clean.” What do you think it means that you have “nothing to commit.” Hint: when would you have something to commit? This is the opposite of that!
-
+
+
-
+
- The git branch command without the branch name lists all branches.
+ The git branch <name> command creates a new branch with the given name.
+ When creating a branch, you should give it a short but descriptive name (e.g.
+ FixTypoInReadme).
+ Note: name may not have spaces, so you can use - (dashes) or CammelCaseText to divide words in your branch names.
-
+
- Type git branch and look at the output produced.
- Which of the following do you see listed?
+
+ Create a new feature branch with a descriptive name that you will use to fix the issue that you claimed.
+ Remember not to include the < > when writing your own command.
+ Type the command you entered below.
+
+
+
-
-
-
-
- main
-
-
-
-
-
- Correct!
-
-
-
-
-
-
-
- name which is the name of your feature branch
-
-
-
-
-
- Correct!
-
-
-
-
-
-
-
- git
-
-
-
-
-
- git is a command and should not be your branch name
-
-
-
-
-
-
-
- <name> which is the name of your feature branch
-
-
+
+
+
+ Use the git status command again now.
+
+
+ Creating a new branch with the git branch command makes your new branch the active branch.
+
+
-
-
- The branch name should not have < >.
-
-
-
-
+
+
+ git branch <name> only creates the branch.
+
+
- If you don't see your branch name it means it was not created.
- Try creating it again using the format of the command from .
+ After you create a branch what needs to be done to make it active?
-
-
+
- By looking at the output provided by git branch how can you tell which is the active branch?
+ How can you tell from the output in if it switched you to the new branch?
-
-
-
-
-
-
- It will have an * before the branch name.
-
-
-
-
-
- Correct!
-
-
-
-
-
-
-
- The branch name will appear in green.
-
-
-
-
-
- Correct!
-
-
-
-
-
-
-
- The branch name will appear in italics.
-
-
-
-
-
- Look at the output provided in the terminal window again.
-
-
-
-
-
-
-
- The branch name will appear in bold.
-
-
-
-
-
- Look at the output provided in the terminal window again.
-
-
-
-
-
-
-
- There are two ways the active branch is indicated.
-
-
+
- Refer back to to see the process you just completed.
+ illustrates the process you just completed to create a feature branch. The feature branch created is shown in orange.
+
+
+
+
+
Create Feature Branch.
+
+
+ Cloud image of origin, upstream, and local branches.
+
+
+
+
diff --git a/source/ch-upstreaming-changes/sec-creating-a-pull-request.ptx b/source/ch-upstreaming-changes/sec-creating-a-pull-request.ptx
index 96595c4..9dbc983 100644
--- a/source/ch-upstreaming-changes/sec-creating-a-pull-request.ptx
+++ b/source/ch-upstreaming-changes/sec-creating-a-pull-request.ptx
@@ -87,13 +87,43 @@
The questions in this exercise will help you to better understand what this information means.
-
+
+
+
+
+
+ Copy the URLs from the gray bar into the textboxes below.
+
+
+
+
+
+
+
+ Base Repository
+
+
+
+
+
+
+
+
+
+ Head Repository
+
+
+
+
+
+
+
- The terms “Base Repository” and “Head Repository” are generic labels that GitHub uses for the two repositories that are involved in the pull request.
+ The terms “Base Repository” and “Head Repository” in are generic labels that GitHub uses for the two repositories that are involved in the pull request.
Often, and in our case, these two repositories will be your origin repository and the project's upstream repository.
- Match the right hand column with either head repository or base repository to indicate which term refers to your origin and which refers to the upstream.
+ Examine the URL's from and match the right hand column with either head repository or base repository to indicate which term refers to your origin and which refers to the upstream.
@@ -118,7 +148,7 @@
Match the right hand column with either base branch or compare branch to indicate which is “pulled from” or “merged into”.
-
+ base branchmerged into
@@ -126,7 +156,7 @@
The base is where you want your changes merged into.
- The compare is where your changes are being pulled from.
+ The head is where your changes are being pulled from.
@@ -179,7 +209,7 @@
- The #123 part of the line should automatically become a link to the issue.
+ The #123 part of the line should automatically become a link to the ticket.
If it does not, check to be sure you have entered the information exactly as shown above.
@@ -189,7 +219,7 @@
- Check the status of your PR and confirm that it can be merged automatically.
+ Check that status of your PR and confirm that it can be merged automatically.
The status will be listed at the top of the GitHub page below the image from
@@ -234,30 +264,12 @@
+
-
-
-
-
-
-
- The upstream repository is the repository you forked from.
- Double check that you aren't in your origin repository.
-
-
-
-
-
-
- In GitHub look at the top left side of the browser window.
- If it says "forked from" with a link it means you are in your fork instead of the upstream repository.
- Click that link to go to the upstream repository.
-
-
-
+
On your pull request page there will be “Files Changed” tab:
@@ -277,8 +289,13 @@
It also indicates the changes you have made.
The project maintainers will often use this diff to see the details of what you have changed.
+
+
+
+
+
- Which of the following describes how the diff indicates the changes that you made?
+ Briefly describe how the diff indicates the changes that you made.
@@ -292,12 +309,6 @@
The change(s) appear in both in bold.
-
-
-
- Correct! You can see the changes by comparing the red and green lines.
-
-
@@ -306,12 +317,6 @@
The line(s) which contains the change(s) appears once in red.
-
-
-
- The red only shows what is being deleted.
-
-
@@ -320,12 +325,6 @@
The line(s) which contains the change(s) appears once in green.
-
-
-
- The green only shows what is being inserted.
-
-
@@ -334,21 +333,9 @@
Only the changed word(s) appear with the old in strike through and the new next to it.
-
-
-
- GitHub doesn't use strike through to indicate changes.
-
-
-
-
-
- The diff command will color code the changes.
- Lines that are changed will show both the original line and the updated line.
-
In the last two sections you created a feature branch and switched to that branch.
In this section you will edit your local files to fix the issue that you claimed in the issue tracker.
- Confirm you are on your feature branch now.
@@ -20,80 +19,42 @@
- Provide the URL to the issue that you claimed in the issue tracker.
+ Provide a link to the issue that you claimed in the issue tracker.
-
-
-
- Thank you.
-
-
-
-
-
-
- Make sure you have pasted the complete URL starting with https and ending with the issue number.
-
-
-
+
Read the issue that you claimed.
- To make the requested change you will need to open the file.
- Click <Code> to see the files in the repository.
- Use the issue to locate the file.
- Once you have found it, click on it to open it.
-
-
- In which file will you be making changes to address your issue? Hint: Look at the text of your issue in the issue tracker.
- Be careful to use the same capitalization as given in the issue.
-
-
-
-
-
-
-
-
- Thank you.
-
-
-
+
+
+
+ In which file will you be making changes to address your issue? Hint: Look at the text of your issue in the issue tracker.
+
+
+
+
-
-
- Double check the spelling of the file name, that the name is ALL CAPS, the .md at the end of the file name is included and in lower case.
-
-
-
-
-
-
-
- Use a text editor to modify the file you identified in so that the issue you claimed has been fixed.
-
-
- Find the file in the Explorer pane to the left. This should show you the list of all the files and folders in the project. If you do not see the list of files and folders, click on the icon that looks like one sheet of paper on top of another.
-
-
- Open the file in the editor and make the changes in the issue you claimed.
-
-
- Your changes should be automatically saved.
-
-
+
+
+
+
+ Use a text editor to modify the file you identified in so that the issue you claimed has been fixed.
+ Be sure to save your changes.
+
+
+
@@ -119,24 +80,20 @@
- If you see the message "nothing to commit, working tree clean", it means that your edits in the previous exercise were not saved.
+ What does the output tell you about the current status of the repository? If you see the message "nothing to commit, working tree clean", it means that your edits in the previous exercise were not saved.
Go back and save your edits and then issue the git status command again before answering the questions below.
-
+
+
How many files are not staged?
@@ -168,7 +125,7 @@
- Correct! The file you changed has been modified but not staged yet.
+ Correct! The file you changes has been modified but not staged yet.
@@ -213,7 +170,7 @@
- How many files will be committed?
+ How many files are added to the commit?
@@ -242,7 +199,7 @@
- Unless you already issued the git stage command you shouldn't have any files ready to be committed.
+ Unless you already issued the git add command you shouldn't have any files ready to be committed.
@@ -285,84 +242,89 @@
-
+
The git diff command provides another way to examine or confirm the changes you have been making.
Note diff is just short for difference, and is called this because it is used to show differences.
- By default the git diff command will show you any changes that have been made to your local files that have not yet been staged.
+ By default the git diff command will show you any changes that have been made to your local files as compared to the version in the most recent commit in the active branch.
Run the git diff command now.
+
-
- How is the change that you made indicated in the output from git diff?
-
-
+
+
+
+ How is the change that you made indicated in the output from git diff?
+
+
-
-
-
-
- The new text is in red, the old text is in green.
-
-
-
-
-
- Look again to see what color your change appears in.
-
-
-
-
-
-
-
- The new text is in green, the old text is in red.
-
-
-
-
-
- Correct! The original text is in red, your changes are in green.
-
-
-
-
-
-
-
- Only the new text appears.
-
-
-
-
-
- Look again, you should see the original text as well.
-
-
-
-
-
-
-
- The old text appears with a strike-through line across it.
-
-
-
-
-
- Strike-through is not part of the feedback git commands can provide.
-
-
-
-
-
-
-
- Look at the feedback again and look for your change.
- Do you also see the original text?
-
-
+
+
+
+
+
+ The new text is in red, the old text is in green.
+
+
+
+
+
+ Look again to see what color your change appears in.
+
+
+
+
+
+
+
+ The new text is in green, the old text is in red.
+
+
+
+
+
+ Correct! The original text is in red, your changes are in green.
+
+
+
+
+
+
+
+ Only the new text appears.
+
+
+
+
+
+ Look again, you should see the original text as well.
+
+
+
+
+
+
+
+ The old text appears with a strike-through line across it.
+
+
+
+
+
+ Strike-through is not part of the feedback git commands can provide.
+
+
+
+
+
+
+
+ Look at the feedback again and look for your change.
+ Do you also see the original text?
+
- Like in the previous chapter, you will be working within the development environment for this exercise.
-
-
-
- Current State:
-
-
-
- shows where you should be based upon the exercises in the previous chapter. You will have forked the upstream FarmData2 repository into your own GitHub account. You will then have cloned your fork into a local repository in the development environment. Your local files at this point are a copy that reflects the current state of the upstream main branch.
-
-
-
- Let's explore this state just a little before making the changes that address the issue that you have claimed.
-
-
-
-
-
Fork, Clone and Local Files.
-
-
- Cloud image of fork, clone, and local files.
-
-
-
+ Like in the previous chapter, you will be working within the KitClient for this exercise.
+
+ Current State:
+
-
- Restarting the Development Environment
+
+ shows where you should be based upon the exercises in the previous chapter. You will have forked the upstream FarmData2 repository into your own GitHub account. You will then have cloned your fork into a local repository on your computer. Your local files at this point are a copy that reflects the current state of the upstream main branch.
+
-
-
-
-
+
+ Let's explore this state just a little before making the changes that address the issue that you have claimed.
+
-
-
-
-
- Click here to open your development environment.
- Please be patient as this can take a few minutes.
- When the development environment is ready you will see the message "Kit development environment is ready for use." and your browser window will look similar to the following:
+
+
+
Fork, Clone and Local Files.
+
- The GitKit Development Environment.
- The development environment is ready when you see the "Kit development environment is ready for use" message.
+ Cloud image of fork, clone, and local files.
-
-
-
-
-
-
-
- <c>git log</c>
+
+
-
+
+
+
- The git log command provides a way to see information about the history of the project.
- It will display information about the most recent commits that have been made to the repository.
- By default, git log displays information about the 10 most recent commits.
- You can append a -2 (or -5) to show only the most recent 2 (or 5) commits.
+ Restart your KitClient based on the instructions in .
-
-
-
-
-
-
-
-
- Which of the following commands will provide the four most recent commits?
-
-
-
-
-
-
-
-
- git log
-
-
-
-
-
- This will provide information about the 10 most recent commits, not just the first four.
-
-
-
-
-
-
-
- git log 4
-
-
-
-
-
- This is not the proper format, a symbol is missing before the 4.
-
-
-
-
-
-
-
- git log -4
-
-
-
-
-
- Correct!
-
-
-
-
-
-
-
- git log +4
-
-
-
-
-
- The symbol before the 4 is incorrect.
-
-
-
-
-
-
-
- Refer back to the beginning of this subsection for specifics about the git log command.
-
-
-
-
-
-
-
-
- Ensure that you are in your cloned repo (i.e.
- the GitKit-FarmData2 directory is your working directory).
- Then use the git log command from to display the information about the 4 most recent commits.
- (If you don't see all four recent commits, press "return" or "spacebar" to see more; when you are done, press "q" to quit.)
-
+
-
- A line that begins with "commit" appears at the start of the information about each commit.
- That line also contains a long string of numbers and letters.
- That string is called the SHA (secure hashing algorithm) hash.
- It is a string of digits (0-9) and letters (a-f) known as a hexadecimal number and it provides a unique identifier for the commit.
- Following the SHA hash is information about the author, the date the commit was made and the commit message that was used to describe the changes.
-
+
+ The git log command provides a way to see information about the history of the project.
+ It will display information about the most recent commits that have been made to the repository.
+ By default, git log displays information about the 10 most recent commits.
+ You can append a -2 (or -5) to show only the most recent 2 (or 5) commits.
+
-
- Paste the output of the git log command you typed in the space below.
-
-
-
-
-
-
-
+
+
+
+ Ensure that you are in your cloned repo (i.e.
+ the GitKit-FarmData2 directory is your working directory).
+ Then use the git log command to display the information about the 4 most recent commits.
+ (If you don't see more all four recent commits, press "return" or "spacebar" to see more; when you are done, press "q" to quit.)
+
+
+ A line that begins with "commit" appears at the start of the information about each commit.
+ That line also contains a long string of numbers and letters.
+ That string is called the SHA (secure hashing algorithm) hash.
+ It is a string of digits (0-9) and letters (a-f) known as a hexadecimal number and it provides a unique identifier for the commit.
+ Following the SHA hash is information about the author, the date the commit was made and the commit message that was used to describe the changes.
+
-
- Reviewing the <c>git log</c> Output
+
+ Use the output from the git log command to answer the following questions about the project history. Note, if you have started this exercise late, new commits may have been added. If so, you will need to look at more than the 5 most recent commits to answer the question.
+
+
-
-
- Use the output from the to answer the following questions about the project history.
- Note, if you have started this exercise late, new commits may have been added.
-
-
-
-
-
@@ -257,13 +138,11 @@
- Look at the dates of each commit.
- The SHA code appears above the author of the commit and date the commit was made.
+ Look at the dates of each commit. The SHA code appears above the author of the commit and date the commit was made.
-
@@ -271,7 +150,6 @@
-
@@ -324,7 +202,7 @@
- There is a more recent commit.
+ There is a more recent commit.
@@ -337,7 +215,6 @@
-
@@ -345,7 +222,6 @@
-
@@ -411,15 +287,13 @@
-
- What is the purpose of the most recent commit by Elad Sheskin (username: shes-dev)?
+ What is the purpose of the most recent commit by shes-dev?
-
@@ -497,255 +371,8 @@
This commit is older than the others, try a git log command that shows a few more commits.
-
-
-
-
-
-
-
- <c>git status</c>
-
-
-
- The git status command provides the current status of your local repository.
- Use the git status command to see the current status of your local GitKit-FarmData2 repository.
-
-
-
-
-
-
-
-
-
- What part of the output tells you which branch is currently active in your repository?
-
-
-
-
-
-
-
- The branch name is displayed in the first line after "On branch".
-
-
-
-
-
- Correct! The first line specifies the current branch.
-
-
-
-
-
-
-
- The branch name is displayed at the end of the second line.
- It is "origin/main".
-
-
-
-
-
- The second line specifies the origin branch not the active branch.
-
-
-
-
-
-
-
- The branch name is not displayed in the output from this git command.
-
-
-
-
-
- Look again, the active branch is listed.
-
-
-
-
-
-
-
- The branch name is displayed at the end of the last line.
- It is "working tree".
-
-
-
-
-
- The last line indicates if there are changes to commit.
-
-
-
-
-
-
-
- Look at the first line of the output from the git status command.
-
-
-
-
-
-
-
-
- Your output should contain the text “Your branch is up to date with 'origin/main'.” What do you think it means that your branch is “up to date”?
-
-
-
-
-
-
-
-
- It means that your branch contains all of the commits in the origin main branch.
-
-
-
-
-
- Correct!
-
-
-
-
-
-
-
- It means that the origin main branch contains all of the commits in your local branch.
-
-
-
-
-
- Think about what is being compared in that statement.
-
-
-
-
-
-
-
- It means that your branch contains all of the issues in the origin main branch.
-
-
-
-
-
- Issues are not part of a branch.
-
-
-
-
-
-
-
- It means that the origin main branch contains all of the issues in your branch.
-
-
-
-
-
- Issues are not part of a branch.
-
-
-
-
-
-
-
- Think about what could be "out of date".
- What differences might there be between the origin main and your branch?
-
-
-
-
-
-
-
-
- Your output should contain the text “nothing to commit, working tree clean.” What do you think it means that you have “nothing to commit.”
-
-
-
-
-
-
-
-
- It means that you haven't made any changes.
-
-
-
-
-
- Correct!
-
-
-
-
-
-
-
- It means that you haven't created any issues.
-
-
-
-
-
- Issues aren't part of a branch.
-
-
-
-
-
-
-
- It means you haven't made any branches.
-
-
-
-
-
- Branches aren't committed.
-
-
-
-
-
-
-
- It means the origin main branch doesn't have any changes.
-
-
-
-
-
- This statement is referring to your local branch, not origin main.
-
-
-
-
-
-
-
- When would you have something to commit? This is the opposite of that!
-
-
-
-
-
-
- In the next section you will create a feature branch.
-
-
diff --git a/source/ch-upstreaming-changes/sec-git-command-summary.ptx b/source/ch-upstreaming-changes/sec-git-command-summary.ptx
index f374308..30e8a76 100644
--- a/source/ch-upstreaming-changes/sec-git-command-summary.ptx
+++ b/source/ch-upstreaming-changes/sec-git-command-summary.ptx
@@ -22,39 +22,21 @@
git logDisplay recent commits made to the active branch.
- git branch <branch>Create a new feature branch.
+ git branch <branch> Create a new feature branch.
- git branchLists all branches.
+ git switch <branch> Change the active branch
- git switch <branch>Change the active branch
+ git status Check the current state of your local repo.
- git statusCheck the current state of your local repo.
+ git status <file name> Display the changes that you made to a file.
- git diffDisplays unstaged changes.
+ git stage <file name> Stage changed files to be committed to the repo.
- git diff --stagedDisplays staged changes.
-
-
- Note that the tasks listed are in approximately the same order as they appear in the sections of this chapter.
-
-
-
-
-
-
-
- Match the tasks on the right with the appropriate git command listed on the left.
-
-
-
-
- git stage <file name>Stage changed files to be committed to the repo.
-
- git add <file name>Another way to stage changed files for a commit.
+ git add <file name> Another way to stage changed files for a commit.
- git commit -m "message"Commit staged files with a message.
+ git commit -m "message" Commit staged files with a message.
- git push <remote> <branch>Push a feature branch to your origin.
+ git push <remote repo name> <branch> Push a feature branch to your origin.
Note that the tasks listed are in approximately the same order as they appear in the sections of this chapter.
diff --git a/source/ch-upstreaming-changes/sec-pushing-a-branch-to-your-origin.ptx b/source/ch-upstreaming-changes/sec-pushing-a-branch-to-your-origin.ptx
index d4009d7..4d2e46c 100644
--- a/source/ch-upstreaming-changes/sec-pushing-a-branch-to-your-origin.ptx
+++ b/source/ch-upstreaming-changes/sec-pushing-a-branch-to-your-origin.ptx
@@ -31,15 +31,13 @@
- The git branch command lists all of the branches that exist in your local repository.
+ The git branch -l (lower case L, not one) command lists all of the branches that exist in your local repository.
-
How many branches are in your local repository?
-
@@ -47,7 +45,6 @@
1 - main
-
Look again, you should see more than just the main branch.
@@ -58,13 +55,12 @@
- 1 - feature branch that you created in
+ 1 - feature branch
-
- Look again, you should see more than just the feature branch.
+ Look again, you should see more than just the feature branch.
@@ -72,13 +68,12 @@
- 2 - main and feature branch that you created in
+ 2 - main and feature branch
-
- Correct! Your local repository will have both the main branch and your feature branch.
+ Correct! Your local repository will have both the main branch and your feature branch.
@@ -89,10 +84,9 @@
3 or more with differing branch names
-
- If you have more than 2 branches perhaps you created a feature branch multiple times by accident.
+ If you have more than 2 branches perhaps you created a feature branch multiple times by accident.
Correct! There is only 1 branch, main in your origin repository on GitHub.
-
+
- 1 - feature branch that you created in
+ 1 - feature branch
-
- Look again, your feature branch should not be listed in GitHub as it is only in your local repository.
+ Look again, your feature branch should not be listed in GitHub as it is only in your local repository.
-
+
- 2 - main and feature branch that you created in
+ 2 - main and feature branch
-
- Look again, your feature branch should not be listed in GitHub as it is only in your local repository.
+ Look again, your feature branch should not be listed in GitHub as it is only in your local repository.
-
+
3 or more with differing branch names
-
- Perhaps you aren't in your origin repository.
- Make sure you see your GitHub userid in the upper left hand corner of your GitHub tab.
+ Perhaps you aren't in your origin repository. Make sure you see your GitHub userid in the upper left hand corner of your GitHub tab.
-
+
- Make sure you are in your origin repository, not the upstream repository.
- Refer to and look at the origin to see what branches appear on GitHub.
+ Make sure you are in your origin repository, not the upstream repository. Refer to and look at the origin to see what branches should appear on GitHub.
@@ -195,247 +182,129 @@
Why is there a difference between the branches in your origin repository and your local repository?
+
+
+
+
+ Getting a Personal Access Token:
+
-
-
-
-
- You created a branch in your local repository but it does not appear in the origin repository yet.
-
-
-
-
-
- Correct!
-
-
-
-
-
-
-
- You created a branch in the origin repository but it does not appear in your local repository.
-
-
-
-
-
- Your branch is in your local repository, not the origin repository.
-
-
-
+
+ Before you will be able to push your feature branch to GitHub you will have to get a Personal Access Token (PAT) from GitHub.
+ A PAT is like a password but has some security benefits.
+ In particular, you can have multiple different PATs.
+ Each one can have different limits on what can be done with it and each one can be revoked individually without affecting the others.
+
-
-
-
- Someone else created a branch in the origin repository.
-
-
+
+ When interacting with GitHub using the git CLI (e.g.
+ when pushing a branch), GitHub requires that you use a PAT for authentication instead of your password.
+
-
-
- Branches are created in the local repository.
- It is possible that someone else created a branch in their local repository and pushed it to their origin.
- You have a different origin repository so you would not see it.
-
-
-
+
+
+
+ Follow GitHub's instructions for creating a (classic) personal access token: Creating a Personal Access Token (classic).
+
-
-
+
+ When doing so be sure to:
+
+
- Someone else created a branch in their local repository and it appears in the origin repository.
+ Choose “repo” for the “scopes and permissions.”
-
+
-
+
- It is possible that someone else created a branch in their local repository and pushed it to their origin.
- You have a different origin repository so you would not see it.
+ Be sure to copy and paste your PAT somewhere safe – maybe e-mail it to yourself.
+ You will not be able to retrieve it again after you leave the page.
-
-
-
+
+
+
-
-
- All the work you have done in this chapter is on your local machine.
- What should be appearing in your local repository that is not in the origin repository?
-
-
-
+
+ Note: Typing or even copy and pasting your PAT every time it is needed can be a hassle.
+ To help, the git CLI provides what is known as the credential helper.
+ The git CLI in the KitClient has configured the credential helper so that your PAT will be stored when you enter it the first time.
+ It will then be used automatically for future commands.
+ If you are curious, you can learn more about the credential helper here: Storing Git Credentials with Git Credential Helper.
+
+
Pushing your Feature Branch:
-
-
+
+
- The git push <remote> <branch> command will push the specified branch of your local repository to the specified remote repository (i.e.
+ The git push <remote repository name> <branch> command will push the specified branch of your local repository to the specified remote repository (i.e.
on GitHub).
- You will need to push your feature branch from your local repository to your origin repository on GitHub.
- You have given your remote repository the name origin which you can use instead of the full URL.
- For example, git push origin <branch> and the name of your branch where you committed your change.
- Type the command now.
+ Use a command that will push your feature branch from your local repository to your origin repository on GitHub.
- The output should not contain any error messages.
- If you see error messages, make sure you spelled your branch name correctly and your command is in the proper format and does not include < >.
- The last few lines should also give you some indication that your push was successful.
- Look at the last two lines of output produced.
+ Note: You can use the name of the remote repository, so you do not need to use the full URL.
+ You will also need to paste your PAT as the password when it is requested. The cursor will not move when you put in the PAT nor will you see any characters. After you type or paste it hit Enter
-
-
-
-
-
-
-
- The second to last line is the URL of the origin repository.
-
-
-
-
-
- Correct!
-
-
-
-
-
-
-
- The last line provides the name of the branch in the local repository that was pushed to the origin repository.
-
-
-
-
-
- Correct!
-
-
-
-
-
-
-
- The second to last line is the URL of your local repository.
-
-
-
-
-
- Your local repository does not have a URL, it is on your local machine.
-
-
-
-
-
-
-
- The last line provides the URL of the branch in the local repository that was pushed to the origin repository.
-
-
-
-
-
- This shows the name of the branch, not a URL.
-
-
-
-
+
+
-
+
+
- There are several lines of output that mention deltas.
- Ignore these.
- Make sure you are looking at the last two lines - the first of which begin with To and the second of which begins with a hexademical code.
+ The output from should not contain any error messages.
+ The last few lines should also give you some indication that that your push was successful.
+ Visit your origin repository on GitHub and check that the branch was pushed.
-
+
-
-
+
+
- Visit your origin repository on GitHub and check that the branch was pushed.
- You may have to reload the page.
+ The git push <remote repo name> <branch> command will push the specified branch of your local repo to the specified remote repo (i.e.
+ on GitHub).
+
- How can you tell your branch was pushed?
+ Use a command that will push your feature branch from your local repo to your origin repo on GitHub.
-
-
-
-
-
-
-
- The number next to the Branches link is now 2.
-
-
-
-
-
- Correct! The number of branches should have increased.
-
-
-
-
-
-
-
- When I click on Branches my branch is now listed in addition to main.
-
-
-
-
-
- Correct! You should be able to see both branches on this page.
-
-
-
-
-
-
-
- The number of issues has increased.
-
-
-
-
-
- Pushing a branch will not create an issues.
-
-
-
-
-
-
- The number of pull requests has increased.
-
-
+
+ Note: You can use the name of the remote repo, so you do not need to use the full URL.
+
+
+
-
-
- Pushing a branch will not create a pull request.
-
-
-
-
+
+
+
+ When you attempted to push in , you should have gotten an authorization error.
+ When this happens VSCode will prompt you in the lower right to open GitPod and configure the authorization.
+ Do that.
+ When done, return to your GitPod workspace and try the push again.
+ It should work.
+
-
- There are multiple ways you can tell that your branch has been pushed by looking at the origin repository on GitHub.
+ If you get the same pop up, open it again.
+ Look for the GitHub authorization.
+ Click the "..." menu next to it and edit it.
+ Ensure that "repo" with read/write permissions are set and save it.
+ It will send you to GitHub to complete the authorization.
+ When done, return to your GitPod workspace and try the push again.
+ It should work.
- The exercises in this section will walk you through staging the changes you made to your Local Files.
-
-
-
- The git stage <file> command adds the indicated file to the stage, preparing it to become a part of the next commit.
+ The exercises in this section will walk you through staging the changes you made to your Local Files.
-
-
- Write a git stage <file> command to stage the file that you edited.
+
+
+ The git stage <file> command adds the indicated file to the stage, preparing it to become a part of the next commit.
+ Use the git stage <file> command now to stage the file that you edited.
-
- Enter the command you wrote below.
-
-
-
-
-
-
-
-
-
-
- Thank you.
-
-
-
-
-
-
- Are you sure that is the file that the issue asked you to edit?
-
-
-
-
-
-
+
+
+
+
+
- Check your issue again to see which file you should have edited.
+ Provide the command you entered.
-
-
+
+
+
+
-
+
- Now run the git status command again.
- Paste the output of the git status command below.
+ Note that git also has a git add command that is equivalent to git stage.
+ So, you can add files to the stage using either git stage or git add.
+ These activities will use git stage because it seems more descriptive of what is happening.
+ However, you are likely to see git add used in other resources, so it is worth knowing that they are equivalent.
+ Provide the git add command that would be equivalent to your answer in .
-
+
+
-
+
- Compare your output in to the output in .
+ Now run the git status command again.
+ Compare your output in to the output in .
@@ -105,7 +88,7 @@
- Correct! After issuing the git stage command the file will be staged.
+ Correct! After issuing the git stage (or git add) command the file will be staged.
@@ -119,7 +102,7 @@
- Did you change more than 1 file by accident? Verify that you only changed the file specified in your issue.
+ Once you have issued the git stage command it show that the file is ready to be committed.
@@ -155,12 +138,13 @@
- Staged means a file has been modified and will be added to the commit.
+ Staged means a file has been modified and added to the commit.
-
+
+
-
+
How many files are listed as ready to be committed?
@@ -228,98 +212,10 @@
- Staged means a file has been modified and will be added to the commit.
+ Staged means a file has been modified and added to the commit.
-
-
-
-
-
-
- Run the git diff command again.
- What output is produced?
-
-
-
-
-
-
-
-
- No output is produced.
-
-
-
-
-
- Correct! There are no differences because your changes were staged.
-
-
-
-
-
-
-
- It shows the file name that I changed.
-
-
-
-
-
- If you are seeing the file name you changed it means either you made additional changes after the git stage command was done or your git stage command did not work properly.
-
-
-
-
-
-
-
- It shows the code I added in green.
-
-
-
-
-
- If you are seeing code changes it means either you made additional changes after the git stage command was done or your git stage command did not work properly.
-
-
-
-
-
-
-
- It shows the code I deleted in red.
-
-
-
-
-
- If you are seeing code changes it means either you made additional changes after the git stage command was done or your git stage command did not work properly.
-
-
-
-
-
-
-
- The git diff command will only show the changes that have yet to be staged.
-
-
+
-
-
-
- The git diff --staged command will show you the differences between the staged changes and the most recent commit.
- Try this command now.
-
-
-
- Note that git also has a git add command that is equivalent to git stage.
- So, you can add files to the stage using either git stage or git add.
- These activities will use git stage because it seems more descriptive of what is happening.
- However, you are likely to see git add used in other resources, so it is worth knowing that they are equivalent.
-
-
diff --git a/source/ch-upstreaming-changes/sec-switching-branches.ptx b/source/ch-upstreaming-changes/sec-switching-branches.ptx
index 151aa2a..7054a95 100644
--- a/source/ch-upstreaming-changes/sec-switching-branches.ptx
+++ b/source/ch-upstreaming-changes/sec-switching-branches.ptx
@@ -8,21 +8,6 @@
In the previous section you learned how to create a branch.
In this section you will learn more about why branching is important and how to switch between existing branches.
-
-
- Figure illustrates this idea by showing what what will happen when you switch to your feature branch and your Local Files have not been modified since the last commit on the main branch (drawn in green).
-
-
-
-
-
Switch to Feature Branch.
-
-
- Cloud image of origin, upstream, and local branches (including new feature branch).
-
-
-
-
@@ -30,7 +15,7 @@
- As you saw in , the git branch <name> command creates a branch (among other uses), but it does not change your active branch.
+ As you saw in the previous section, the git branch command creates a branch (among other uses), but it does not change your active branch.
The git switch <name> command switches (i.e.
changes) the active branch.
@@ -40,279 +25,98 @@
- Type git switch <name> to change your active branch to the new feature branch that you created in the previous section.
- What output is produced?
+ What command will change your active branch to the new feature branch that you created in the previous section?
+
+
-
-
-
-
- Switched to branch '<name>'
-
-
-
-
-
- Correct!
-
-
-
-
-
-
-
- Switched to branch 'main'
-
-
-
-
-
- You were on main prior to switching branches.
-
-
-
-
-
-
-
- error: Your local changes to the following files would be overwritten by checkout: ...
-
-
-
- Aborting
-
-
+
+
+
+ Use the git status command again now.
+ What part of the output confirms that your feature branch is now the active branch?
+
+
+
+
+
-
-
- You should not have made any changes so far.
-
-
-
+
+ Figure illustrates this idea by showing that you have switched to your feature branch and that your Local Files have not been modified since the last commit on the main branch (drawn in green).
+
+
+
+
Switch to Feature Branch.
+
+
+ Cloud image of origin, upstream, and local branches (including new feature branch).
+
+
+
+
-
-
-
- fatal: invlalid reference: <name>
-
-
+
+
+
+ You can also switch branches using the git branch command.
+
+
-
-
- You probably typed the branch name incorrectly.
- Run git branch again to see the name of the branch you created.
-
-
-
-
-
+
+
- Make sure you don't include < > in your git switch <name> command.
+ Issue the git branch command now. You should see a list of branches. How can you tell which branch is the active branch?
-
+
+
-
+
- Which of the following commands could be used to confirm that your feature branch is now the active branch?
+ git branch <name> will make name the active branch. Enter a git branch command that will make main the active branch. What command did you enter?
+
+
-
-
-
-
- git branch
-
-
-
-
-
- Correct!
-
-
-
-
-
-
-
- git status
-
-
-
-
-
- Correct!
-
-
-
-
-
-
-
- git log
-
-
-
-
-
- git log will show the commit history, it will not show the active branch
-
-
-
-
-
-
-
- git branch <name>
-
-
-
-
-
- When git branch ends with a name it creates a new branch, it does not show what is active.
-
-
-
-
-
-
+
+
- There are two commands that will provide information about the active branch.
+ How do you know that main is the active branch?
-
+
+
+
-
-
+
- Which of the following commands could be used to make main the active branch?
+ In the next section you will be making changes to your Local Files. It is essential that you are on your feature branch before making any changes.
+
+
+ Enter a git branch command that will make your feature branch the active branch. What command did you enter?
+
+
-
-
-
-
- git switch main
-
-
-
-
-
- Correct!
-
-
-
-
-
-
-
- git branch main
-
-
-
-
-
- This will try to create a new branch named main.
-
-
-
-
-
-
-
- git branch
-
-
-
-
-
- git branch will show all the branches
-
-
-
-
-
-
-
- git status
-
-
-
-
-
- git status will show the active branch and information about changes
-
-
-
-
-
-
+
+
- Refer back to how you made your feature branch the active branch.
+ How do you know that your feature branch is the active branch?
-
+
+
-
-
-
- Type the command from and verify that main is the active branch.
-
-
-
-
- Assuming you are on the main branch, drag the steps that will make your feature branch the active branch and verify you are on your feature branch.
- Some steps may not be used.
-
-
-
-
- git switch
-
-
-
-
- git switch <name>
-
-
-
-
- git branch <name>
-
-
-
-
- git branch
-
-
-
-
- git switch main
-
-
-
-
-
- Think about how you make a branch active and then verify it.
-
-
-
-
-
- Use the commands from to make your feature branch the active branch and verify your active branch.
-
-
diff --git a/source/docinfo.ptx b/source/docinfo.ptx
index ba40b81..ed6c2af 100644
--- a/source/docinfo.ptx
+++ b/source/docinfo.ptx
@@ -5,9 +5,9 @@
- gitkit
+ gitkitlinux
- A hands-on introduction to Open Source collaboration using a git/gitHub forking workflow.
+ A hands-on introduction to Open Source collaboration using a git/gitHub forking workflow in a Linux desktop environment.
diff --git a/source/frontmatter.ptx b/source/frontmatter.ptx
index cedda3d..a3a60ad 100644
--- a/source/frontmatter.ptx
+++ b/source/frontmatter.ptx
@@ -5,10 +5,6 @@
-
-
-
- Grant BraughtDickinson College
@@ -36,18 +32,7 @@
-
-
- HFOSS Kits
-
-
-
- 2024
- HFOSS Kits
- This work is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License. To view a copy of this license, visit CreativeCommons.org
-
-
-
+
Overview
@@ -116,7 +101,17 @@
-
+
+
+ HFOSS Kits
+
+
+
+ 2024
+ HFOSS Kits
+ This work is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License. To view a copy of this license, visit CreativeCommons.org
+
+
\ No newline at end of file
diff --git a/source/main.ptx b/source/main.ptx
index f51eebd..f650f89 100644
--- a/source/main.ptx
+++ b/source/main.ptx
@@ -5,7 +5,7 @@
- GitKit (2nd ed.)
+ GitKit (Linux Desktop Edition)Learn git and GitHub in Context
@@ -22,4 +22,4 @@
-
\ No newline at end of file
+
diff --git a/source/shared-images/DevEnv-Kitty-Ready.png b/source/shared-images/DevEnv-Kitty-Ready.png
deleted file mode 100644
index 63e8f63..0000000
Binary files a/source/shared-images/DevEnv-Kitty-Ready.png and /dev/null differ
diff --git a/source/shared-images/placeholder.tmp b/source/shared-images/placeholder.tmp
new file mode 100644
index 0000000..ddcd0ec
--- /dev/null
+++ b/source/shared-images/placeholder.tmp
@@ -0,0 +1 @@
+Can be removed when any image is added.
\ No newline at end of file