Git and GitHub: the team workflow
Learn the Git workflow used by real teams: commits, branches, pull requests, merge conflicts and safe undo. It is the starting point of every CI/CD pipeline and a common interview topic.
What you'll do: use Git the way real teams do. You will make commits, work on a branch, push to GitHub, open a pull request, resolve a merge conflict and undo mistakes safely. The same flow is used in almost every company, and CI/CD pipelines later in this track start from a Git push.
Prerequisites: Git installed (check with git --version; download from git-scm.com if missing), a free GitHub account and a terminal (see *Linux command line essentials* for basics). Using Git for solo projects is fine; this lesson focuses on teamwork.
The mental model
Git saves snapshots of your project. Each snapshot is a commit with a message, an author and a pointer to the previous commit. A branch is just a movable label pointing at a commit, so creating one is instant and cheap. GitHub is a website that hosts a copy of your repository (a remote, usually called origin) and adds collaboration features: pull requests, reviews, issues and Actions.
A file goes through three places: your working folder (where you edit), the staging area (what you chose to include in the next commit, using git add) and the repository (saved commits).
Commands you will use every day
| Command | What it does |
|---|---|
git status | Show changed, staged and untracked files (use it constantly) |
git add file | Stage a file for the next commit |
git commit -m "message" | Save the staged changes as a commit |
git log --oneline | Short history of commits |
git diff | Show unstaged changes line by line |
git switch -c name | Create and move to a new branch |
git push and git pull | Send your commits to GitHub / fetch and merge others' commits |
Set up and make your first commits
git config --global user.name "Asha Rao"
git config --global user.email "asha@example.com"
git config --global init.defaultBranch main
mkdir brew-bean-notes
cd brew-bean-notes
git initThe first three lines are one-time setup: your name and email go on every commit. git init turns the folder into a repository (it creates a hidden .git folder).
# Brew & Bean menu
- Espresso: 120
- Cappuccino: 180
- Cold Brew: 220
git status
git add menu.md
git commit -m "Add first version of the menu"
git log --onelinea1b2c3d Add first version of the menuWrite commit messages in the imperative and say what and why: "Fix price rounding in order total" is useful, "changes" or "final2" is not. Small, focused commits are easier to review and to undo.
Never commit what shouldn't be shared
A .gitignore file lists files Git must not track: dependencies, build output, local settings and, above all, secrets such as .env files and API keys.
node_modules/
__pycache__/
.venv/
.env
*.log
dist/
Leaked secrets
If you commit a password or API key, deleting it in the next commit does not help: it stays in the history, and bots scan GitHub for leaked keys within minutes. Treat the key as stolen, revoke it at the provider and create a new one. Prevent this by adding .env to .gitignore before the first commit.
Work on a branch and push to GitHub
On a team you never work directly on main. You create a branch for each change, push it, and ask teammates to review it through a pull request (PR). First create an empty repository on github.com named brew-bean-notes (do not tick 'add a README'). Then connect your local repository to it.
git add .gitignore
git commit -m "Add gitignore"
git remote add origin https://github.com/YOUR-USERNAME/brew-bean-notes.git
git push -u origin maingit remote add saves the GitHub address under the name origin. -u links your local main to origin/main, so later a plain git push works. Git will ask you to sign in; GitHub no longer accepts account passwords here, so use the browser sign-in offered by Git Credential Manager, a personal access token, or the GitHub CLI command gh auth login.
git switch -c add-filter-coffee
Creates the branch add-filter-coffee and moves you onto it.
# Brew & Bean menu
- Espresso: 120
- Cappuccino: 180
- Cold Brew: 220
- Filter Coffee: 80
git add menu.md
git commit -m "Add Filter Coffee to the menu"
git push -u origin add-filter-coffeeThe pull request flow
- 1Open your repository on github.com. A yellow banner offers Compare & pull request; click it.
- 2Write a title and a short description: what changed and why, and how a reviewer can check it.
- 3Click Create pull request. A teammate reads the changes, leaves comments, and approves.
- 4If checks (tests from CI) are configured, wait for them to pass.
- 5Click Merge pull request, then Delete branch (the work is now in
main). - 6Back in your terminal:
git switch mainthengit pullto get the merged result.
Small PRs win
Keep pull requests small (ideally one idea, under a few hundred changed lines). Small PRs get reviewed faster and break less. Many teams also protect main with a branch protection rule so changes can only arrive through a reviewed PR with passing checks.
Merge conflicts: not scary
A conflict happens when two branches change the same lines and Git cannot decide which to keep. Git stops and marks the file. You choose the final text, then finish the merge. Let us create one on purpose.
git switch main
git switch -c change-cold-brew
# edit menu.md: change the Cold Brew line to 230
git commit -am "Raise Cold Brew price to 230"
git switch main
# edit menu.md: change the same line to 240
git commit -am "Raise Cold Brew price to 240"
git merge change-cold-brewcommit -am stages changes to already-tracked files and commits in one step. The merge now stops with a conflict.
Auto-merging menu.md
CONFLICT (content): Merge conflict in menu.md
Automatic merge failed; fix conflicts and then commit the result.<<<<<<< HEAD
- Cold Brew: 240
=======
- Cold Brew: 230
>>>>>>> change-cold-brew
Between <<<<<<< HEAD and ======= is your current branch (main). Between ======= and >>>>>>> is the incoming branch.
Resolve a conflict
- 1Open the file and decide what the final text should be (it may be one side, the other, or a mix).
- 2Delete the three marker lines (
<<<<<<<,=======,>>>>>>>) so only the final text remains. - 3Run
git add menu.mdto tell Git the conflict is resolved. - 4Run
git commit(Git suggests a merge message) to finish. - 5Run your tests or the app to check the result still works.
To avoid painful conflicts: pull often, keep branches short-lived and talk to teammates before both editing the same file. Some teams use git rebase to replay their branch on top of the latest main for a cleaner history; learn it after you are comfortable with merging.
Undoing things safely
Which undo?
| Situation | Command |
|---|---|
| I edited a file and want to throw the edit away | git restore menu.md |
| I staged a file by mistake | git restore --staged menu.md |
| My last commit has a typo in the message and is NOT pushed | git commit --amend -m "new message" |
| A commit is already pushed and was wrong | git revert a1b2c3d (creates a new commit that undoes it) |
| I want to see what changed before I decide | git diff and git log -p |
Dangerous commands
git reset --hard and git push --force can destroy work, yours and your teammates'. Prefer git revert for anything already shared. If you do need to force-push your own branch, use git push --force-with-lease, which refuses to overwrite commits you have not seen.
I am using Git on [Windows/macOS/Linux]. I ran this command: [command]. Git printed this message: [paste message]. My goal is: [what you want]. Explain what happened in plain English, then give the safest commands to fix it. Tell me if any command could lose work, and how to back up first (for example with a new branch).What to expect: A good answer explains the cause first, suggests git status or git log to inspect, and flags destructive commands such as reset --hard with a backup step.
How this comes up in interviews
Expect questions like: the difference between merge and rebase, how to undo a pushed commit (revert), what a pull request is for, what git fetch does compared with git pull (fetch only downloads; pull fetches and merges), and how you handled a merge conflict. Have a short real story ready from your own projects. Your GitHub profile is also read by recruiters, so write clear commit messages and a README.
Try it: Do the full team flow with a friend
Make a repository with a README on GitHub and add a friend as collaborator (Settings, Collaborators). Each of you creates a branch, edits the same line of the README, and opens a pull request. Merge the first PR, then update and resolve the conflict on the second.
Self-check
- I can explain working folder, staging area and repository
- I never commit .env files or keys, and my .gitignore exists from the first commit
- I work on branches and merge through pull requests
- I can read conflict markers and resolve them
- I know revert is for shared history and reset --hard is dangerous
Key takeaways
- Commits are snapshots, branches are cheap labels, GitHub hosts the shared remote called
origin. - The team flow: branch, commit, push, pull request, review, merge, pull.
- Use
.gitignorefrom day one; a committed secret must be revoked, not just deleted. - A conflict means you decide the final text: edit, remove the markers,
git add,git commit. - Undo with
restore(local edits),amend(unpushed commit) andrevert(pushed commit).
Check yourself
Finishing the quiz marks the lesson as done.
1. What does git add do?
2. You accidentally committed an API key and pushed it. What is the correct response?
3. Why do teams use pull requests instead of pushing straight to main?
4. A commit that is already pushed and shared has a bug. Which is the safest fix?
5. What do the lines <<<<<<<, ======= and >>>>>>> in a file mean?
Saved on this device. Create a free account to keep it on every device.
Practise this with Sam
A real mock interview, out loud, with an honest scorecard. Free to start.