diff --git a/LICENSE b/LICENSE index 9cf1062..9dccfa4 100644 --- a/LICENSE +++ b/LICENSE @@ -1,19 +1,19 @@ -MIT License - -Permission is hereby granted, free of charge, to any person obtaining a copy -of this software and associated documentation files (the "Software"), to deal -in the Software without restriction, including without limitation the rights -to use, copy, modify, merge, publish, distribute, sublicense, and/or sell -copies of the Software, and to permit persons to whom the Software is -furnished to do so, subject to the following conditions: - -The above copyright notice and this permission notice shall be included in all -copies or substantial portions of the Software. - -THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR -IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, -FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE -AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER -LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, -OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE -SOFTWARE. +MIT License + +Permission is hereby granted, free of charge, to any person obtaining a copy +of this software and associated documentation files (the "Software"), to deal +in the Software without restriction, including without limitation the rights +to use, copy, modify, merge, publish, distribute, sublicense, and/or sell +copies of the Software, and to permit persons to whom the Software is +furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice shall be included in all +copies or substantial portions of the Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE +AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, +OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE +SOFTWARE. diff --git a/README.md b/README.md index 966eaf4..19a72b0 100644 --- a/README.md +++ b/README.md @@ -1,114 +1,29 @@ -# Git and GitHub - -## Contents -* [Description](#description) -* [Learning Outcomes](#learning-outcomes) -* [Assignments](#assignments) -* [Contacts](#contacts) -* [Delivery of the Learning Module](#delivery-of-the-learning-module) -* [Schedule](#schedule) -* [Requirements](#requirements) -* [Resources](#resources) - + [Cheat sheet](#cheatsheet) - + [Videos](#videos) - + [How to get help](#how-to-get-help) -* [Folder Structure](#folder-structure) - -## Description - -This module explores version control with Git and GitHub, and how it connects to the ethical discussions of reproducibility. Participants will set up Git and create and use repositories, including recording, viewing and undoing changes. You will also learn how to create branches and collaborate with others with shared branches. This module also introduces more advanced commands such as de-bugging and history editing. - -Throughout the entire module, participants will learn how to problem solve through live coding. You will also learn about reproducibility and how to centre it within your work. - -## Learning Outcomes - -By the end of the module, participants will be able to: -* Use Git to collaboratively save, restore, and update work through version control -* Explain the difference between Git and GitHub - -## Assignments - -Participants should review the [Assignment Submission Guide](https://github.com/UofT-DSI/onboarding/blob/main/onboarding_documents/submissions.md) for instructions on how to complete assignments in this module. - - -1. [Git Assignment](https://github.com/UofT-DSI/git/blob/main/02_assignments/git_assignment.md) - - -## Contacts - -**Questions can be submitted to the _#cohort-3-help_ channel on Slack** - -* Technical Facilitator: - * **Simeon Wong** (he/him) - simeonm.wong@utoronto.ca - - * Learning Support Staff: - * **Michaela Drouillard** (she/her) - michaela.drouillard@mail.utoronto.ca - * **Julia Gallucci** (she/her) - julia.gallucci@mail.utoronto.ca - * **Emma Teng** - e.teng@mail.utoronto.ca -  -## Delivery of the Learning Module - -This module will include live learning sessions and optional, asynchronous work periods. During live learning sessions, the Technical Facilitator will introduce and explain key concepts and demonstrate core skills. Learning is facilitated during this time. Before and after each live learning session, the instructional team will be available for questions related to the core concepts of the module. Optional work periods are to be used to seek help from peers, the Learning Support team, and to work through the homework and assignments in the learning module, with access to live help. Content is not facilitated, but rather this time should be driven by participants. We encourage participants to come to these work periods with questions and problems to work through. -  -Participants are encouraged to engage actively during the learning module. They key to developing the core skills in each learning module is through practice. The more participants engage in coding along with the instructional team, and applying the skills in each module, the more likely it is that these skills will solidify. - -## Schedule - -The schedule is tentative and may be modified as needed. Learners will be notified of schedule changes. - -||Day 1|Day 2|Day 3|Day 4|Day 5| -|---|---|---|---|---|---| -|Week 1|Live Learning Session 1 ([Shell](https://github.com/UofT-DSI/shell))|Live Learning Session 2 (Shell)|Live Learning Session 3 (Git & Github)|Work Period 1|Work Period 2| -  -## Requirements - -* Participants are not expected to have any coding experience; the learning content has been designed for beginners. -* Participants are encouraged to ask questions, and collaborate with others to enhance their learning experience. -* Participants must have a computer and an internet connection to participate in online activities. -* Participants must not use generative AI such as ChatGPT to generate code in order to complete assignments. It should be used as a supportive tool to seek out answers to questions you may have. -* We expect learners to have completed the [onboarding repo](https://github.com/UofT-DSI/onboarding/tree/main/onboarding_documents). -* We encourage participants to default to having their camera on at all times, and turning the camera off only as needed. This will greatly enhance the learning experience for all participants and provides real-time feedback for the instructional team. - -## Resources - -Feel free to use the following as resources: - -### Cheat sheet - -- [Atlassian](https://www.atlassian.com/git/tutorials/atlassian-git-cheatsheet) -- [GitHub](https://education.github.com/git-cheat-sheet-education.pdf) - -### Videos -- [Most common git commands](https://www.youtube.com/watch?v=PSJ63LULKHA) -- [Git explained in 100 seconds](https://www.youtube.com/watch?v=hwP7WQkmECE) -- [Git vs GitHub: What's the difference?](https://www.youtube.com/watch?v=wpISo9TNjfU) - -### How to get help - -![image](./steps_to_ask_for_help.png) - -
- -## Folder Structure - -```markdown -. -├── 01_slides -├── 02_assignments -├── 03_homework -├── 04_instructional_team -├── LICENSE -├── README.md -└── steps_to_ask_for_help.png -``` - -* **slides:** Module slides as PDF or PPTX files. -* **homework:** Homework to practice concepts covered in class. -* **assignments:** Assignments. -* **instructors:** This folder provides guidance for Technical Facilitators and the Learning Support team on teaching methodologies and content delivery. -* README: This file! -* .gitignore: Files to exclude from this folder, specified by the Technical Facilitator \ No newline at end of file +# Git Assignment - + +nano README.mda. What is an issue? +so far so good no issue +b. What is a pull request? +pull request - A pull request is a feature commonly used in distributed version control systems like Git, particularly in platforms like GitHub, GitLab, and Bitbucket. It allows developers to propose changes to a repository hosted on such platforms. +c. How do I open up a pull request? +first we need fork the repository and clone the forl +d. Give me a step by step guide on how to add someone to your repository. +Navigate to Your Repository: Go to the main page of your repository on GitHub. +Click on "Settings": On the right-hand side of the repository page, you'll find a "Settings" tab. Click on it to access the settings for your repository. +Select "Manage access": In the settings sidebar on the left, you'll see an option labeled "Manage access." Click on it. +Click on "Invite a collaborator": You'll see a button labeled "Invite a collaborator" near the top-right corner of the page. Click on it to invite someone to collaborate on your repository. +Enter the Collaborator's Username or Email: In the dialog that appears, enter the GitHub username or email address of the person you want to add as a collaborator. +Choose the Collaborator's Access Level: You can choose whether to give the collaborator "Write" access or "Maintain" access. Write access allows them to push to the repository and manage issues and pull requests. Maintain access grants them additional privileges, such as managing repository settings and inviting more collaborators. +Click on "Add [username]": Once you've entered the collaborator's information and selected their access level, click on the "Add [username]" button to send the invitation. +Confirm the Invitation (if necessary): If the collaborator is not already a GitHub user, they will receive an email inviting them to join GitHub and collaborate on your repository. They'll need to accept the invitation before they can access the repository. +e. What is the difference between git and GitHub? +git as Git is the underlying version control system that allows developers to track changes to files, while GitHub is a web-based platform that provides hosting for Git repositories and collaboration features to facilitate teamwork and project management. The `git diff` command is used to show the differences between various states of your Git repository, such as changes between commits, the working directory, and the staging area. It helps you understand what changes have been made to your files. +f. What does git diff do? +The `git diff` command is used to show the differences between various states of your Git repository, such as changes between commits, the working directory, and the staging area. It helps you understand what changes have been made to your files. +g. What is the main branch? +main branch for muy perspective meanes thr main branch before fork and developed by expenince developer for other user to make a fork as well as a template The main branch usually has a default name like master or main, though some projects may use different names based on their conventions or preferences. For example, GitHub recently renamed the default branch from master to main as part of a broader initiative to remove potentially offensive language from its platform. +h. Besides our initial commit if it is a new repository, should we directly push our changes directly into the main branch? +no ideally, 4 reasons below Isolation of Changes: By creating feature branches, you isolate your changes from the main branch until they are ready to be merged. This allows you to work on multiple features or fixes simultaneously without affecting the stability of the main branch. +Code Review: Pull requests provide an opportunity for code review. By opening a pull request, you invite your peers to review your changes, provide feedback, and ensure code quality. This helps catch errors, improve code clarity, and maintain consistency across the codebase. +Continuous Integration and Testing: Many development teams use continuous integration (CI) systems to automatically build, test, and validate code changes. Pull requests can trigger CI pipelines, allowing automated tests to run against your changes before they are merged into the main branch. This helps catch regressions and ensures that new code meets quality standards. +Version History: Using feature branches and pull requests preserves a clean version history. Each pull request represents a discrete set of changes, making it easier to track the evolution of the codebase over time and understand the rationale behind each change. +Reduced Risk: By decoupling feature development from the main branch, you reduce the risk of introducing bugs or breaking existing functionality. Changes can be thoroughly tested and reviewed before they are merged into the main branch, helping to maintain the stability of the codebase.