- 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-cloning-your-origin.ptx b/source/ch-communities-and-collaboration/sec-cloning-your-origin.ptx index cb12f5e..3aafa73 100644 --- a/source/ch-communities-and-collaboration/sec-cloning-your-origin.ptx +++ b/source/ch-communities-and-collaboration/sec-cloning-your-origin.ptx @@ -421,11 +421,11 @@
- 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.
- 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
- 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. +
+
-
- 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.
- 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.
-
- 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 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.
- 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.
- 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.
- 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.