---
# System prepended metadata

title: Git and GitHub

---

# Git and GitHub

---
title: Agenda
description:
duration: 300
card_type: cue_card
---

### Content

* Git with GitHub Desktop
  * Version Control System
  * Git vs. GitHub
  * Creating a repository
  * Pushing & Collaboration
  * Branching & Merging
  * Forking & Cloning
* Git with CLI
  * Install & Initializing Git
  * Staging Environment
  * Git Commands
  * Git Branches
  * Creating a repository
  * Git Push & Pull
  * Git Rebase & Merge
  * GitHub Fork & Clone

---
title: Git using GitHub
description:
duration: 900
card_type: cue_card
---

## Git using GitHub

### Intuition for Git

* Suppose you start working on a long-term project, and you're making changes to the project daily.
* One day you realize that the previous version of a function made more sense and that you have wanted to return to that version.
* Only if we had a place where we kept all versions of our code, we could have done it easily.

<img src = https://d2beiqkhq929f0.cloudfront.net/public_assets/assets/000/063/172/original/version.png?1706065709 height = 300 width = 600>

### What is Git?

* Git is a VCS (version control system).
* But Git isn't any VCS, it's a distributed VCS which means that
  * Every collaborator of the project will have a history of the changes made on their local machine.
* It is distributed so you can access your code files from another computer and so can other developers.
* People can work on different features of the project without having to communicate with each other or the server hosting the project.

### What is GitHub?

* It is a platform for version control that uses Git at its core.
* It lets you host the remote version of your project from where all the collaborators can have access to it.
* Not just your own team members but any member of GitHub can contribute to your code (if it is a public project and you accept the changes proposed).
* It also serves as a platform where people can find a plethora of open-source projects with their codes.

There are other platforms as well that offer this:
- Bitbucket
- GitLab

<img src = https://d2beiqkhq929f0.cloudfront.net/public_assets/assets/000/063/173/original/push12.png?1706069414 height = 400 width = 600>

\
Here’s how it all fits together:
* You write your story on your computer using Git to keep track of changes.
* You save snapshots (called commits) of your story with Git so you can go back in time if needed.
* You put your story on GitHub, making it available on the internet for others to see.
* Others can make copies of your story from GitHub to work on their versions.
* They can suggest changes or improvements to your story and send them back to you (this is called a pull request).
* You review their changes and decide if you want to include them in your story.
* GitHub helps manage this collaboration, making it easier for everyone to work together on the same project.

### Difference between Git and GitHub

* Git is a VCS that manages and keeps track of your code.
* GitHub is a service that lets you host, share, and manage your code files on the internet.

**Please make sure -**
* You have GitHub Desktop  installed,
* Created and signed into your GitHub account.
* Ref : https://docs.github.com/en/desktop/installing-and-authenticating-to-github-desktop/installing-github-desktop

---
title: Creating & Working on a repo
description:
duration: 1200
card_type: cue_card
---

### What is a Repository?

A **Repository** is like a folder where you keep all the files for your project.

* **Local Repository**: Think of this as your personal folder on your computer. It's where you work on your project, make changes, and save your progress.
* **Remote Repository**: This is like a backup or a shared folder on the internet. It's where you store your project online, so others can see it and collaborate with you.

### Create a repository -

1. Click "Create a New Repository on your Hard Drive..."
2. In the “Create a New Repository” window, fill in the fields -
     * **Name** - Defines the name of your repository both locally and on GitHub.
     * **Description** - Self explanatory. Optional field.
     * **Local path** - Location of the repository on your computer.
3. **Initialize this repository with a README** - Creates an initial commit with a README.md file.
    * README file helps people understand the purpose of your project.
4. **Git ignore** drop-down menu lets you add a custom file to ignore specific files in your local repository.
5. **License** drop-down menu lets you add an open-source license to a LICENSE file in your repository.
     * You don't need to worry about adding a license right away.
6. Click Create repository.

<img src = https://d2beiqkhq929f0.cloudfront.net/public_assets/assets/000/063/223/original/git1.png?1706080980 height = 450 width = 650>

### Working on the repository -

1. We can now go to the git folder that we want to work with and open a file in the code editor.
2. We can update our code or even add/remove some files.
3. If we then go back to the repository in github desktop, it will show the difference in the two versions of the updated file.

<img src = https://d2beiqkhq929f0.cloudfront.net/public_assets/assets/000/063/296/original/git3.png?1706113772 height = 400 width = 750>

4. Now we can add a summary, description and click on '**Commit to main**'.
5. Our history is saved. We can check it in the **History** tab.

\
But these changes are only available on your local machine because we haven't pushed anything to the remote repository yet.

You can publish your repository to GitHub to keep it synchronized across multiple computers and allow other people to access it.

1. To publish your repository, **push** your local changes to GitHub.
2. In the **Publish Repository** window, enter details for your new repository.  
3. **Keep this code private** lets you control who can view your project.
4. The **Organization** drop-down menu, if present, lets you publish your repository to a specific organization that you belong to on GitHub.
5. Click Publish Repository.

<img src = https://d2beiqkhq929f0.cloudfront.net/public_assets/assets/000/063/300/original/git4.png?1706115506 height = 400 width = 700>

---
title: Pushing and Collaboration
description:
duration: 900
card_type: cue_card
---

### Pushing and Collaboration

* **Pull**: Pull not only downloads changes from a remote repository but also merges them into your current working branch automatically.
* **Fetch**: Fetch only downloads changes from a remote repository and stores them in your local repository but doesn't automatically merge them into your current working branch.
  * Use “fetch” when you want to see what changes exist in the remote repository but don't want to merge them immediately.
  * This allows you to review changes before deciding to merge.
* **Conflict**: A conflict occurs in Git when multiple people make changes to the same part of a file, and Git can't automatically decide which changes to accept.
  * To resolve a conflict, you need to manually edit the file, keeping the changes you want and removing the conflicting parts.
  * After resolving the conflict, you can commit the resolved file.

<img src = https://d2beiqkhq929f0.cloudfront.net/public_assets/assets/000/063/308/original/git5.png?1706120432 height = 400 width = 500>

### Collaborative Development

The main branch (often called “master” or “main”) in a Git repository typically represents the stable and production-ready version of your project.

#### The complete pipeline theoretically looks like -
1. **Pulling Code**: Start by making sure you have the latest code from the main branch.
2. **Creating a New Branch**: If you’re working on a new feature or bug fix, create a new branch from the main branch. This branch will contain your changes.
3. **Making Changes**: Work on your code changes within your feature branch.
4. **Committing Changes**: Return to GitHub Desktop. You should see your changes listed under “Changes.” Write a descriptive commit message and click the “Commit” button to save your changes.

<img src = https://d2beiqkhq929f0.cloudfront.net/public_assets/assets/000/063/312/original/pull1.png?1706121091 height = 320 width = 650>

---
title: Branching and Merging
description:
duration: 900
card_type: cue_card
---

### Branching and Merging

* Git branches are effectively a pointer to a snapshot of your changes.
* When you want to add a new feature or fix a bug, no matter how big or how small, you spawn a new branch to encapsulate your changes.

<img src = https://d2beiqkhq929f0.cloudfront.net/public_assets/assets/000/064/146/original/bran567.PNG?1707119206 height = 330 width = 500>

1. Let's create a new branch say `branch1` and make some changes in the README file. Then commit to `branch1` and push it.
2. If we go to our github repository, we can see that there is a new branch and an option to compare and pull request.

<img src = https://d2beiqkhq929f0.cloudfront.net/public_assets/assets/000/063/315/original/bran1.png?1706122640 height = 400 width = 700>

\
<img src= https://d2beiqkhq929f0.cloudfront.net/public_assets/assets/000/063/316/original/bran2.png?1706122931 height = 400 width = 700>

3. The first thing we want to do is create a pull request to compare the changes of `branch1` with the `main` branch.
4. Because you are the owner of the repository, you can review and merge the pull request.

<img src = https://d2beiqkhq929f0.cloudfront.net/public_assets/assets/000/063/317/original/pullr1.png?1706123145 height = 400 width = 750>

5. Once merged, you have the option to delete the `branch1` and you will see that the changes in README file are visible in the `main` branch.

### Resolving Conflicts

* If while merging, there are two conflicting or different changes to same line of a file, GitHub is not sure which one to keep.
* In that case, you must manually check that to resolve the conflict. After that you can mark as resolved and merge.

---
title: Quiz-1
description: Quiz-1
duration: 60
card_type: quiz_card
---

# Question
How can we merge the changes in a branch into the main branch?

# Choices
- [ ] By committing the changes in the branch.
- [ ] By publishing the branch.
- [x] By publishing the branch and creating a pull request.
- [ ] By pulling the latest version of main into the branch.

---
title: Contributing to a Project
description:
duration: 900
card_type: cue_card
---

### Forking

* It is a way to make a personal copy of a public or open-source repository on a platform like GitHub.
* When you fork a repository, you create an identical copy of that repository in your GitHub account.

### Cloning

* You can create a local copy of any repository on GitHub that you have access to by cloning the repository.
* [Read this](https://docs.github.com/en/desktop/adding-and-cloning-repositories/cloning-a-repository-from-github-to-github-desktop) to see how to clone a repository to GitHub Desktop.

Try forking and cloning : <u>https://github.com/octocat/Spoon-Knife</u>
This is a demo repository meant for trying out forking.

<img src = https://d2beiqkhq929f0.cloudfront.net/public_assets/assets/000/064/126/original/spoon1.PNG?1707068598 height = 400 width = 700>

\
<img src = https://d2beiqkhq929f0.cloudfront.net/public_assets/assets/000/064/127/original/spoo2.PNG?1707068811 height = 400 width = 700>

* When you clone a repository, any changes you push to GitHub will affect the original repository.
* To make changes without modifying the original project, you can create a separate copy by forking the repository.
* You can create a pull request to propose that maintainers incorporate the changes in your fork into the original upstream repository.

\
When you're ready to propose changes into the main project -

1. Head on over to the repository on GitHub where your project lives.
2. Click **Contribute** and then Open a pull request.
3. GitHub will bring you to a page that shows the differences between your fork and the original repository.
4. Click **Create pull request**.
5. GitHub will bring you to a page where you can enter a title and a description of your changes.
6. It's important to provide as much useful information and a rationale for why you're making this pull request in the first place.
7. Click **Create pull request**.

<img src = https://d2beiqkhq929f0.cloudfront.net/public_assets/assets/000/064/129/original/pullre3.PNG?1707070622 height = 400 width = 700>

---
title: Quiz-2
description: Quiz-2
duration: 30
card_type: quiz_card
---

# Question
If you create a new branch in a project, will it take additional storage space?

# Choices
- [ ] Yes
- [x] No

---
title: Break & Doubt Resolution
description:
duration: 600
card_type: cue_card
---

### Break & Doubt Resolution

`Instructor Note:`
* Take this time (up to 5-10 mins) to give a short break to the learners.
* Meanwhile, you can ask the them to share their doubts (if any) regarding the topics covered so far.

---
title: Git using CLI
description: 
duration: 1200
card_type: cue_card
---

## Git using CLI

### Installing Git

Git comes pre-installed in some Macs and Linux-based systems, but you can always check if you have Git installed in your machine by typing `git --version` in your terminal.

<u>https://www.atlassian.com/git/tutorials/install-git</u>

We will start by creating a folder `github_test` and open that in the terminal.

We will add some files into that folder
* `python_file.py` : which has one statement print(“python file”)
* `text_file.txt` : that has single line text file

Now, these files are in our local system. How to get them on github?

### Git Help

If you are having trouble remembering commands or options for commands, you can use Git help.

There are a couple of different ways you can use the help command in command line or see all the available options for the specific command.

* `git help <command>`
* `git <command> help`
* `git help --all`

### Initialize Git

Once you have navigated to the correct folder which in our case is the github_test folder with our two files, you can initialize Git on that folder:
* `git init`

The `git init` command creates a new Git repository. It can be used to convert an existing, unversioned project to a Git repository or initialize a new, empty repository.

We can check what's in our folder now.

<img src = https://d2beiqkhq929f0.cloudfront.net/public_assets/assets/000/063/322/original/git44.png?1706150394 height = 200 width = 500>

### Staging Environment

* One of the core functions of Git is the concepts of the `Staging Environment`, and the `Commit`.
* As you are working, you may be adding, editing and removing files. But whenever you hit a milestone or finish a part of the work, you should add the files to a Staging Environment.
* Git has three main states that your files can reside in: **modified**, **staged**, and **committed**.
  * **Modified** means that you have changed the file but have not committed it to your database yet.
  * **Staged** means that you have marked a modified file in its current version to go into your next commit snapshot.

---
title: Git Commands
description:
duration: 1200
card_type: cue_card
---

### Git Status

The `git status` command displays the state of the working directory and the staging area.

It lets you see which changes have been staged, which haven't, and which files aren't being tracked by Git.

<img src = https://d2beiqkhq929f0.cloudfront.net/public_assets/assets/000/063/381/original/giy7.png?1706168738 height = 300 width = 600>

### Git Add

* The `git add` command adds a change in the working directory to the staging area.

<img src = https://d2beiqkhq929f0.cloudfront.net/public_assets/assets/000/063/326/original/stg3.png?1706154090 height = 200 width = 500>

* Using `--all` instead of individual file names will stage all changes (new, modified, and deleted) files.

### Git Commit

* Adding commits keep track of our progress and changes as we work. Git considers each commit change point or `Save Point.

<img src = https://d2beiqkhq929f0.cloudfront.net/public_assets/assets/000/063/327/original/stg6.png?1706154424 height = 250 width = 500>

`git commit -m "first commit"`

* By adding clear messages to each commit, it is easy for yourself (and others) to see what has changed and when.

### Git Reset

* `git reset` is the command we use when we want to move the repository back to a previous commit, discarding any changes made after that commit.

---
title: Git Branches
description:
duration: 1500
card_type: cue_card
---

### Git Branches

<img src = https://d2beiqkhq929f0.cloudfront.net/public_assets/assets/000/063/328/original/tre4.png?1706155236 height = 150 width = 800>

* One of Git's biggest advantages is its branching capabilities.
* **This allows someone to branch off of the master branch (where the production-quality code typically remains) and work on a feature or fix independently of the rest of the project.**

### New Git Branch

* Now we want to add some new features to our `python_file.py` page.
* We are working in our local repository, and we do not want to disturb or possibly wreck the main project.
* So we create a new branch: `git branch feature1`

<img src = https://d2beiqkhq929f0.cloudfront.net/public_assets/assets/000/063/329/original/fea4.png?1706155984 height = 70 width = 650>

* We can see that we have two branches now. The the `*` beside main specifies that we are currently on that branch.

### Git Checkout

* The `git checkout` command lets you navigate between the branches created by git branch.
* Checking out a branch updates the files in the working directory to match the version stored in that branch, and it tells Git to record all new commits on that branch.
* And moves us from the current branch, to the one specified at the end of the comman.

`git checkout feature1`


Now let's see just how quick and easy it is to work with different branches, and how well it works.

We are currently on branch feature1. We added a file to this branch, so let's list the files in the current directory using `ls`.

`ls`

<img src = https://d2beiqkhq929f0.cloudfront.net/public_assets/assets/000/063/354/original/ls5.png?1706165491 height = 40 width = 500>

### Git Switch Branch

* The git switch command is one of the latest commands being added to the list of Git commands. The git switch command was added in Git version 2.23.
* It can be seen as an alternative to its ancestor `git checkout` command.

`git switch main`

<img src = https://d2beiqkhq929f0.cloudfront.net/public_assets/assets/000/063/357/original/sw34.png?1706165748 height = 70 width = 600>

* We can see there that git manages the files. We can see that if we list files we don't see the `file2.txt`.

### Git Merge Branch

* Let's say now you have worked on the feature and tested it.
* Now we need to add the code to the main branch.

`git merge feature1`

<img src = https://d2beiqkhq929f0.cloudfront.net/public_assets/assets/000/063/361/original/mer7.png?1706166266 height = 180 width = 600>

* We can now see that when we list files in the main branch as well, we can see the new file there.

### Git Stash

* `git stash` temporarily shelves (or stashes) changes you've made to your working copy so you can work on something else, and then come back and re-apply them later on.
* Stashing is handy if you need to quickly switch context and work on something else, but you're mid-way through a code change and aren't quite ready to commit.

---
title: Quiz-3
description: Quiz-3
duration: 60
card_type: quiz_card
---

# Question

Which of these is usually the first command we run in a new project?

# Choices

- [ ] git add
- [ ] git status
- [ ] git branch
- [x] git init

---
title: Creating a github repository
description:
duration: 900
card_type: cue_card
---

### Creating a github repository -

Make sure you have a GitHub account.

* A repository contains all of your project's files and each file's revision history.

<img src = https://d2beiqkhq929f0.cloudfront.net/public_assets/assets/000/063/380/original/fer5.png?1706168677 height = 500 width = 500>

* Name the repo as `github_test`.
* Change it to private / public, add README and click create.

<img src = https://d2beiqkhq929f0.cloudfront.net/public_assets/assets/000/063/384/original/deg3.png?1706169533 height = 400 width = 800>

* Copy the url from the highlighted quick setup link for https.

### Creating Access Token on GitHub

First of all, you must create a personal Access Token on GitHub.

1. Click on your GitHub profile icon on the top right corner
2. Click Settings
3. From the menu shown on the left, click Developer Settings
4. Click Personal access tokens classic
5. Click Generate new token
6. Add a note that will help you identify the scope of the access token to be generated
7. Choose the Expiration period from the drop down menu
8. Select the scopes you want to grant the corresponding access to the generated access token
9. Finally click Generate Token

\
By now, you should have generated your personal access token successfully and the following message should be visible on your screen.

<img src = https://d2beiqkhq929f0.cloudfront.net/public_assets/assets/000/063/385/original/msg45.png?1706169958 height = 75 width = 800>

To add a new remote, use the git remote add command on the terminal, in the directory your repository is stored at.

`git remote set-url origin https://<githubtoken>@github.com/<username>/<repositoryname>.git`

<img src = https://d2beiqkhq929f0.cloudfront.net/public_assets/assets/000/063/387/original/fki3.png?1706170195 height = 200 width = 800>

---
title: Git Push & Pull
description:
duration: 900
card_type: cue_card
---

### Git Push

`git push -u origin main`

* The `git push` command is used to upload local repository content to a remote repository.
* Pushing is how you transfer commits from your local repository to a remote repo.
* `-u` is a flag and used to set origin as the upstream remote in the git config.

<img src = https://d2beiqkhq929f0.cloudfront.net/public_assets/assets/000/063/388/original/bfj3.png?1706171083 height = 250 width = 700>

* In Git, "origin" is a shorthand name for the remote repository that a project was originally cloned from.
* More precisely, it is used instead of that original repository's URL - and thereby makes referencing much easier.

#### Add a readme

<img src = https://d2beiqkhq929f0.cloudfront.net/public_assets/assets/000/063/389/original/read66.png?1706171258 height = 200 width = 400>

### Git Pull

* The `git pull` command is used to fetch and download content from a remote repository and immediately update the local repository to match that content.

* `pull` is a combination of 2 different commands:
  * Fetch
  * Merge

`git pull origin`

<img src = https://d2beiqkhq929f0.cloudfront.net/public_assets/assets/000/063/404/original/dhe2.png?1706179582 height = 150 width = 800>

---
title: Quiz-4
description: Quiz-4
duration: 60
card_type: quiz_card
---

# Question

You want to push your local branch "new-feature" to the remote repository. What is the correct git push command to accomplish this?

# Choices

- [x] git push origin new-feature
- [ ] git push new-feature
- [ ] git push origin main new-feature
- [ ] git push remote new-feature

---
title: Git Merge & Rebase
description:
duration: 900
card_type: cue_card
---

#### Git Merge

`git merge feature main`

* This creates a new “merge commit” in the feature branch that ties together the histories of both branches, giving you a branch structure that looks like this:

<img src = https://d2beiqkhq929f0.cloudfront.net/public_assets/assets/000/063/406/original/mer55.png?1706180985 height = 300 width = 600>

* Merging is nice because it's a non-destructive operation. The existing branches are not changed in any way.

#### Git Rebase

* You can rebase the feature branch onto main branch using the following commands:

  * `git checkout feature`
  * `git rebase main`

* This moves the entire feature branch to begin on the tip of the main branch, effectively incorporating all of the new commits in main.
* But, instead of using a merge commit, rebasing re-writes the project history by creating brand new commits for each commit in the original branch.

<img src = https://d2beiqkhq929f0.cloudfront.net/public_assets/assets/000/063/407/original/hfjg8.png?1706181431 height = 300 width = 600>

* Rebase is used for maintaining a linear project history.
* You will benefit from an eventual clean merge of your feature branch back into the main branch, perpetuating a clean history.

---
title: Quiz-5
description: Quiz-5
duration: 60
card_type: quiz_card
---

# Question

Which git command would you use to combine the completed work from the "new-widget" branch into the master branch?

# Choices

- [ ] git checkout main
- [x] git merge new-widget
- [ ] git rebase main new-widget
- [ ] git push origin new-widget

---
title: GitHub Fork & Clone
description:
duration: 600
card_type: cue_card
---

### GitHub Fork & Clone

* Any public Git repository can be forked or cloned.
* A fork creates a completely independent copy of the Git repository.
* A Git clone creates a linked copy that will continue to synchronize with the target repository. (Changes made to the cloned repository cannot be merged with the original repository unless you are the collaborator or the owner of the repository)
* Fork is not a command in Git
* You can navigate to the landing page of the repository in your web browser and click on the Fork button on the repository's home page.
* For cloning a repository you can use `git clone <repo url>`

\
`Instructor Note:` Contributing to the original repository once we have made changes to forked repository has been covered in GitHub Desktop section.

---
title: Practice Coding Question(s)
description: 
duration: 300
card_type: cue_card
---

### Practice Coding Question(s)

You can pick the following question and solve it during the lecture itself.

This will help the learners to get familiar with the problem solving process and motivate them to solve the assignments.

<span style="background-color: pink;">Make sure to start the doubt session before you solve this question.</span>

Q. https://www.scaler.com/hire/test/problem/101607/