- The exercises in this chapter focus on FOSS communities. They explore what they are, how they are organized, the principles on which they operate and the roles that the community members take on. They also begin to look at some of the tools and processes that these communities use to support those principles and coordinate their work. You will see how git and GitHub work together to allow FOSS communities to share their work and to collaborate. In particular, you will create a fork and clone, and see how they make it possible for a diverse and distributed group of contributors to work asynchronously and to contribute useful changes back to the upstream. + The exercises in this chapter focus on FOSS communities. They explore what they are, how they are organized, the principles on which they operate and the roles that the community members take on. They also begin to look at some of the tools and processes that these communities use to support those principles and coordinate their work. You will see how Git and GitHub work together to allow FOSS communities to share their work and to collaborate. In particular, you will create a fork and clone, and see how they make it possible for a diverse and distributed group of contributors to work asynchronously and to contribute useful changes back to the upstream.
- In this and the next several chapters you will use a copy of the FarmData2 project repository to gain hands-on experience using use git and GitHub. This experience will strengthen your understanding of git, GitHub and FOSS communities. + In this and the next several chapters you will use a copy of the FarmData2 project repository to gain hands-on experience using use Git and GitHub. This experience will strengthen your understanding of Git, GitHub and FOSS communities.
diff --git a/source/ch-communities-and-collaboration/sec-basic-foss-workflow.ptx b/source/ch-communities-and-collaboration/sec-basic-foss-workflow.ptx
index a010fad..b318210 100644
--- a/source/ch-communities-and-collaboration/sec-basic-foss-workflow.ptx
+++ b/source/ch-communities-and-collaboration/sec-basic-foss-workflow.ptx
@@ -1,27 +1,28 @@
-
- Now that you have found an issue to work on, you will need to collaborate with the project community to fix that issue.
- Collaboration in FOSS communities follows patterns of behavior known as Now that you have found an issue to work on, you will need to collaborate with the project
+ community to fix that issue. Collaboration in FOSS communities follows patterns of behavior
+ known as
-
- The exercises in this section will help to familiarize you with the terminology and the process of this basic FOSS workflow.
-
- GitHub uses specific terminology to refer to the copies of the repository.
- Match the GitHub terminology on the left with the repository in
- Review the diagrams of the basic FOSS workflow from the in the class materials. -
- GitHub uses specific terminology to refer to the copies of the repository. Match the
+ GitHub terminology on the left with the repository in
-
+ Review the diagrams of the basic FOSS workflow from the in the class materials. +
+- Review the diagrams of the basic FOSS workflow from the in the class materials. -
-
+
- Drag the steps of the basic FOSS workflow into the order that they are likely to occur when working on a project. -
-- Fork -
-+ Review the diagrams of the basic FOSS workflow from the in the class materials. +
+- Clone -
-+ Drag the steps of the basic FOSS workflow into the order that they are likely to occur + when working on a project. +
++ Fork +
+- Edit -
-+ Clone +
+- Push -
-+ Edit +
+- Pull Request -
-+ Push +
+- Imagine the process you would go through when starting to work on a project, fixing a bug, and contributing your changes back to the main project. -
-+ Pull Request +
+ + + ++ Imagine the process you would go through when starting to work on a project, fixing a bug, + and contributing your changes back to the main project. +
+
- The clone URL should have the format
Be sure you are using your GitHub origin repository (see
- The
- It looks like you might be trying to clone the upstream repository instead of your origin. + It looks like you might be trying to clone the upstream repository instead of your fork/orign. Be sure you are using the URL of your origin repository.
- Be sure to replace the URL with the clone URL you found in
- 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? + Which command will show you the URL(s) of the remote(s) that Git knows about?
-
The
- This command will set the name associated with your changes in git. + This command will set the name associated with your changes in Git.
- This command will set the email associated with your changes in git. + This command will set the email associated with your changes in Git.
- Please give the full URL of your fork on GitHub. + Make sure you are giving the URL for your fork, not the project's upstream URL. + This URL should contain your GitHub username.
- Make sure you are giving the URL for your fork, not the project's upstream URL.
Review
- The origin URL should be the one from your git clone command. + The origin URL should be the one from your Git clone command.
Git and GitHub were designed to support the collaborative work of the FOSS communities that you learned about in class and in
Some of the key principles that guide FOSS communities are
+ If you would like you can review a discussion of these principles in the speaker notes in
+ Shared values +
++ It's not shared values. + Another principle is more closely related. Review the principles in The Open Source Way. +
++ Collaboration +
++ Working together to solve problems is at the heart of collaboration. +
++ Transparency +
++ It's not transparency. + Another principle is more closely related. Review the principles in The Open Source Way. +
++ Inclusivity +
++ It's not inclusivity. + Another principle is more closely related. Review the principles in The Open Source Way. +
++ Meritocracy +
++ It's not meritocracy. + Another principle is more closely related. Review the principles in The Open Source Way. +
++ Release early and often. +
++ It's not release early and often. + Another principle is more closely related. Review the principles in The Open Source Way. +
++ Shared values +
++ It's not shared values. + Another principle is more closely related. Review the principles in The Open Source Way. +
++ Collaboration +
++ It's not collaboration. + Another principle is more closely related. Review the principles in The Open Source Way. +
++ Transparency +
++ Sharing decisions and rationale with the community allows everyone to know how and why decisions are reached. +
++ Inclusivity +
++ Sharing decisions and rationale allows everyone in the community to feel included. +
++ Meritocracy +
++ It's not meritocracy. + Another principle is more closely related. Review the principles in The Open Source Way. +
++ Release early and often. +
++ It's not release early and often. + Another principle is more closely related. Review the principles in The Open Source Way. +
+@@ -93,24 +236,94 @@
+ Shared values +
++ The goals are shared if they take precedence over individual agendas. +
++ Collaboration +
++ Shared goals of the community invite collaboration. +
++ Transparency +
++ It's not transparency. + Another principle is more closely related. Review the principles in The Open Source Way. +
++ Inclusivity +
++ It's not inclusivity. + Another principle is more closely related. Review the principles in The Open Source Way. +
++ Meritocracy +
++ It's not meritocracy. + Another principle is more closely related. Review the principles in The Open Source Way. +
++ Release early and often. +
++ It's not release early and often. + Another principle is more closely related. Review the principles in The Open Source Way. +
++ Shared values +
++ It's not shared values. + Another principle is more closely related. Review the principles in The Open Source Way. +
++ Collaboration +
++ It's not collaboration. + Another principle is more closely related. Review the principles in The Open Source Way. +
++ Transparency +
++ It's not transparency. + Another principle is more closely related. Review the principles in The Open Source Way. +
++ Inclusivity +
++ Individuals feel included if their contributions are assessed on merit, not their own identity. +
++ Meritocracy +
++ Ideas and contributions should be assessed solely on merit. +
++ Release early and often. +
++ It's not release early and often. + Another principle is more closely related. Review the principles in The Open Source Way. +
++ Shared values +
++ It's not shared values. + Another principle is more closely related. Review the principles in The Open Source Way. +
++ Collaboration +
++ It's not collaboration. + Another principle is more closely related. Review the principles in The Open Source Way. +
++ Transparency +
++ It's not transparency. + Another principle is more closely related. Review the principles in The Open Source Way. +
++ Inclusivity +
++ It's not inclusivity. + Another principle is more closely related. Review the principles in The Open Source Way. +
++ Meritocracy +
++ It's not meritocracy. + Another principle is more closely related. Review the principles in The Open Source Way. +
++ Release early and often. +
++ Releasing early and often allows the project to respond to needs quickly by gathering feedback. +
++ Shared values +
++ It's not shared values. + Another principle is more closely related. Review the principles in The Open Source Way. +
++ Collaboration +
++ When we can modify what others have shared, we unlock new possibilities. +
++ Transparency +
++ It's not transparency. + Another principle is more closely related. Review the principles in The Open Source Way. +
++ Inclusivity +
++ It's not inclusivity. + Another principle is more closely related. Review the principles in The Open Source Way. + +
++ Meritocracy +
++ It's not meritocracy. + Another principle is more closely related. Review the principles in The Open Source Way. +
++ Release early and often. +
++ It's not release early and often. + Another principle is more closely related. Review the principles in The Open Source Way. +
++ Shared values +
++ It's not shared values. + Another principle is more closely related. Review the principles in The Open Source Way. +
++ Collaboration +
++ It's not collaboration. + Another principle is more closely related. Review the principles in The Open Source Way. +
++ Transparency +
++ It's not transparency. + Another principle is more closely related. Review the principles in The Open Source Way. +
++ Inclusivity +
++ Good ideas can come from anywhere. +
++ Meritocracy +
++ It's not meritocracy. + Another principle is more closely related. Review the principles in The Open Source Way. +
++ Release early and often. +
++ It's not release early and often. + Another principle is more closely related. Review the principles in The Open Source Way. +
++ Shared values +
++ It's not shared values. + Another principle is more closely related. Review the principles in The Open Source Way. +
++ Collaboration +
++ It's not collaboration. + Another principle is more closely related. Review the principles in The Open Source Way. +
++ Transparency +
++ When we have access to the information and materials to do our best work, we can build on each other's work. +
++ Inclusivity +
++ It's not inclusivity + Another principle is more closely related. Review the principles in The Open Source Way. +
++ Meritocracy +
++ It's not meritocracy. + Another principle is more closely related. Review the principles in The Open Source Way. +
++ Release early and often. + Another principle is more closely related. Review the principles in The Open Source Way. +
++ It's not release early and often. +
+
- There are a number of roles that tend to exist in FOSS communities.
- Some of these include
+ If you would like you can review a discussion of these roles in the speaker notes in
Choosing the license under which the project will be released.
+ ++ Users +
++ Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides. +
++ Requestors +
++ It's not requestors. + Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides. +
++ Contributors +
++ It's not contributors. + Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides. +
++ Maintainers +
++ It's not maintainers. + Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides. +
++ Leaders +
++ Leaders determine how a project will be licensed. +
++ Users +
++ Users have the freedom to choose how to use software. +
++ Requestors +
++ It's not requestors. + Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides. +
++ Contributors +
++ It's not contributors. + Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides. +
++ Maintainers +
++ It's not maintainers. + Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides. +
++ Leaders +
++ It's not leaders. + Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides. +
++ Users +
++ Users only use the software as is. +
++ Requestors +
++ Requestors request new features. +
++ Contributors +
++ It's not contributors. + Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides. +
++ Maintainers +
++ It's not maintainers. + Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides. +
++ Leaders +
++ It's not leaders. + Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides. +
++ Users +
++ Users detect bugs and report them. +
++ Requestors +
++ Requestors detect bugs and report them. +
++ Contributors +
++ It's not contributors. + Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides. +
++ Maintainers +
++ It's not maintainers. + Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides. +
++ Leaders +
++ It's not leaders. + Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides. +
++ Users +
++ It's not users. + Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides. +
++ Requestors +
++ It's not requestors. + Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides. +
++ Contributors +
++ Contributors patch the code. +
++ Maintainers +
++ It's not maintainers. + Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides. +
++ Leaders +
++ It's not leaders. + Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides. +
+@@ -410,21 +1267,79 @@
+ Users +
++ It's not users. + Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides. +
++ Requestors +
++ It's not requestors. + Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides. +
++ Contributors +
++ Contributors contribute more than just code, such as installation instructions. +
++ Maintainers +
++ It's not maintainers. + Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides. +
++ Leaders +
++ It's not leaders. + Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides. +
++ Users +
++ It's not users. + Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides. +
++ Requestors +
++ Requestors can do bug documenting. +
++ Contributors +
++ Contributors contribute more than just code, such as bug documenting. +
++ Maintainers +
++ It's not maintainers. + Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides. +
++ Leaders +
++ It's not leaders. + Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides. +
++ Users +
++ It's not users. + Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides. +
++ Requestors +
++ It's not requestors. + Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides. +
++ Contributors +
++ It's not contributors. + Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides. +
++ Maintainers +
++ It's not maintainers. + Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides. +
++ Leaders +
++ Leaders determine the goals for a project. +
++ Users +
++ It's not users. + Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides. +
++ Requestors +
++ It's not requestors. + Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides. +
++ Contributors +
++ It's not contributors + Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides. +
++ Maintainers +
++ Maintainers are responsible for the code, including accepting bug fixes. +
++ Leaders +
++ It's not leaders. + Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides. +
++ Users +
++ It's not users. + Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides. +
++ Requestors +
++ It's not requestors. + Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides. +
++ Contributors +
++ Contributors contribute to design. + Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides. +
++ Maintainers +
++ Maintainers are responsible for the code, including designing. +
++ Leaders +
++ It's not leaders. + Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides. +
+- It will take a while for this process and all of the commands to become a natural part of the way you work. - To help speed that process, this section provides a chance to collect and review the Git commands that were used in this chapter. + It will take a while for this process and all of the commands to become a natural part of the + way you work. + To help speed that process, this section provides a chance to collect and review the Git + commands that were used in this chapter.
- Match the tasks on the right with the appropriate git command listed on the left. + 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. -
-+ Note that the tasks listed are in approximately the same order as they appear in the + sections of this chapter. +
+
@@ -349,7 +347,6 @@
-
@@ -363,7 +360,20 @@
Choose the best match.
@@ -557,7 +567,7 @@
Thank you.
diff --git a/source/ch-instructor-guide/sec-instructor-communities.ptx b/source/ch-instructor-guide/sec-instructor-communities.ptx
index 8827b16..bffb1b6 100644
--- a/source/ch-instructor-guide/sec-instructor-communities.ptx
+++ b/source/ch-instructor-guide/sec-instructor-communities.ptx
@@ -125,16 +125,16 @@
-
- The GitKit uses sequences of diagrams to visualize key concepts and processes related to the use of git and GitHub and the forking workflow. Diagrams in the same style are used throughout all of the GitKit topics. A key to success with the GitKit, for both faculty and students, is understanding these diagrams and being able to connect what they depict to the git/GitHub commands used in the forking workflow.
+ The GitKit uses sequences of diagrams to visualize key concepts and processes related to the use of Git and GitHub and the forking workflow. Diagrams in the same style are used throughout all of the GitKit topics. A key to success with the GitKit, for both faculty and students, is understanding these diagrams and being able to connect what they depict to the Git/GitHub commands used in the forking workflow.
- The first series of diagrams show the relationship between the three copies of a FOSS project's repository that a developer interacts with (upstream, origin and local). They also illustrate the connection between these three copies and the git and GitHub commands that create them (fork and clone). A distinction is also made between remote copies of the repository, those residing in the cloud (the upstream and origin), and the local copy that resides in the student's development environment. Note, that when using a KitClient the development environment is running via GitHub Codespaces and not on the student's physical machine. This can be a source of confusion and it is worth spending some time clarifying this relationship.
+ The first series of diagrams show the relationship between the three copies of a FOSS project's repository that a developer interacts with (upstream, origin and local). They also illustrate the connection between these three copies and the Git and GitHub commands that create them (fork and clone). A distinction is also made between remote copies of the repository, those residing in the cloud (the upstream and origin), and the local copy that resides in the student's development environment. Note, that when using a KitClient the development environment is running via GitHub Codespaces and not on the student's physical machine. This can be a source of confusion and it is worth spending some time clarifying this relationship.
The hands-on activities provide detailed instructions for creating a fork in GitHub, starting the KitClient and creating a local clone. However, if time allows it may be also be helpful to demonstrate these actions in class.
@@ -143,7 +143,7 @@
- A second series of diagrams introduce a basic FOSS workflow that illustrates how upstreaming works. Note that this is not the full forking workflow, as it does not include the use of feature branches and ignores the details of staging and committing changes. The primary purpose of this sequence of diagrams is to illustrate how the concept of upstreaming from the Cookie video is implemented using git/GitHub. Additional details of the forking workflow (branch, edit, stage, commit) are added in the second topic and revisited in the third topic.
+ A second series of diagrams introduce a basic FOSS workflow that illustrates how upstreaming works. Note that this is not the full forking workflow, as it does not include the use of feature branches and ignores the details of staging and committing changes. The primary purpose of this sequence of diagrams is to illustrate how the concept of upstreaming from the Cookie video is implemented using Git/GitHub. Additional details of the forking workflow (branch, edit, stage, commit) are added in the second topic and revisited in the third topic.
- This chapter then focuses on the resolution of merge conflicts. The concepts of merge commits, common ancestors, best common ancestor, and non-conflicting and conflicting changes are introduced. The topic then covers the process of merging main into a feature branch, git's raw conflict information and the use of a basic merge tool. The hands-on activity concludes with the students having resolved the merge conflict in their "Round 2" pull request. Note that these PRs are never merged into the upstream as part of the GitKit activities. + This chapter then focuses on the resolution of merge conflicts. The concepts of merge commits, common ancestors, best common ancestor, and non-conflicting and conflicting changes are introduced. The topic then covers the process of merging main into a feature branch, Git's raw conflict information and the use of 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:
@@ -89,7 +89,7 @@
Uses a text based example to introduce the concepts of main branch to the best common ancestor and highlight all differences in the main branch. Then any lines that are highlighted in both the feature branch and the main branch are conflicting changes. All other highlighted lines are non-conflicting changes.
- Note that in these examples the identification of conflicting changes is simplified to be line based. That is, if a change is found, the entire line is marked as containing a change. Similarly, if a line is changed in both the feature branch and the main branch, the entire line is marked as a conflict. The algorithm used by git is more complex than this simplified approach, but the concept is sufficiently the same for the purposes of these activities.
+ Note that in these examples the identification of conflicting changes is simplified to be line based. That is, if a change is found, the entire line is marked as containing a change. Similarly, if a line is changed in both the feature branch and the main branch, the entire line is marked as a conflict. The algorithm used by Git is more complex than this simplified approach, but the concept is sufficiently the same for the purposes of these activities.
- Shows the raw merge conflict information that is produced by git when a merge creates a conflict. This information can be edited manually in any text editor. However, it is often difficult to identify exactly what changes exist. This is good motivation for the use of a raw merge conflict information that is produced by Git when a merge creates a conflict. This information can be edited manually in any text editor. However, it is often difficult to identify exactly what changes exist. This is good motivation for the use of a
- Reviews the main git/GitHub concepts and vocabulary from Chapter 2. The terms
Introduces branches and commits. In the diagrams on these slides, and throughout the remainder of the GitKit, different colors are used as the unique identifier for each commit (e.g. we can talk about the "red" or the "yellow" commit). - This slide introduces a conceptual simplification to think of a commit as a complete "snapshot" of all files in the project repository at that point in time, along with some meta data. Depending on the level of the course being taught, it may be worth a moment here to to explore the idea that storing a complete copy of the files for each commit would be very inefficient and discuss that it does not work that way in practice. Git commits do not actually contain full copies of every file in the repo. Instead, for each file that is changed by the commit, the "snapshot" contains a full (compressed) copy of the file. For each file that is not changed by the commit, the "snapshot" contains only a link (like a shortcut) to that file. This link points to the file in the most recent commit in which it was changed. Depending on the level of the course being taught, this can also provide an opportunity to distinguish git from other delta-based version control systems (cvs, svn) where commits record changes to files rather than complete copies of the changed files. + This slide introduces a conceptual simplification to think of a commit as a complete "snapshot" of all files in the project repository at that point in time, along with some meta data. Depending on the level of the course being taught, it may be worth a moment here to to explore the idea that storing a complete copy of the files for each commit would be very inefficient and discuss that it does not work that way in practice. Git commits do not actually contain full copies of every file in the repo. Instead, for each file that is changed by the commit, the "snapshot" contains a full (compressed) copy of the file. For each file that is not changed by the commit, the "snapshot" contains only a link (like a shortcut) to that file. This link points to the file in the most recent commit in which it was changed. Depending on the level of the course being taught, this can also provide an opportunity to distinguish Git from other delta-based version control systems (cvs, svn) where commits record changes to files rather than complete copies of the changed files.
- The diagrams used by the GitKit to illustrate git and GitHub concepts are extended to include branches and commits. The convention of using colors as the unique identifier for each commit is also used in these diagrams. In doing so, it is important to emphasize the distinction between the final commit in the main branch.
+ The diagrams used by the GitKit to illustrate Git and GitHub concepts are extended to include branches and commits. The convention of using colors as the unique identifier for each commit is also used in these diagrams. In doing so, it is important to emphasize the distinction between the final commit in the main branch.
Thank you.
@@ -409,7 +409,7 @@
Be sure that your URL is from your pull request to the upstream repository for your course.
- It should have the format
- 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. + 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.
@@ -45,7 +45,7 @@
Note that the tasks listed are in approximately the same order as they appear in the sections of this chapter.
diff --git a/source/ch-merge-conflicts/sec-merging-the-main-branch-into-a-feature-branch.ptx b/source/ch-merge-conflicts/sec-merging-the-main-branch-into-a-feature-branch.ptx
index 07b6a74..239ebb6 100644
--- a/source/ch-merge-conflicts/sec-merging-the-main-branch-into-a-feature-branch.ptx
+++ b/source/ch-merge-conflicts/sec-merging-the-main-branch-into-a-feature-branch.ptx
@@ -53,7 +53,18 @@
Read the introduction to this section.
diff --git a/source/ch-merge-conflicts/sec-resolving-a-merge-conflict.ptx b/source/ch-merge-conflicts/sec-resolving-a-merge-conflict.ptx
index 97c6d85..a7e64d9 100644
--- a/source/ch-merge-conflicts/sec-resolving-a-merge-conflict.ptx
+++ b/source/ch-merge-conflicts/sec-resolving-a-merge-conflict.ptx
@@ -68,7 +68,20 @@
Compare the terms used in the merge tool options to the information displayed in the first and last lines of the merge conflict information.
@@ -397,7 +436,7 @@
-
- Please give the full
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-staying-synchronized/sec-gitkit-feedback.ptx b/source/ch-staying-synchronized/sec-gitkit-feedback.ptx
index b828154..aeeee14 100644
--- a/source/ch-staying-synchronized/sec-gitkit-feedback.ptx
+++ b/source/ch-staying-synchronized/sec-gitkit-feedback.ptx
@@ -195,7 +195,7 @@
- Examples of the git commands in addition to the syntax would help me understand what I should be typing.
+ Examples of the Git commands in addition to the syntax would help me understand what I should be typing.
The command reference that you created in
Please give the full
Please give the full
- The arrow on the left represents a git remote associated with your local repository, but it is not the upstream.
+ The arrow on the left represents a Git remote associated with your local repository, but it is not the upstream.
The base is where you want your changes merged into/the repository you created your fork from. @@ -129,11 +134,16 @@ Match the right hand column with either base branch or compare branch to indicate which is “pulled from” or “merged into”.
-
The base is where you want your changes merged into.
diff --git a/source/ch-upstreaming-changes/sec-editing-local-files.ptx b/source/ch-upstreaming-changes/sec-editing-local-files.ptx
index 63e6cce..b3c0c49 100644
--- a/source/ch-upstreaming-changes/sec-editing-local-files.ptx
+++ b/source/ch-upstreaming-changes/sec-editing-local-files.ptx
@@ -363,7 +363,7 @@
- Strike-through is not part of the feedback git commands can provide.
+ Strike-through is not part of the feedback Git commands can provide.
- The branch name is not displayed in the output from this git command.
+ The branch name is not displayed in the output from this Git command.
- 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.
+
+ 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.
-
+ 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.
+
- Examples of the git commands in addition to the syntax would help me understand what I should be typing. + Examples of the Git commands in addition to the syntax would help me understand what I should be typing.
- Are you sure that is the file that the issue asked you to edit? -
-
- Check the format of your
- Note that git also has a
- The GitKit introduces students to fundamental git and GitHub skills and concepts and the
- The GitKit is designed to be used as a module within a course where students are first introduced to git and GitHub, but has been adapted for use in other settings. A nominal use of the GitKit requires four 75-minute class periods where the instructor introduces each chapter and four 2-3 hour homework assignments where concepts are reinforced and students gain hands-on experience. + The GitKit is designed to be used as a module within a course where students are first introduced to Git and GitHub, but has been adapted for use in other settings. A nominal use of the GitKit requires four 75-minute class periods where the instructor introduces each chapter and four 2-3 hour homework assignments where concepts are reinforced and students gain hands-on experience.
@@ -75,7 +75,7 @@
- Chapters that guide students through exercises that reinforce concepts from class and give them hands-on experience with git and GitHub. + Chapters that guide students through exercises that reinforce concepts from class and give them hands-on experience with Git and GitHub.