You've joined a new team. Your first task is to get the project code onto your machine from a remote repository and explore its current state.
The project has multiple branches. You need to understand how to view them, switch between them, and understand what HEAD means.
You are starting a brand new project. The first step is to initialize a Git repository to start tracking your files.
A clean, readable commit history is crucial for collaboration. Practice making small, logical, 'atomic' commits with clear messages.
You made changes to several files but want to discard them. Learn safe ways to undo uncommitted work.
You're working on a feature when a critical bug needs immediate attention. Use stash to temporarily save your work so you can switch contexts.
Learn to inspect your code changes and commit history effectively using git diff and git log.
Before merging or rebasing, you need to see what changes exist between branches. Learn to compare effectively.
Your local project is ready. Now it's time to connect it to a remote repository on a service like GitHub to back it up and collaborate with others.
Learn to properly configure .gitignore to exclude files you don't want to track, and how to handle files that were accidentally committed.
Master creating, switching, renaming, and deleting branches - the most frequent Git operations in daily development.
The standard workflow for developing a new feature is to create a dedicated branch. This keeps the 'main' branch clean and allows for code reviews before merging.
Your feature branch was created yesterday. Today, main has several new commits. Use rebase to build your feature on top of the latest main, keeping a clean linear history.
You have local commits on main, but a teammate pushed new commits to origin/main. Use git pull --rebase to avoid unnecessary merge commits.
You've been working on a feature, and in the meantime, someone else changed the same line of code on the 'main' branch. It's time to merge, and you need to resolve the conflict.
You want to contribute to an open-source project. Learn the fork workflow: create your own copy, make changes, and submit a pull request.
Your feature branch has messy commit history: 'WIP', 'fix typo', 'actually fix it'. Before submitting a PR, clean it up by squashing commits into one logical change.
After pushing your feature branch, a reviewer requests changes. Learn to amend your commit and update the pull request.
For complex PRs with multiple commits, use fixup commits to address review feedback, then automatically squash them with autosquash rebase.
You've made a commit you want to undo locally. git reset is the tool, but it has three modes: soft, mixed, and hard. Understanding them is key to avoiding data loss.
You've pushed a commit to a shared branch that introduced a bug. You can't use git reset because it rewrites history. The safe way is with git revert.
Disaster! You accidentally used git reset --hard and lost a commit. git reflog is your safety net, tracking all movements of HEAD, allowing you to recover.
You want to contribute to an open-source project. Learn the fork workflow: create your own copy, make changes, and submit a pull request.
1. In a fork workflow, what does 'origin' typically refer to?
2. What is the purpose of adding an 'upstream' remote in a fork workflow?
3. What is a Pull Request (PR)?