2.5.
2 Accessibility and Usability
When including inputs, it is an accessibility requirement to add labels alongside.
This is needed so those who use assistive technologies can tell what the input is
for. Also, clicking or touching a label gives focus to the label's associated form
control. This improves the accessibility and usability for sighted users, increases
the area a user can click or touch to activate the form control. This is especially
useful (and even needed) for radio buttons and checkboxes, which are tiny.
See above example under 2.4 and 2.5 how to associate the <label> with an
<input> element.
2.6 What is Git and why use it?, Git setup and config (git config), Creating
a local repository: git init
2.6.0 What is Git and why do we use it?
Git is a Version Control System (VCS), means Every developer has a full
copy of repo.
It helps keep track of every change you make to files in a project.
If something breaks, you can go back to an earlier version.
Multiple people can work on the same project without disturbing each
other’s work.
Git is widely used in the software industry to manage projects and
teamwork.
Key points:
Git runs on your local computer.
GitHub is a website (cloud) where Git projects can be stored and shared.
Together, Git + GitHub = teamwork + backup + tracking changes.
Git has four important areas:
1. Working Directory – Where you actually edit files (your project folder).
2. Staging Area (Index) – A temporary area where you put the changes you
want to commit.
3. Local Repository – The permanent history of commits stored on your
computer.
4. Remote Repository (GitHub/GitLab/Bitbucket) – The copy of your
repository stored on the server for sharing and collaboration.
120
Quick check: In VS Code, open the Terminal and run:
git –version
If you see a version (e.g., git version 2.45.x), you’re set.
2.6.1 First-time Git setup in VS Code (one-time)
1. Open VS Code → Terminal → New Terminal.
2. Set your identity (appears in commit history):
Creating a GitHub Account
1. Go to https://github.com/
2. Sign up with email → verify → choose username.
3. Create a new repository:
o Repository Name: web-project
o Description: " Learn Git from Scratch !! "
o Public → Add README.md → Create Repository.
121
122
We will use this GitHub Repo to push our project code remotely after few steps.
2.6.2 Creating a Local Repository
A local repository is a project folder on your computer that Git will track.
This is the first step before pushing anything to GitHub.
Using VS Code (Beginner-Friendly UI)
Create a project folder
Example: web-project
123
Open it in VS Code (File → Open Folder).
124
Create project files
Example: index.html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<title>My First GitHub Project</title>
</head>
<body>
<h1>Hello Git & GitHub</h1>
125
<p>Demo project pushed from VS Code </p>
</body>
</html>
Initialize Git (create local repository)
Where to Perform This Step?
126
This step is performed in your terminal/command prompt (VS Code
terminal or Git Bash) — not on GitHub’s website.
In terminal:
Use the commands:
Initialize the repository:
127
Using the command git init
This command creates a hidden .git folder, which means Git is now
tracking your project.
Add and commit files:
128
2.7 Tracking changes: add, commit, status, log,.gitignore basics,Practical
2.7.0 Add a Single File
If you only want to add one file to the staging area (for example, index.html):
git add index.html
Add Multiple Specific Files
You can also add more than one file at a time by naming them:
git add index.html style.css
Add All Files (Recommended when you want to add everything)
If you want to add all files in the project folder:
git add .
2.7.1 Commit the Changes
After adding files, you need to commit them with a message:
git commit -m "Initial commit with index.html"
129
A commit is like saving a snapshot of your project at that point in time.
Now, project file is saved in local repository.
130
Pull & Sync changes from GitHub into VS Code
Pull: download new commits and merge them into your local branch.
Fetch: check for new commits without merging.
3.0 Cloning and pulling repositories
3.0.0 Cloning repositories
When you clone a repository, you copy the repository from GitHub.com to your
local machine. You can clone a repository from GitHub.com to your local
131
computer to make it easier to fix merge conflicts, add or remove files, and push
larger commits.
3.0.1 Pulling a Repository
What is pulling?
Pulling means fetching the latest changes (commits, updates, new files) from
the remote GitHub repository and merging them into your local repository.
Where does it happen?
You perform git pull inside your local project folder (the one you cloned
earlier).
132
Command:
git pull origin main
origin refers to your GitHub repository.
main is the branch name (sometimes master or another branch).
When do we use pull?
If your team members (or you from another system) made changes on
GitHub, you run git pull to sync your local project with the latest version.
This avoids conflicts and keeps your work up-to-date.
In simple terms:
Clone = "Download the whole project to my computer."
Pull = "Update my local project with the latest changes from GitHub."
So Pull remote first, then push.
This way you combine your local and GitHub changes. Run:
If there are no conflicts, your local commit will be placed “on top” of the
remote commit.
Then push:
133
Run the command:
git push -u origin main
This means Upload my local main branch to the remote repository named origin,
and set up a tracking relationship so future pushes/pulls are easier.
To verify this, please refresh the GitHub repository and see the changes in
files available in repository.
134
3.1 GitHub repository structure and README.md
3.1.0 GitHub Repository Structure
When you create or work with a GitHub repository, you will notice some
important files and folders. Each has a specific purpose and makes your project
more professional and maintainable:
3.1.1 README.md
What is README.md?
A README.md file is written in Markdown format (file extension:
.md).
It provides an introduction and overview of your project so that visitors
can quickly understand:
o What the project is about
o How to install and run it
o Features and usage
o Contribution guidelines
o Credits and contributors
Example of a README.md file:
1. Project Title & Description
# My Web Project
A simple web project to demonstrate Git & GitHub basics.
The # symbol in Markdown means Heading 1.
Provide a clear project name and a one-line description.
2. Installation Instructions
## Installation
Clone the repo:
https://github.com/Firstyearpranshiverma-Educator/web-project.git
135
Open the folder and run:
npm install (if Node.js project)
Always guide users step by step on how to set up your project.
3. Usage Instructions
## Usage
Open `index.html` in your browser.
Show how to run the project after installation.
4. Contribution Guidelines
## Contribution
Anyone can fork this repository, create a new branch, make improvements, and
open a Pull Request for review.
Fork → Copy someone else’s repository into your own GitHub account.
You can make changes freely in your fork without affecting the original
project.
Later, you can create a Pull Request (PR) to merge your changes into the
original repository.
(We will discuss Fork and Pull Request in detail in upcoming lectures.)
5. Screenshots or Examples
## Screenshots
We can add images like images/demo.png or any other demo images here.
Visuals make your README attractive and easy to understand.
6. Credits & Contributors
##Credits & Contributors
- **Author / Maintainer: ** [Your Name](https://github.com/your-username)
- **Contributors: **
136
- [Contributor 1] (https://github.com/contributor1) – Feature XYZ
- [Contributor 2] (https://github.com/contributor2) – Bug fixes & testing
Special thanks to:
- Open-source libraries and frameworks used in this project
- Community members who gave feedback and suggestions
Explanation:
Author / Maintainer → The person who created or maintains the repo.
Contributor’s → People who added code, fixed bugs, improved docs, etc.
Special Thanks → Credit libraries, tutorials, or external help.
(GitHub also auto-generates a contributors list based on commits, but
mentioning key contributors manually is a good practice.)
Best Practice:
Always write a clear and meaningful README.md because it’s the first
impression of your project on GitHub.
Keep it organized, simple, and helpful for anyone who visits your
repository.
2. .gitignore
This file tells Git which files or folders should not be tracked or uploaded
to GitHub.
Example use cases:
o Ignoring dependencies like node_modules/ in Node.js projects
o Ignoring log files (.log)
o Ignoring environment configuration files (.env) for security
Example .gitignore content:
node_modules/
.env
*.log
3. LICENSE
This file specifies the license type under which your project is distributed.
137
It defines what other developers can and cannot do with your code (e.g.,
MIT, Apache 2.0, GPL).
Example:
o MIT License → Free to use, copy, modify with attribution
o GPL License → Derivative projects must also be open-source
Including a LICENSE file makes your project legally safe and encourages
contributions.
4. src/ (Source Code Folder)
The src/ directory usually contains the main source code of your project.
Example structure for a web project:
src/
├── index.html
├── style.css
├── script.js
└── images/
Keeping source files inside src/ makes your repository organized and
professional.
Key Takeaway
README.md → First impression (must be meaningful and well-written).
.gitignore → Keeps unnecessary files out of Git.
LICENSE → Defines usage rights of your project.
src/ → Main code lives here (clean and organized).
3.2 Basic collaboration terms: fork, pull request, branch (intro)
3.2.0 Basic Collaboration Terms: Fork
A Fork is a personal copy of someone else’s repository on your GitHub
account.
It allows you to experiment with changes without affecting the original
repository.
138
Commonly used in open-source projects where you don’t have write
access to the original repo.
Example:
Suppose there is a public repo:
👉 https://github.com/Pranshi10Verma/HTML-BEGINNERS-TO-ADVANCE
Step 1: Open the repository on GitHub
Go to the repo link in your browser.
At the top-right of the page, you’ll see a Fork button.
This button is used to create your own copy of the repo inside your GitHub
account.
👉 Think of Fork as “Save a copy to my account.”
Step 2: Click on Fork
Click the Fork button.
GitHub will ask where you want to fork the repository (if you belong to
multiple organizations, you can select your personal account).
Optionally, you can rename the repository during the fork.
Then click Create Fork.
139
You can click Fork (on GitHub UI) → it creates a copy in your account:
140
👉 https://github.com/Firstyearpranshiverma-Educator/Fork-HTML-
BEGINNERS-TO-ADVANCE
Now you can make changes safely in your copy.
141
3.2.1 Basic Collaboration Terms: Pull Request
What is Pull Request (PR)?
A Pull Request is a request to merge your changes from your fork (or branch)
back into the original repository.
It’s the main way developers contribute to open-source projects.
Clone Your Fork Locally
In VS Code:
Create a New Branch for Your Change
git switch -c update-readme
142
Make a Change
Open README.md and add a new line at the bottom:
This line was added as a demo for Pull Request.
143
Commit the Change
git add README.md
git commit -m "Added a demo line in README for PR"
Push the Branch to Your Fork
git push origin update-readme
144
Open a Pull Request
Go to your fork on GitHub.
You’ll see a message: “Compare & pull request”.
Click it.
1. GitHub shows a comparison view:
o Base repository → the original repo (octocat/Spoon-Knife).
o Head repository → your fork + branch (your-username/update-
readme).
2. Add a title and description.
145
3. Click Create Pull Request.
4. Add a comment for high readability. (not mandatory).
146
After that owner of the url https://github.com/Pranshi10Verma/HTML-
BEGINNERS-TO-ADVANCE received a pull request
you’ll see a Merge pull request button.
Click it → then click Confirm merge.
147
PR merged successfully.
Key Takeways:
Fork → Create personal copy of repo.
Clone → Bring fork to your computer.
Branch → Make safe changes.
Commit & Push → Upload to fork.
PR → Ask original repo owner to accept.
Merge → Changes officially added.
148
3.3 Branching: git branch, git checkout, git switch, merging
branches, handling merge conflicts
3.3.0 Branch
A Branch is a parallel line of development inside a repository.
By default, every repo has a branch called main (or master).
Developers create new branches to work on features, bug fixes, or
experiments without disturbing the main branch.
Let’s understand how to create branch, switching between branches,
making changes, and merging branches.
You can create new branches to work on features or fixes without
disturbing the main project.
Step 1: Create a Repository on GitHub
1. Log in to your GitHub account.
2. Click on New Repository.
3. Enter the repository name → Git Branch Demo.
4. Do not check the option “Initialize this repository with a README”.
5. Click Create Repository.
149
Step 2: Clone the Repository into VS Code
Open the VS Code and click on Clone Git Repository…
Then copy the url from github repo.
150
Then select the folder, where you want to clone it
151
Repository cloned successfully
152
Step 4: Create a new file named index.html and add the content:
Step 5: Initialize Git (if not already initialized)
In the VS Code terminal:
git init
This command initializes the folder as a Git repository.
153
Step 6: Make the First Commit
Step 7: Push the Code to GitHub
git branch -M main
154
Meaning:
git branch → command to manage branches.
-M → option that means move/rename branch (forcefully if needed).
main → the new name for the current branch.
So this command renames your current branch to main, even if a branch with
that name already exists (it will overwrite).
git push -u origin main
Meaning:
git push
Uploads your local commits (from your computer) to a remote repository
(like GitHub).
origin
This is the short name (alias) for the remote repository you linked earlier
using
git remote add origin <URL>
By convention, the first/primary remote is always called origin.
main
The branch you want to push. Here it means: “Push the local main
branch to the remote repository’s main branch.”
155
-u (or --set-upstream)
This sets a tracking relationship between your local main branch and
the remote main branch.
After this first time, you don’t need to write git push origin main again.
You can simply run:
git push
and Git will know where to push by default.
GitHub showing main branch with index.html
Step 7: Check the Current Branch
Output shows all branches. The active branch has a * symbol in front of it (e.g.,
* main).
156
Step 8: Create a New Branch
Using the command: git branch feature1
This creates a new branch named feature1.
Step 9: Switch to the New Branch
There are two methods:
Old method (checkout):
git checkout feature1
New method (recommended):
git switch feature1
157
Now you are working inside the feature1 branch.
Step 10: Make Changes in index.html
Open your index.html and add one more line under the <p> tag. For example:
158
Step 11: Commit the Changes in feature1 Branch
Run these commands:
git add index.html
git commit -m "Updated index.html in feature1 branch"
Commit message for feature1 branch.
Step 12: Switch Back to Main Branch
git switch main
Open index.html now → you will notice that the extra line is not visible here,
because it only exists in the feature1 branch.
Step 13: Merge feature1 into main
git merge feature1
159
Now the changes from feature1 are merged into main.
Check index.html again → you will see the new line has appeared.
Step 14 (Optional): Delete the Branch
git branch -d feature1
👉 If you don’t need the branch anymore, you can delete it safely.
That completes our first branching + switching + merging demo.
Step 15 Merge Conflict Demo (with index.html)
From main branch, create a new branch:
git switch -c feature2
160
This creates and switches to a new branch feature2.
Step 16: Modify index.html in feature2
Change the second <p> line like this:
<p>This is a sample HTML document. Edited in feature2 branch</p>
161
Commit this change:
git add index.html
git commit -m "Edited index.html in feature2 branch"
Commit in feature2 branch
Step 17: Switch to main and Make a Different Change
Switch back to main: git switch main
162
Now edit the same line but write something different:
<p>This is a sample HTML document. Updated in main branch</p>
Commit this change:
git add index.html
git commit -m "Edited index.html in main branch"
Commit in main branch
163
Step 18: Try Merging feature2 into main
Now merge:
git merge feature2
Git will detect that both branches modified the same line differently → this
creates a merge conflict.
Merge conflict message in terminal and The index.html file will show conflict
markers like this:
<<<<<<< HEAD → your current branch (main) version
======= → separator
>>>>>>> feature2 → incoming branch version
Step 20: Resolve the Conflict Manually
Decide how you want the final version to look.
For example, keep both lines combined:
<body>
<h1>Hello, World!</h1>
<p>This is a sample HTML document. Updated in main branch & feature2
branch</p>
164
<p>Change made in feature1 branch</p>
</body>
Step 21: Mark the Conflict as Resolved
git add index.html
git commit -m "Resolved merge conflict between main and feature2"
Merge conflicts occur when two branches edit the same part of a file
differently.
Git cannot decide automatically, so it asks you to resolve.
You open the file, remove the conflict markers (<<<<<<<, =======,
>>>>>>>), and keep the correct content.
After resolving, you stage and commit the file.
Summary of Key Commands:
Create a new branch: git branch <branch-name>
Switch to a branch: git checkout <branch-name>
Create and switch in one step: git checkout -b <branch-name>
Stage changes: git add <file-name> or git add .
Commit changes: git commit -m "message"
165
List all branches: git branch
Merge a branch into the current branch: git merge <branch-name>
Delete a branch: git branch -d <branch-name>
Push changes: git push origin <branch-name>
3.4 GitHub collaboration workflow, Best practices for commits,
branches, and messages
3.4.0 Collaboration Workflow in GitHub
When working in a team project, multiple developers collaborate. The most
common workflow is:
Step 1: Fork (for open-source projects) / Clone (for team repos)
If you’re contributing to someone else’s repository → Fork it into your
account.
If you’re in a team and already have access → Clone the repo.
# Forked repo (on GitHub) → then clone it
git clone https://github.com/your-username/project.git
cd project
(Already discussed with eg.)
Step 2: Create a New Branch for Your Work
Never work directly on the main branch.
git checkout -b feature/login-page
Real-life example:
Project repo = E-commerce website
You → creating login page feature → branch name = feature/login-page
166
Step 3: Make Changes Locally
Edit files, add new features, or fix bugs.
Stage changes:
git add .
Commit with a meaningful message:
git commit -m "Added login form with validation"
Step 4: Push the Branch to GitHub
git push origin feature/login-page
Now your branch is visible on GitHub.
Step 5: Create a Pull Request (PR)
Go to GitHub → Open a Pull Request from feature/login-page → main.
Describe what you did.
Example PR message:
"Implemented login page with form validation and session handling."
Step 6: Code Review & Discussion
Teammates review your code.
They can request changes or approve.
Step 7: Merge PR
Once approved → merge into main.
If conflicts appear → resolve with:
git pull origin main
# Fix conflicts in files
git add .
git commit -m "Resolved merge conflicts"
167
git push origin feature/login-page
Step 8: Delete Branch (after merge)
git branch -d feature/login-page # local
git push origin --delete feature/login-page # remote
3.4.1 Best Practices for Commits, Branches, and Messages
A. Branching Best Practices
Use descriptive names:
o feature/login-page
o bugfix/cart-issue
o hotfix/security-patch
One branch = One task/feature
B. Commit Best Practices
Small, frequent commits (atomic commits).
Avoid large commits like: "updated everything".
Good messages:
o "Added search functionality in product list"
o "Fixed bug in checkout page discount calculation"
Bad messages:
o "Fixed", "Update code", "Work done"
C. Pull Request Best Practices
Clear title + description.
Link issue number (if using GitHub issues).
Request review from teammates.
168
D. General Workflow Best Practices
1. Always pull latest changes before starting work:
2. git pull origin main
3. Work in your own branch.
4. Keep commits clean.
5. Write meaningful PR descriptions.
6. Delete merged branches to avoid clutter.
3.4.2 Real-Life Example Flow
Team Project: E-commerce Website
Alice creates feature/login-page.
Bob creates feature/cart-system.
Both work separately.
They push branches → make PR → merge into main.
The main branch always has stable, production-ready code.
3.4.3 Diagram of GitHub Collaboration Workflow
This workflow ensures smooth collaboration, prevents conflicts, and keeps the
main branch stable.
169
