- 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 -
-
+ The exercises in this section will help to familiarize you with the terminology and the process of this basic FOSS workflow. +
- The next step in the basic FOSS workflow is to ensure that you have a
+ The next step in the basic FOSS workflow is to ensure that you have a
-
- In some development environments cloning the origin requires that you use a command like
- 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
+ In order to clone a repository into your development environment you will need the
+ Visit the GitHub page 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
- Find and click the green "Code" button.
-
-
- Open the "Local" and "HTTPS" tabs as shown here:
+
+ 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.
+
+ Open the "Local" and "HTTPS" tabs as shown here:
- Copy and paste the clone URL that you will use to clone your origin as your answer to this exercise. + 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
+ 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
+ Be sure you are using your GitHub origin repository (see
- 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. -
-
+ The
+ 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
+ Give a command that will clone your origin into your development environment. +
++ +
+- Use the following command in the Terminal to clone your origin repository into your development environment: + Thank you.
+
-
- Be sure to replace
+ Execute your command from
+ 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". + Look at the output in your terminal.
- Use the
- If it it does not, check the output in
- The the output in
- The "Kit-tty" introduces itself using the line - "😺💻 Meow, Kit-tty here!" Read the description of the "Kit-tty" that follows this line. -
-
+ Which line of output from entering the command from
- 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
- What does the "IMPORTANT" line ask you to do? -
-- Close the terminal and open a new one. -
+ Cloning into +- Take the Kit-tty for a walk. -
+ remote: Total- I'm sure the Kit-tty would like that, but its not the correct answer. -
-
- Use the
- Delete some unnecessary files. -
+ Resolving deltas+ Look for a line in the output that begins with "Cloning into". +
+
+ Use the
+ If it it does not, check the output in
+ In this section you will briefly explore the GitKit FarmData2 repository that you have cloned into your development environment. +
+ +
+ Use the
+ See
+ Use the
+ 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. +
+
- If you haven't already, close the Terminal you are currently using and open a new one.
+
- 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. -
-
- Use the
- See
- Use the
- Compare these files and directories to those in your origin repository on GitHub. Are there any differences? If so describe them here.
+
- 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
- Compare these files and directories to those in your origin repository on GitHub. Are there any differences? If so describe them here. -
+ + + + + + + + +
+ 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
+ The command
+ If you want to have git display the URLs of the remotes as well, you will need to add the
+ Which command will show you the URL(s) of the remote(s) that git knows about? +
+
- 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
- Use the following command to ask Git to display a list of the remote repositories (i.e. those on GitHub) that it knows about:
+
-
- Copy and paste the output of the
+ You are asking
+ Execute the command
- Examine the output in
- 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. -
-
- How is the origin remote that you see in the output of the
- 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 step of the basic FOSS workflow requires that your clone know the location of your origin repository? + The "origin" lines have a URL that points to GitHub.
- Pull request -
-- Fork -
-- Clone -
-- Edit -
-- Push -
-+ It is not possible to tell from the output. +
++ Look closely at the "origin" URLs. +
+
+ How is the origin remote that you see in the output of the
+ 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? +
++ Which step of the basic FOSS workflow requires that your clone know the location of your origin repository? +
++ Pull request +
++ Fork +
++ Clone +
++ Edit +
++ Push +
++ Think about which step of the basic FOSS workflow will need to send information from the clone back to the origin. +
+
+ You cloned your fork of the GitKit FarmData2 upstream repository 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 your clone of the GitKit FarmData2 repository. +
++ You can do this by going to the "hamburger" (≡) menu in the upper left of your development environment window. +
+
+ Choose
+ Select the folder containing your clone of the
+ You will see
+ The the output in
+ Your personal virtual assistant. +
++ A terminal. +
++ A teletypewriter. +
++ A pet kitten. +
++ 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 now have been assigned an
- To work on your issue you will need to setup your
- 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
+ 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.
- In this section you will learn how to start, configure, stop, and restart your development environment.
+ The development environment will run in the cloud using a service called
- Your development environment will run in the cloud using a service called GitPod. Visit
- The following tasks will guide you through the process of starting and configuring your development environment. + The following tasks will guide you through the process of creating the development environment.
- Click this link to
-
- Choose "Terminal" as the "Editor - Browser" and "Standard" as the machine "Class" as shown here:
-
- Click the "Continue" button and wait for a few minutes until output that is similar to that shown here to appear: -
-
-
- Click the link in your output that is similar to the one that is shown above. + 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
+ 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
- Click the "Connect" button that appears in your browser.
+ Paste the PAT that you created in
- After clicking the "Connect" button your development environment should open in the browser. It will appear similar to the window shown in
-
+ 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. +
+- There are a few additional things that you can to to make working in your development environment more convenient. + Use the following steps to practice stopping the development environment.
- Use the following steps to make the development environment fill and resize with your 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. -
-
- 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 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". + Close the browser tab containing the development environment.
+ When you return to work after stopping the development environment, you will need to restart it. +
+- The following tasks will guide you through the process of starting and configuring your development environment. + Use the following steps to restart the development environment.
- Click this link to
-
- Paste the URL of your GitKit FarmData2 repository from
- Choose "VS Code..." as the "Editor - Browser" and "Standard" as the machine "Class" as shown here:
-
-
- Click the "Continue" button and wait for the development environment to open in the browser. It will appear similar to the window shown in
+ 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
-
- 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? -
-
Your development environment includes a
- 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
- You will interact with Git using its command line interface via a Terminal. Use the following steps to open a Terminal.
+ The Git CLI is accessed by using the
- Click the "Terminal" icon at the bottom of the development environment window to open a new Terminal.
+ Using the
- Enter your name at the prompt and press enter. This will customize the Terminal prompt for you.
+ Enter the command
- 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. -
-
- Enter the command
- Give a
- Use the output from
- What version of the
- Use the command that you identified in
- 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. -
-- Use the following command to set the name that Git will associate with your changes: -
-
-
- Replace
- Use the following command to set the e-mail that Git will associate with your changes:
+ Check the output of the
-
- Replace
- Use the following command to display Git's global configuration including the two new settings you just added:
+
-
- Give the output of this command as your answer for this task.
+ Check the output of the
- There are a few GitPod settings that you can change that will make working with your development environment more convenient. + 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
+ 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.
- Use the following steps to adjust your GitPod settings.
+ The
+ Give a command that will set the name you want to have associated with your changes by replacing
+ +
+ ++ 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
+ Give a command that will set the email you want to have associated with your changes by replacing
+ +
++ 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
+ Then use the command
- Open your GitPod workspaces in a browser by visiting
- 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.
+
- Click the "Pushpin" icon, or choose "Pin" from the "⋮" (three vertical dots) menu to the right of the "GitKit Dev Env" workspace. -
-
- This will
- Open your GitPod preferences in a browser by visiting
- 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
- 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. -
-
- Open your GitPod workspaces in a browser by visiting
- Choose "Stop" from the "⋮" (three vertical dots) menu to the right of the "GitKit Dev Env" workspace.
+
- When you already have a GitKit development environment and want to continue working on the GitKit exercises, you will need to
- Restart your development environment using the following steps. -
-
- Open your GitPod workspaces in a browser by visiting
- Click the name of your "GitKit Dev Env" workspace or choose "Open" from the "⋮" (three vertical dots) menu to the right of its name.
+
- Wait for the text similar to that in
Thank you. @@ -104,63 +104,105 @@
- Clone your origin (i.e. your fork) for the project you selected into your development environment. -
- Copy and paste the Git commands that you used and their output here.
+ Make sure you are giving the URL for your fork, not the project's upstream URL. Review
- 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. -
+ xml:id="ex-extra-practice-clone" + label="ex-extra-practice-clone"> +- Briefly describe how you created the the development environment, and thus cloned your origin, for the project you have chosen. + Pick and order the commands to change to your home directory, clone your fork of the project you chose and check its remotes.
+ Review
- 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. -
-
+ In your terminal enter the commands from
+ Which of the following do you see in the output of the
+ The origin URL should be the one from your git clone command. +
+Thank you.
Looks like you might be trying to use the real FarmData2 upstream. Be sure to use the URL that your instructor has given you.
Looks like you might be trying to use the real FarmData2 upstream. Be sure to use the URL that your instructor has given you.
+ 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. +
+@@ -82,7 +89,12 @@
+ 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. +
- Click the “Fork” button to create your own fork of the upstream repository. Be sure to pick the GitHub username you used in
Thank you.
Looks like you might be giving the URL of the real FarmData2 upstream. Be sure to give the URL of the fork you created in your GitHub space.
Looks like you might be trying to use the real FarmData2 upstream. Be sure to give the URL of the fork you created in your GitHub space.
+ 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. +
+@@ -175,7 +194,9 @@
+ 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. +
- Visit your origin repository on GitHub. There is some text and a link on that page that corresponds to the orange dashed arrow in
+ 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. +
+ Think about which step of the basic FOSS workflow needs to send information back to the main project. +
- 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? + 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?
-+ 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? +
+
- There are a number of roles that tend to exist in FOSS communities. Some of these included
- 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:
- 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
- -
-- 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. +
+
+ 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:
+ 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
+ +
++ Thank you. +
++ Looks like you are using the example given. Be sure to give the URL of your actual GitHub profile. +
++ Please give the full URL using the format indicated in the question. +
+
+ When starting your development environment for the first time (in
+ 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:
+ 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? +
++ gpat +
++
++ ghp_ +
++ All GitHub PATs begin with ghp_ +
++ 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
-
+ The tasks in this exercise will help you to find the issue tracker for the GitKit FarmData2 repository that you will be using. +
+- 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.
-- 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
- Use the issue tracker in the GitKit FarmData2 repository to complete the following tasks.
+ 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? -
-- Add Missing "that" -
-- Seeding Report: Allows Invalid Inputs -
-- Seeding Input: Duplicates appearing in Area Dropdown -
-- Dickinson College Farm Link -
-+ Use the issue tracker in the GitKit FarmData2 repository to complete the following tasks. +
++ 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
- Which file in the repo would you need to modify in order to fix the typo described in issue #11? -
-- Which of the following indicate an order by which the issues can be sorted? -
-- 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. -
-
+ Each issue can have
- Because projects often have many people working asynchronously many will have a process by which contributors can
- The following exercises will guide you through the process of claiming an issue to work on in the GitKit FarmData2 issue tracker. -
-+ Be sure you are looking at issue #8. +
+- Examine the GitKit FarmData2 issue tracker. - How can you tell which issue have already been assigned? + Which file in the repo would you need to modify in order to fix the typo described in issue #11?
+ Be sure you are looking at issue #11. +
++ Which of the following indicate an order by which the issues can be sorted? +
++ Find the sort drop-down (which will be headed either "Newest" or "Oldest" depending on how it was last set) in the issue tracker and see what sort by options are available. +
+ ++ 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! +
++ Choose the best match. +
+- 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: -
- -
-
- 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. -
-+ Examine the GitKit FarmData2 issue tracker. + How can you tell which issue have already been assigned? +
+- Choose an unassigned issue with a "Round 1" tag. -
-
- Comment on the issue that you chose using the
- Reload the issue tracker and check that you received a response and that the issue has been assigned to you. -
+ The username of assigned user appears next to the issue title.
- 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
- 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
+ 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: +
+ +
+
+ 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. +
+
- Give the full URL to the issue that you have been assigned, for example
+ See
-
+ Comment on the issue that you chose using the
- Thank you. -
-- Please give the full URL using the format indicated in the question. -
-+ 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
- 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? + Reload the issue tracker and check that you received a response and that the issue has been assigned to you.
+ 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
+ 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
+ Give the full URL to the issue that you have been assigned, for example
+ +
++ Thank you. +
++ Looks like you are trying to use the example above. Be sure to use the URL for your actual issue. +
++ 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. +
++ Assigning issues can help prevent people from duplicating work. +
++ Allow a developer to "hold on" to an issue, even if they are not currently working on it. +
++ 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. +
++ Assigning issues could work like creating a ToDo list for core project contributors. +
++ Think about this from both the individual developer's perspective and from the overall project's perspective. +
+
- 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
+ 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
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.
-
- If you have questions about the GitKit, need help getting setup to use it in a class, or have feedback for us, please
- Fork the upstream `GitKit-FarmData2` repository into their own GitHub space. + Fork the upstream of the GitKit FarmData2 repository into their own GitHub space.
- Clone their fork (i.e. their origin) of the `GitKit-FarmData2` repository. + Clone their fork (i.e. their origin) of the GitKit FarmData2 repository.
- If time permits, a live demo looking at the issue tracker in the upstream GitKit-FarmData2 repository, pointing out the "Round 1" label and how to tell if an issue has been assigned. Note that several of the issues will have been pre-assigned to whomever deployed the kit. + If time permits, a live demo looking at the issue tracker in the upstream GitKit FarmData2 repository, pointing out the "Round 1" label and how to tell if an issue has been assigned. Note that several of the issues will have been pre-assigned to whomever deployed the kit.
@@ -174,35 +174,32 @@
-
-
+
- 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 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.
-
- 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. + 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.
-
- 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. + 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.
- Some students will attempt to clone the project that they select while they are inside the GitKit-FarmData2 repository that they already cloned. If they do attempt this the Kit-tty should intervene, prevent the action and respond with a helpful message. + Some students will attempt to clone the project that they select while they are inside the directory containing their local GitKit FarmData2 repository. If they do attempt this the Kit-tty should intervene, prevent the action and respond with a helpful message.
- For help with GitKit, you can
- Note that you are currently viewing the
-
- 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
- Click to
- 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. + 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.
- 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
- Read
- Consider doing the GitKit for yourself as described in
- Follow the steps in
- Refer to
- The GitKit content is broken into 4 chapters (See
@@ -167,18 +159,18 @@
- 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. + Students complete the hands-on activities contained in each chapters of this text as 2-3 hours of homework or during assigned lab periods.
- 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. + 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:
- 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: + Limited Coverage: The first two GitKit topics form a cohesive unit and can be completed without continuing onto the final two 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. + 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.
- 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.
- 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. + The content of the GitKit is broken into the chapters below.
@@ -235,7 +227,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.
- Provides practice with understanding merge conflicts, merging main into a feature branch, using a graphical merge tool and updating a pull request.
+ Provides practice with understanding merge conflicts, merging
- The GitKit provides a cloud based development environment that students use to complete the hands-on GitKit activities. This development environment is called a
- 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. - -
-
-
- 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
- You are currently viewing the
-
- 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. + 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.
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
- merge a feature branch into main (instead of vice versa).
+ merge a feature branch into
- 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!" + 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!"
- Current development work on FarmData2 is occurring in the
- The GitKit text is an e-text that is available on
@@ -438,30 +389,23 @@
- Note that you are currently viewing the
-
You can either
+ The course pack includes a
- The course pack includes a
- 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
- Review the Slide Notes for the chapter. + Review the Slide Notes for the chapter for helpful instructor tips.
- Click this link to
+ Click the green "Create new codespace" button. +
+
+ Creating the codespace requires a few minutes. When it is complete will see the prompt in
- 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. + The GitHub username or the name of a GitHub organization to which you have write permission as the location to deploy the upstream repository.
- 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 to the following that shows the URL of your deployed GitKit FarmData2 repository.
+ When the deployer completes it will generate output similar
-
Copy the URL of the repository and distribute it to your students using e-mail, LMS or whatever means is convenient for you.
@@ -642,7 +616,7 @@ https://github.com/someLocation/GitKit-FarmData2
- 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
The following links provide easy access to the chapters with the hands-on exercises, the presentation slides for each chapter and a set of instructor notes for each chapter.
The
- For any kind of question, difficulty, suggestion, or suspected bug,
@@ -741,7 +717,7 @@ https://github.com/someLocation/GitKit-FarmData2
- Active work on the deployer and the KitClients takes place in the
- 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
- 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. + 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.
The exercises in this chapter have the students perform the following major tasks: @@ -32,7 +32,7 @@
- Use the VS Code merge tool to resolve the conflict. + Use VS Code's basic merge tool to resolve the conflict.
- 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. + 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.
+ 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. +
+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. @@ -187,37 +195,30 @@
-
- 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. + 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.
-
- 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 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.
+ 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.
-
- 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.
+ These students should follow the instructions given in 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.
-
diff --git a/source/ch-instructor-guide/sec-instructor-synchronization.ptx b/source/ch-instructor-guide/sec-instructor-synchronization.ptx index 6c83aed..68ed505 100644 --- a/source/ch-instructor-guide/sec-instructor-synchronization.ptx +++ b/source/ch-instructor-guide/sec-instructor-synchronization.ptx @@ -142,7 +142,7 @@ Note
- 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. + 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.
-
-
+
- It is a good idea to check here that the student's upstream remote points to the correct GitKit-FarmData2 repository. The Kit-tty should have caught this error and directed students on the correct way to set the upstream remote. However, some students have still managed to set their upstream to point to their origin or to the live FarmData2 repository. + It is a good idea to check here that the student's upstream remote points to the correct GitKit FarmData2 repository. The Kit-tty should have caught this error and directed students on the correct way to set the upstream remote. However, some students have still managed to set their upstream to point to their origin or to the live FarmData2 repository.
-
diff --git a/source/ch-instructor-guide/sec-instructor-upstreaming.ptx b/source/ch-instructor-guide/sec-instructor-upstreaming.ptx index 7747b42..10efffe 100644 --- a/source/ch-instructor-guide/sec-instructor-upstreaming.ptx +++ b/source/ch-instructor-guide/sec-instructor-upstreaming.ptx @@ -7,7 +7,7 @@
- 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
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
diff --git a/source/ch-merge-conflicts/ch-merge-conflicts.ptx b/source/ch-merge-conflicts/ch-merge-conflicts.ptx
index 3185d92..4bbf864 100644
--- a/source/ch-merge-conflicts/ch-merge-conflicts.ptx
+++ b/source/ch-merge-conflicts/ch-merge-conflicts.ptx
@@ -8,13 +8,14 @@
- 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
diff --git a/source/ch-merge-conflicts/sec-confirming-the-merge-conflict.ptx b/source/ch-merge-conflicts/sec-confirming-the-merge-conflict.ptx
new file mode 100644
index 0000000..99f3471
--- /dev/null
+++ b/source/ch-merge-conflicts/sec-confirming-the-merge-conflict.ptx
@@ -0,0 +1,329 @@
+
+
+
+ While you were working on your Round2 issue your instructor, playing the role of a maintainer, merged some changes into the upstream
+
+ 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
+ The activities in the remainder of this section will reinforce your understanding of how the conflict arose, confirm that your
+ Complete the following tasks that ask about the current situation, which is illustrated in
+ Which of the following commits (i.e. which color) in
+ Dark Blue
+
+ Correct.
+
+ Lime Green
+
+ The lime green commit is not in the upstream
+ Brown
+
+ The brown commit is not in the upstream
+ Light Blue
+
+ The light blue commit was added to the upstream
+ Yellow
+
+ The yellow commit was added to the upstream
+ Look at which commits are in upstream
+ Which of the following commits (i.e. which color) in
+ Dark Blue
+
+ The dark blue commit is already in the upstream
+ 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
+ Yellow
+
+ The yellow commit is already in the upstream
+ 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
+ Visit the
+ 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.
+
+
+ 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
+ When would you have to create your feature branch for the upstream
- 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:
-
-
-
+ To do the extra practice you'll need to have your development environment running.
+
+ Click here to
- The
- I have fetched the branch -
-- I have not fetched the branch -
-
- Do not make continue until you have the
+ 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
+ Ensure that you are in the directory for your GitKit FarmData2 repository. Then use the following command to get this feature branch from the upstream into your local repo:
+ Run the
+ Which of the following branches are listed? +
+
+
+ Correct. +
+
+
+ Correct. +
+
+
+ Are you sure this branch exists? +
+
+
+ Are you sure this branch exists? +
+
+ If you do not see the
+ At this point you should think of the
- Make the
+
+
+
+
+ Review
- The
- I have resolved the conflicts -
-
+ Execute the commands you selected in
+ In which file were the merge conflicts created? +
+
+
+ Correct. +
+
+
+ Check the hint. +
+
+
+ Check the hint. +
+
+
+ Check the hint. +
+
+
+ Check the hint. +
+
+ The file containing the conflicts should have opened in the editor automatically when you performed the
- I have not resolved the conflicts -
-- Do not make continue until you resolve 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
- 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. + Choose and order the steps below to describe the sequence of things that you will do to resolve the merge conflicts that were created.
+ Edit the merge conflict information. +
+
+
+
+
+ Create a pull request to the upstream. +
+
- Push the
+
+ Thank you. +
+
+ Be sure that your URL is from your pull request to the upstream repository for your course. It should have the format
+ Review sections
Match the tasks on the right with the appropriate git command listed on the left. The <...> notation indicates parameters that are needed to customize each use.
-- Note that the tasks listed are in approximately the same order as they appear in the sections of this chapter. -
-+ Note that the tasks listed are in approximately the same order as they appear in the sections of this chapter. +
++ Note that the tasks listed are in approximately the same order as they appear in the sections of this chapter. +
+
- 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
-
-
+
- If you are going to merge the changes from the
- The
+
+ When two branches are merged the branch containing the changes to be merged is called the
+
+ When the changes in the source and target branches have been successfully merged a
- To use the
- What were the commands you used? And their output? You can copy your work into the provided textbox. + Read the introduction to this section.
- -
- Use the
+ Dark blue with a brown ring. +
+
+ Correct. The dark blue commit in
+ Dark blue +
+
+ The dark blue commit is a commit in the
+ Brown +
+
+ The brown commit is a commit in the
+ Pink +
+
+ The pink commit is a commit in the
+ Light blue with a white ring. +
+
+ The light blue with a white ring is a merge commit in
- What were the commands you used? And their output? You can copy your work into the provided textbox.
+ Read the introduction to this section and examine
- The output from
+ The command
- In which file is the conflict located?
+ Imagine that the
+
+
+
+
+ To merge the
+ Use the
+ Use the
- Use the
- 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
+ The command you want is in
+ Review what you did in
- Answer the following questions by copying the appropriate portion of the output that you gave in
- What is the part of the output that is the Best Common Ancestor?
+ Run your
- What is the part of the output that shows the changes that the maintainers merged into the
+ 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
+ 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. +
+ Something else happened. +
+
+ Double check that your
- What is the part of the output that shows your changes?
+ Which of the following things also happened when you ran your
+ The terminal displays a message indicating that there is a "Merge conflict in README.md." +
++ Correct. +
+
+ The
+ 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
- Undo the merge that you started in
- Briefly explain how you can tell from the output of
- 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.
+ This section will walk you through the process of resolving the merge conflict. In
+ After completing
+ If you are not seeing the
- Ensure that you are on your feature branch. Then issue the command to merge the
- As you have seen when a merge fails
-
- The KitClient you are using has been configured so that the
- The KitClient you are using has configured VS Code's Merge Editor as a mergetool. -
- -
- The
- To open a file in VS Code's Merge Editor: -
-
- Issue the
+ Match the terms below to the descriptions based upon what is displayed in the editor. +
++ Match the terms below to the descriptions based upon what is displayed in the editor. +
+
+ Recall that the merge conflict that you are seeing arose because your feature branch and the upstream
+ 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
+
- When VS Code's Merge Editor is first opened, it will open a window containing three panes (
-
- Open the conflicted file, and click the "Resolve in Merge Editor" (
-
+ Only the changes from the feature branch remain. +
++ Correct. +
+
+ Only the changes from the
+ Check the editor contents after you click "Accept Current Change". +
+
+ The changes from the
+ 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". +
+
- When VS Code's Merge Editor is first opened, it will open a window containing three panes (
+ 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. +
++ 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. +
+
-
+ Which of the following appear in the output of the
+ 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
+ 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? +
+
+
+ Correct. +
+
+
+ Close. Check the output again. +
+
+
+ Check the output again. +
+
+
+ Check the output again. +
+
+ Run the
+ Feel free to try out the
- 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. -
-
- Use the "…" menu in the upper right of the merge tool window and check the "" and "" options as shown in
-
+
+
+
+
- With these options enabled, the merge tool window should now contain 4 panes (
-
- Do you have your merge tool window showing four panes and their content?
+ What does
+ use "git commit" to conclude merge +
+
+ Correct. You already knew that, but its good to know that
+ use "git pull" to conclude merge +
+
+
+ use "git push" to conclude merge +
+
+
+ use "git restore" to conclude merge +
+
+
- Do not make changes until you have your merge tool set up.
+ Run the
- Using your answer to
- 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: -
- Copy your final merged result here. -
-- Save your changes in the merge tool and close the merge tool window. -
-
- Then issue a
- 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.
+ What does
+ 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 +
+
- Briefly explain why the output you see in
- From
- 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. -
-
-
-
+
- In class we saw that the maintainers had merged some changes into the upstream
- 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
- 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
- Which of the commits (i.e. which colors) in
+ Click here to
+ 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:
+ +- Dark Blue -
-
- Lime Green
+ Assuming your feature branch is currently the active branch, arrange the the commands below into the order they would be used to synchronize your
+
+
+
+
+
- Brown
+ Review
- Green
+ Run the commands that you identified in
- Look at which commits are new in upstream that are not part of the local repository's
- Visit the main page for your
- How many commits behind the upstream are you? -
-
- Now find your pull request in the
- 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
- What are the commands you used?
+ Let's, confirm that your origin
- Check that you are now synchronized: -
- Check that the
- Use
- If the
+ 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
- The exercises in this section provide practice in identifying merge conflicts and their resolutions. + The exercises in this section provide practice in identifying merge conflicts and resolving them.
-
-
- Consider the merge shown in
+ The current
+
- Study the program in the
- Highlight (by clicking, or by circling) all of the lines that are non-conflicting changes in the feature branch or the
- Merge conflicts occur when both source branches change the same line. -
-+ Find the average of a list of numbers. +
++ Correct. +
++ Find the total of a list of numbers. +
+
+ Consider the last line in the
+ 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. +
+
- Highlight (by clicking, or by circling) all of the lines that are conflicting changes in the feature branch and the
- Merge conflicts occur when both source branches change the same line. -
-
+ Select the statement below that best describes a
+ A non-conflicting change occurs when a part of the code changes in the feature branch or in the
+ Correct. +
+
+ A non-conflicting change occurs when a part of the code changes in both the feature branch and the
+ 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
+ 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
- Would the feature branch in
+ Select the statement below that best describes a
+ A conflicting change occurs when a part of the code changes in the feature branch or in the
+ 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
+ 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
+ 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
- Highlight the correct lines that give a Merged Result of the program in
+ Highlight (by clicking) all of the lines in the
+ Non-conflicting changes occur when a part of the code changes in either the feature branch or the
+ Highlight by clicking all of the lines in the
+ Conflicting changes occur when the same part of the code is changed both the feature branch and the
-
-
+ Select the statement below that best describes why the feature branch in
+ The feature branch cannot be merged automatically because there is a conflicting change. +
+
+ Correct. The last line contains changes in both
+ The feature branch can be merged automatically because 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
+ Close. What type of changes prevent automatic merges? +
+
+ Use the table below to indicate how the feature branch would be merged into the
+ Select all of the non-conflicting changes and choose the conflicting change that ensures that the program will work correctly. +
+
- Now consider the merge shown in
+ As in the previous example, the right-hand panel shows commits that the maintainers have merged into the
+
- Study the program in the
- Highlight (by clicking, or by circling) all of the lines that are non-conflicting changes in the feature branch or the
- Merge conflicts occur when the feature,
- Highlight (by clicking, or by circling) all of the lines that are conflicting changes in the feature branch and the
- Merge conflicts occur when the feature,
+ Study the program in
+ Compute the area of a circle. +
++ Correct. +
++ Find the circumference of a circle. +
+
+ Close. Notice the use of
+ Compute the volume of a sphere. +
+
+ Close, but that formula would use
+ None of these. +
++ One of the other answers is correct. +
+
+ The
- Would the feature branch in
+ The questions below will now ask you to identify the non-conflicting and conflicting changes that exist in the merge from
- Give the Merged Result to show the result of an automatic merge of the feature and
+ Highlight (by clicking) all of the lines in the
+ Non-conflicting changes occur when a part of the code changes in either the feature branch or the
- Look carefully at your result in
+ Highlight (by clicking) all of the lines (if any) in the
+ Conflicting changes occur when the same part of the code is changed both the feature branch and the
- When a merge can be completed automatically, does it guarantee that the Merged Result will be correct?. -
-
+ Select the statement below that best describes why the feature branch in
+ The feature branch can be merged automatically because 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
+ What type of changes prevent automatic merges? +
+
+ Imagine that the non-conflicting changes you identified in
+ 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
+ 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
+ Look closely at how the
+ When both the feature branch and the
+ Consider what happened with
- 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
- Push your modified feature branch to your
- Now visit the upstream repo and find your pull request. You should see that it can now be merged automatically.
+ Give the command that will push your modified feature branch to your
+
++ 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
+ Review the
- If your PR cannot be merged automatically you have not correctly resolved the merge conflict; return to
- !!Give a screenshot from your pull request showing that it can now be merged automatically. +
- -
+ Use your command from
+ 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 the URL of your pull request. + 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!
-
+ Visit the
+ 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. +
+ 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 focused on how to keep your local and origin repositories synchronized with the project’s upstream repo.
+ This topic focuses 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
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
- Ensure that you are in the GitKit-FarmData2 directory then use the following commands: + Ensure that you are in the directory for your local clone of your GitKit FarmData2 repository then use the following commands:
+
-
- The first step is to delete the feature branch from your local repository. - This exercise will walk you through that process. + 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.
- It is not possible to delete the active branch.
- So, if you have not already, switch from your feature branch to the
- Which command did you type to list the local branches? -
-
-
- The
-
+
+
+
+
+
- The
-
- The
-
+
+
+
+
+ It is not possible to tell that
- Correct! The
- Refer back to the section on switching branches
- From the output provided by
+ The command
+ Give a command that will delete your feature branch. +
+ ++ +
++ Thank you. +
+
+ Please give the full
+ Run your command from
+ 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
+ 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. +
++ 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. +
+- It has an * next to it. -
-
+ First, let's confirm that your feature branch still exists in your origin. How can you check if your feature branch exists in your
+ Go to the GitHub origin repo and click on the branches button. +
++ Correct! +
+
+ Use the
+ This command shows the local branches. +
+
+ Use the
+ 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
+
+ Give a command that will delete your feature branch from your origin repository. +
++ +
++ Thank you. +
+
+ Please give the full
- It appears in green.
+ Run your command from
- It appears in bold. + Which of the following looks most similar to the output you see?
+ [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 italics.
+ Examine the output of your
- It is not possible to tell the active branch based upon the output provided.
+ Use your browser as you did in
- Refer back to the section on switching branches
- The command
- How can you check if your branch was deleted? Be sure to check that it was deleted.
- If not return to
- In the previous exercise you deleted your feature branch from your local repository. -
-
- This feature branch no longer exists in your
- You have only deleted the feature branch in your local repository. It still exists in your
- 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
- You can delete your feature branch from your origin repo using the git CLI. - The command -
- -
-
- 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
- Match the tasks on the right with the appropriate git command listed on the left. -
-- 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. +
++ Refer back to the sections in this chapter to see what each command does. +
++ 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.
- 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!
+ 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
- The issue tracker in the upstream FarmData2 repository being used for these tasks. + 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.
- 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?
+ The steps you carried out in
- 4 -
-- 6 -
-- 35 -
-- 40 -
-+ 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 +
+- ADD HINT HERE + Think about the full process that you worked through from claiming your Round1 issue through making a pull request for your changes.
- 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. -
-- 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 + Now it is time to find a new issue to work on.
-- 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 -
-- HINT HERE. -
-
- Use the process that you outlined in
- 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. -
-
- Which of the following Git commands did you use for the steps indicated below.
- The command references that you created in
- Note that the tasks listed are in approximately the same order as they appear in the sections of this chapter. -
-- 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 doesn't provide enough information. - What is issue 37? -
-- adding-link -
-- This branch name is too generic. -
-- adding-nsf-link-acknowledgement -
-- Correct! This branch name describes the work to be done in the branch. -
-- nsf-acknowledgement -
-- This branch name doesn't specify what is being done with regard to the NSF acknowledgement. -
-
- Refer back to the section on creating branches
- 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? + How many issues have the Round2 tag?
- Added the URL for GNOME to the acknowledgements section of the REAMDE file. + 4
- Correct! This commit message briefly but completing describes the change made. + Correct.
- Added URL. + 6
- This commit message doesn't provide enough information about the URL added. + Be sure you have selected the "Round2" label.
- Updated README. + 35
- This commit message doesn't provide enough information about what has been changed in the README file. + Be sure you have selected the "Round2" label.
- Fixed typo. + 39
- This commit message is too generic and does not describe the change for this issue. + Be sure you have selected the "Round2" label.
- Refer back to the section on creating branches
- Give the following information about your pull request.
- Hint: You can revisit the prior sections to refresh your memory on the terms
- The number of your PR + 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.
-- Full URL of your PR + 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 as it was in Round1. + Try to spread out across the issues so that multiple people have commented that they are working on each one.
-- Base Repository URL + Give the number of the issue you chose.
-- Head Repository URL +
+ Thank you for selecting a Round2 issue. +
++ Make sure that your issue is labeled as a Round2 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. +
+
+ The command reference that you created in
+ When creating branches you should always use a 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. +
++ add-link-to-nsf-award-in-acknowledgements-section +
++ This branch name is very descriptive but seems excessively long. Can you imagine typing that over and over again? +
+
+ Refer back to
+ When writing commit messages for the
+ 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
+ Now that you have fixed the issue and pushed your feature branch, the last thing to do is to make a pull request. +
+- Base Branch + Make a pull request for your feature branch to the upstream repository for your course.
-- Compare Branch + Enter the full URL of your PR below.
-- The line number of the README.md file that you changed. - Hint: use the diff you saw in the prior chapter. +
- 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. -
-+ 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
+ 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
+ Correct. While your PR changes the same lines of the
+ GitHub will indicate that your PR cannot be merged automatically because it contains a conflict with the upstream
+ While your PR changes the same lines of the
+ 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
+ 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
+ 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
+ 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
+ Your PR will have changed the same lines in
+ GitHub will indicate that your PR cannot be merged automatically because it contains a conflict with the upstream
+ Correct. A PR for the Round2 issue you were working on has been merged into the upstream
+ 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
+ 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
+ Visit your PR in the upstream repo and see what GitHub tells you about whether it can be merged or not. +
+
+ As you saw in
Now, recall that upstream
+ 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
+ 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
+
+
+ This section walks you through the process of pulling changes from the upstream
- To pull the changes from the upstream main branch into your local repo you first need to ensure that
-
- The
-
- The
-
- Correct! The
-
- The
- Refer back to the section in the previous chapter on switching branches
+ Which command can you use to check if
+
+ The
+
+ The
+
+ Correct! The
+
+ The
+ Refer to
+ If your active branch is not
+
+ The
+
+ The
+
+ The
+
+ Correct! The
+ 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
- If your active branch in not the
-
- The
-
- The
-
- The
-
- Correct! The
- Refer back to the section in the previous chapter on switching branches
- The command +
- ++ Correct. +
+
+ Please give the full
-
- 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
- Examine the output from
@@ -208,7 +239,6 @@
@@ -216,7 +246,6 @@
@@ -224,7 +253,6 @@
@@ -233,13 +261,11 @@
Make sure you look at all of the lines of output and the color coding of the lines.
- 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.
+ Your local
Recall that you previously used the
+
-
- command to push your feature branch from your local repo to your origin repo.
- Use the
- Examine the output from
- 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?
+ Please give the full
- 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. -
-
- Only look at the last two lines, the one that starts with "To" and the one that starts with a SHA code.
+ Run the
- 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:
+ Examine the output from your
+ If you don't see information about deltas and objects but see an error message instead, revisit
+ 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:
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
-
-
- Answer the following questions using
- Which commits (give the colors) were merged into the upstream
- Red -
-- Yellow -
-- Green -
-- Blue -
-- Pink -
-- Lime Green -
-
- Look at which commits are new in upstream that are not part of the local repository's
- Which of the commits did the managers merge from the contributor's pull request? -
-- Red -
-
- Red was in
- Yellow -
-
- Yellow was in
- Green -
-
- Green was in
- 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
- Use your browser to visit your origin repo on GitHub and ensure that the
- If you do not see a message that your main branch is behind the upstream
+
+ Answer the following questions using
+ Which commits (give the colors) were merged into the upstream
+ Red +
++ Yellow +
++ Green +
++ Blue +
++ Pink +
++ Lime Green +
+
+ Look at which commits are in the upstream
+ Which of the commits did the managers merge from the contributor's pull request? +
++ Red +
+
+ Red was in
+ Yellow +
+
+ Yellow was in
+ Green +
+
+ Green was in
+ 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
+ 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
+ The pink commit is part of the upstream
+ 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. +
+
- Briefly explain what has happened that caused your origin’s
+ Use your browser to visit your origin repo on GitHub and ensure that the
+ Which of the following messages do you see that indicates that your origin's main branch is behind the upstream
+ This branch is x commits behind
+ Correct! Being behind means that the upstream
+ This branch is x commits ahead of
+ Being ahead means that your origin
+
+ I do not see either of those messages. +
+
+ Seeing no message indicates that origin
+
+ 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
+ Another contributor has made a pull request to the upstream for changes that they have made. +
+
+ In order for this to affect the upstream
+ 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
+ You have committed changes to your local
+ Here your origin
+ A maintainer merged a pull request and you have not yet updated your origin's
+ Correct. The manager merging the pull request will add changes to the upstream
+ Think about how changes may been added to the upstream
- Like the last activity, you will be working within the KitClient for this activity. -
- -
+ Before you will be able to pull changes from the upstream your local repository will need to know where to find the upstream repository.
+ In earlier figures (e.g.
- Restart your KitClient based on the instructions in
+ Like prior chapters, you will be working within your development environment for this activity. +
+
- The
- How is the origin remote indicated in
+ A
+ A
+ The
+ Be sure that you are in the directory containing your local repository and run the
+ Examine the output of the
- It is labeled as "origin". + Where does the URL associated with the origin remote point?
+ 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. +
+- Correct! The diagram shows your origin remote on the top left side with the label "origin". + 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.
-- It is labeled as "upstream". + Where does the URL associated with the upstream remote point?
- It is labeled as "local". -
-+ 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. +
+- It is labeled as "feature branch". + 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.
-
- When you issued the
- Confirm that
+ The remotes you just examined with
+ How is the origin Git remote associated with your local repository represented in the figure? +
++ The dotted orange arrow on the left that points from your local repository to the origin. +
++ Correct. +
++ The dotted orange arrow on the right that points from your local repository to the upstream. +
++ The arrow on the right represents a Git remote associated with your local repository, but it is not the origin. +
++ 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. +
++ 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 origin Git remote will be associated with your local repo and will indicate where the origin repository is located. +
++ How is the upstream Git remote represented associated with your local repo represented in the figure? +
++ 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 a git remote associated with your local repository, but it is not the upstream. +
++ 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. +
++ 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. +
+
+ As you saw in
+ Not all development environments are able to automatically set the upstream remote when you open your local repository. The exercises in this section will walk you through how you can manually set the upstream remote if you need to. +
+
- 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
- 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:
-
- Use the above command to create a remote named
- Use the
- 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". -
-
+ 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. +
+
- When you issued the
- 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
+ Note that if you are using a development environment that does not automatically set the upstream remote for you, you will still only need to set it once. Once the upstream remote is set for a repository you will be able to pull from the upstream repo as often as is necessary. +
++ It is also worth mention that there is nothing particularly special about the names of the remotes. The names origin and upstream are used by convention by most developers. However, you could name your remotes anything you like and they would still work. +
-- 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
+ 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. +
++ 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
+ Write a
+ +
++ Thank you. + Your command is in the proper format, please make sure the commit message is meaningful. +
+- Provide the command you entered. + Try using a longer commit message to be more descriptive.
- -+ Try using a more concise commit message. +
++ Double check the format of your command. +
+
+ Use the
+ 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
+ You have staged and committed all modified files. +
+How do you know your changes have been committed?
+ The
+ The
+ The
+ The
+ There should be no modified files that are still staged and the
Use the
+ 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. +
+
+
+
+
+ Correct! +
++ To change the active branch you need to switch to it. +
+
The output of the
+ What branch are you on, the
- Briefly explain how you know.
+ The commit is not shown in the
+ You are on the
+ Correct! +
+
+ You are on the feature branch and the commit is on the
+ You should be on the
+ The
+ The
+ It only shows the first commit made, not every commit. +
+
+ The
+ Commits are specific to branches. + You must be on the proper branch to see a commit. +
+
+
+
- The
- What part of the output tells you which branch is currently active in your repository? + If you want to create a new feature branch named fixTypoInName, which command should you use?
- The branch name is displayed in the first line after "On branch".
+
- Correct! The first line specifies the current branch. + Correct!
- 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 command should not contain < >.
- The branch name is not displayed in the output from this git command.
+
- Look again, the active branch is listed.
+ The command is missing
- 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.
+ The command is missing
- Look at the first line of the output from the
- 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”?
+ Adapt the command from
+ What output was produced when you typed the
+ 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. +
+- 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! + Look back at the format of the command and make sure you type it correctly.
-
- The
-
- 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. -
+ Type
- Use the
- Creating a new branch with the
+
-
+ Correct! +
+
+
+ Correct! +
+
+
+
+
+ The branch name should not have < >. +
+
- After you create a branch what needs to be done to make it active?
+ 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
- How can you tell from the output in
+ 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. +
+
-
-
- Copy the URLs from the gray bar into the textboxes below. -
-- Base Repository -
-- Head Repository -
-
- The terms “Base Repository” and “Head Repository” in
The base is where you want your changes merged into. - The head is where your changes are being pulled from. + The compare is where your changes are being pulled from.
- The #123 part of the line should automatically become a link to the ticket. + The #123 part of the line should automatically become a link to the issue. If it does not, check to be sure you have entered the information exactly as shown above.
@@ -219,7 +189,7 @@
- Check that status of your PR and confirm that it can be merged automatically.
+ Check the 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
- +
+ Thank you. +
++ Double check the URL of your pull request to ensure that it is in the upstream for your course and is correct. +
++ 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:
@@ -289,13 +280,8 @@ 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. -- Briefly describe how the diff indicates the changes that you made. + Which of the following describes how the diff indicates the changes that you made?
+ Correct! You can see the changes by comparing the red and green lines. +
++ The red only shows what is being deleted. +
++ The green only shows what is being inserted. +
++ 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.
@@ -19,42 +20,80 @@- Provide a link to the issue that you claimed in the issue tracker. + Provide the URL 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 that you have been assigned. +
+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. +
-- In which file will you be making changes to address your issue? Hint: Look at the text of your issue in the issue tracker. -
-+ +
++ Thank you. +
+
- Use a text editor to modify the file you identified in
+ 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
+ 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. +
+@@ -80,20 +119,24 @@
- 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.
+ 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
How many files are not staged?
@@ -125,7 +168,7 @@- Correct! The file you changes has been modified but not staged yet. + Correct! The file you changed has been modified but not staged yet.
- How many files are added to the commit? + How many files will be committed?
- Unless you already issued the
The
- How is the change that you made indicated in the output from
- 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. -
-
+ How is the change that you made indicated in the output from
- 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 KitClient for this exercise. + Like in the previous chapter, you will be working within the development environment for this exercise. +
+ +
+
+
+ Let's explore this state just a little before making the changes that address the issue that you have claimed. +
+ +
+
-
-
- Let's explore this state just a little before making the changes that address the issue that you have claimed. -
++
+
-
+ Click here to
- Restart your KitClient based on the instructions in
- The
+ Which of the following commands will provide the four most recent commits? +
+
- Ensure that you are in your cloned repo (i.e.
- the GitKit-FarmData2 directory is your working directory).
- Then use the
- 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
+
- Use the output from the
+ This will provide information about the 10 most recent commits, not just the first four. +
+
+
+ This is not the proper format, a symbol is missing before the 4. +
+
+
+ Correct! +
+
+
+ The symbol before the 4 is incorrect. +
+
+ Refer back to the beginning of this subsection for specifics about the
+ Ensure that you are in the directory containing your cloned GitKit FarmData2 repository (use the
+ 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
+ Paste the output of the
+ Use the output from the
@@ -138,11 +256,13 @@
- 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.
@@ -150,6 +270,7 @@
- There is a more recent commit. + There is a more recent commit.
@@ -222,6 +344,7 @@
- What is the purpose of the most recent commit by shes-dev? + What is the purpose of the most recent commit by Elad Sheskin (username: shes-dev)?
+ The
+ 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
+ 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
+ Correct! +
+
+ It means that the origin
+ Think about what is being compared in that statement. +
+
+ It means that your branch contains all of the issues in the origin
+ Issues are not part of a branch. +
+
+ It means that the origin
+ Issues are not part of a branch. +
+
+ Think about what could be "out of date".
+ What differences might there be between the origin
+ 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
+ This statement is referring to your local branch, not origin
+ When would you have something to commit? This is the opposite of that! +
++ In the next section you will create a feature branch. +
++ 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. +
+
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 4d2e46c..c1e5214 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,13 +31,15 @@
- The
How many branches are in your local repository?
Look again, you should see more than just the
- 1 -
- Look again, you should see more than just the
- 2 -
- Correct! Your local repository will have both the
- 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,
- 1 -
- Look again, your
- 2 -
- Look again, your
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
-
- Before you will be able to push your feature branch to GitHub you will have to get a
+ You created a branch in your local repository but it does not appear in the origin repository yet. +
+- 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. -
++ Correct! +
+
- Follow GitHub's instructions for creating a (classic) personal access token:
+ You created a branch in the origin repository but it does not appear in your local repository. +
+- When doing so be sure to: -
- Choose “repo” for the “scopes and permissions.” + Your branch is in your local repository, not the origin repository.
-- 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. + Someone else created a branch 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
+ 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. +
++ Someone else created a branch in their local repository and it appears in the origin 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. +
++ 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? +
+
- The
- Use a command that will push your feature branch from your local repository to your origin repository 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
- 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 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.
-+ 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. +
+
- The output from
- The
- Use a command that will push your feature branch from your local repo to your origin repo on GitHub. + How can you tell your branch was pushed?
+- Note: You can use the name of the remote repo, so you do not need to use the full URL. -
-
- When you attempted to push in
+ 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
+ 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. +
++ Pushing a branch will not create a pull request. +
+- 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. + There are multiple ways you can tell that your branch has been pushed by looking at the origin repository on GitHub.
-- The exercises in this section will walk you through staging the changes you made to your Local Files. + The exercises in this section will walk you through staging the changes you made to your Local Files. +
+ +
+ The
- The
+ Write a
+ Enter the command you wrote below. +
- Provide the command you entered. +
-+ Thank you. +
++ Are you sure that is the file that the issue asked you to edit? +
+
+ Check the format of your
+ Check your issue again to see which file you should have edited. +
+
- Note that git also has a
- Now run the
@@ -88,7 +112,7 @@
- Correct! After issuing the
- Once you have issued the
- Staged means a file has been modified and added to the commit.
+ Staged means a file has been modified and will be added to the commit.
How many files are listed as ready to be committed?
@@ -212,10 +235,98 @@
- Staged means a file has been modified and added to the commit.
+ Staged means a file has been modified and will be added to the commit.
+ Run the
+ 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
+ It shows the code I added in green. +
+
+ If you are seeing code changes it means either you made additional changes after the
+ It shows the code I deleted in red. +
+
+ If you are seeing code changes it means either you made additional changes after the
+ The
+ The
+ Note that git also has a
+ Figure
+
- As you saw in the previous section, the
- What command will change your active branch to the new feature branch that you created in the previous section?
+ Type
- Use the
+ Switched to branch '<name>' +
+
- Figure
-
+ Correct! +
+
- You can also switch branches using the
+ Switched to branch 'main' +
+
+ You were on
+ error: Your local changes to the following files would be overwritten by checkout: ... +
+ ++ Aborting +
++ You should not have made any changes so far. +
++ fatal: invlalid reference: <name> +
+
+ You probably typed the branch name incorrectly.
+ Run
- Issue the
-
+
+ Correct! +
+
+
+ Correct! +
+
+
+
+
+ When
- How do you know that
- 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
+
+ Correct! +
+
+
+ This will try to create a new branch named
+
+
+
+
- How do you know that your feature branch is the active branch? + Refer back to how you made your feature branch the active branch.
-
+ Type the command from
+ 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. +
+
+
+
+
+
+
+ Think about how you make a branch active and then verify it. +
+
+ Use the commands from