π Previous: π Homepage
π€ Topics Covered for Day 2
- π Introduction
- πΏ Branching in Git
- π Making Changes & Committing
- β
Pushing Changes
- π Cloning a Repository
- π΄ Forking a Repository
- π Opening a Pull Request (PR)
- π₯ Adding Collaborators
- π Merging the PR into Main
- β‘ Resolving Merge Conflicts
- π Summary & Cheatsheet
- π Hands-On Exercise
- Branching in Git
- What is a branch?
- Why use branches?
- Creating a branch:
git branch
, git checkout -b
- Switching branches:
git checkout
, git switch
- Best practices for naming branches
- Making Changes & Committing
- Editing files
- Staging and committing changes
- Pushing Changes
git push origin branch-name
- Cloning a Repository
- Cloning your own repo vs. a forked repo
git clone
command
- Next steps after cloning: branching, making changes, committing, pushing
- Forking a Repository
- What is forking?
- Why fork instead of clone?
- How to fork a repo on GitHub
- Adding the original repo as upstream (for syncing)
- Open a Pull Request (PR)
- What is a PR?
- How to open a PR on GitHub
- PR title and description
- Adding Collaborators (Alternative to Forking)
- How to add collaborators
- Permissions required
- Cloning as a collaborator
- Merging the PR into Main
- Reviewing and merging PRs
- Pulling merged changes locally
- Resolving Merge Conflicts
- What are merge conflicts?
- How to resolve them
Summary Table for Day 2
Topic |
Description/Goal |
Branching |
Work on features/changes without affecting main branch |
Making Changes |
Edit, stage, and commit code |
Pushing Changes |
Upload your branch to GitHub |
Cloning |
Get a local copy of a repo (forked or original) |
Forking |
Work independently on a copy of a repo |
Pull Requests |
Propose your changes for review and merging |
Collaborators |
Work directly if added as a team member |
Merging PRs |
Integrate changes into the main branch |
Merge Conflicts |
Handle conflicting changes between branches |
Tip:
- Forking is best for open source or when you donβt have write access.
- Adding as a collaborator is best for private/team projects.
- Branching is always recommended for safe
β‘οΈUp Next: πΏ Branching in Git