Git and GitHub for Beginners: Commands, Branching, Conflicts and Interview Questions

Why Git matters

Git is the version control system used by almost every software team. It records the history of your code, lets many people work in parallel and lets you undo mistakes. GitHub (like GitLab and Bitbucket) hosts Git repositories online. Employers expect Git skills from day one, and your GitHub profile is often looked at before the interview (portfolio projects). Interviews ask both practical questions ("how do you undo a commit?") and conceptual ones ("merge vs rebase").

1. The mental model

Git stores snapshots of your project, not file-by-file differences. Your files live in three areas:

1. Working directory: the files you edit
2. Staging area (index): the changes you have chosen for the next commit
3. Repository: the committed history

The flow: edit, git add (stage), git commit (save a snapshot), git push (send to a remote). Each commit has a unique id (hash), a message, an author and a pointer to its parent. A branch is just a movable pointer to a commit, and HEAD points to the branch (or commit) you are on.

Git is distributed: every clone holds the full history, so you can commit offline.

2. First-time setup and the daily loop

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

git init                       # start a repo in the current folder
git clone <url>                # copy an existing repo

git status                     # what changed?
git add file.txt               # stage one file   (git add -p to stage in pieces)
git commit -m "Add job search filter"
git log --oneline --graph      # compact history
git diff                       # unstaged changes; git diff --staged for staged ones

Write good commit messages: a short imperative summary ("Fix login redirect", not "fixed stuff"), one logical change per commit. Add a .gitignore so node_modules, build output, .env files and secrets are never committed.

3. Remotes: GitHub

git remote add origin https://github.com/you/project.git
git push -u origin main        # first push, sets upstream
git pull                       # fetch + merge
git fetch                      # download changes without merging

git fetch only updates your view of the remote; git pull also integrates the changes (fetch plus merge, or plus rebase with --rebase). Authenticate with a personal access token or SSH key. Never commit passwords, API keys or tokens. If you do, revoke them immediately; deleting the commit is not enough because the history keeps it.

4. Branching and merging

git switch -c feature/saved-jobs     # create and move to a new branch
# ...work and commit...
git switch main
git merge feature/saved-jobs         # bring the work into main
git branch -d feature/saved-jobs     # delete the merged branch

• Fast-forward merge: main simply moves forward when it has no new commits of its own
• Three-way merge: Git creates a merge commit combining two diverged histories
• Rebase: replays your commits on top of another branch, giving a linear history

git switch feature/saved-jobs
git rebase main                      # replay my commits on top of the latest main

Merge vs rebase: merge preserves true history and is safe for shared branches; rebase makes history cleaner but rewrites commits, so never rebase commits that others have already pulled. A typical rule: rebase your own local feature branch before opening a pull request, merge when integrating into shared branches.

Common team workflows: GitHub Flow (short-lived feature branches and pull requests into main), Git Flow (develop, release and hotfix branches) and trunk-based development (very small, frequent merges).

5. Resolving merge conflicts

A conflict happens when two branches change the same lines. Git stops and marks the files:

<<<<<<< HEAD
const limit = 10;
=======
const limit = 20;
>>>>>>> feature/saved-jobs

To resolve: open the file, decide the correct final content (keep one side, or combine), delete the markers, then:

git add path/to/file
git commit            # for a merge; use git rebase --continue during a rebase

git merge --abort or git rebase --abort returns you to the state before. Reduce conflicts with small branches, frequent pulls and clear ownership of files.

6. Undoing things (very commonly asked)

Situation	Command
Discard changes in a file (not staged)	git restore file
Unstage a file	git restore --staged file
Fix the last commit message or add a forgotten file	git commit --amend (only if not pushed)
Undo a commit but keep the changes	git reset --soft HEAD~1
Undo a commit and unstage the changes	git reset --mixed HEAD~1 (the default)
Undo a commit and discard the changes	git reset --hard HEAD~1 (destructive)
Undo a pushed commit safely	git revert <hash> (creates a new commit that reverses it)
Recover "lost" commits	git reflog, then git switch -c rescue <hash>

reset vs revert: reset moves the branch pointer back and rewrites history (fine locally, risky after pushing); revert adds a new commit and keeps history intact (safe for shared branches).

git stash temporarily shelves uncommitted changes (git stash pop brings them back), and git cherry-pick <hash> copies one commit to your current branch.

7. Pull requests and code review

A pull request (PR) proposes merging your branch and is where review happens.

• Keep PRs small and focused with a clear title and description (what, why, how to test)
• Link the issue, add screenshots for UI changes and make sure tests pass
• Respond to review comments politely and push fixes as new commits
• Review others' code kindly and specifically: explain the reason for a suggestion

Teams often protect main so it requires reviews and passing checks (CI), which run tests automatically on every push.

8. Useful extras

• git log -p, git blame file (who changed each line), git show <hash>
• Tags mark releases (git tag v1.0.0)
• Submodules and monorepos at a definition level
• git bisect finds the commit that introduced a bug using binary search
• .gitattributes, hooks (pre-commit checks) and signing commits are nice to know

9. Making your GitHub profile work for you

• Pin your 3 to 6 best repositories
• Every project needs a README: what it does, a screenshot or demo link, the tech stack, how to run it, and what you learned
• Commit regularly with meaningful messages; a graph of steady work looks better than one huge dump
• Do not include copied tutorial projects without changes; add your own features
• Add a profile README with a short introduction and links
• Make sure no secrets are in any repository
• Link your GitHub from your resume and LinkedIn

10. Common mistakes

• Committing node_modules, .env files or large binaries
• Working directly on main and making giant commits
• Using git reset --hard or git push --force without understanding them
• Rebasing shared branches
• Vague messages like "update" and "final final"
• Resolving conflicts by blindly choosing one side without running the code

11. Frequently asked interview questions

1. What is Git? How is it different from GitHub?
2. Explain the working directory, staging area and repository
3. git fetch vs git pull
4. git merge vs git rebase; when would you use each?
5. What is a merge conflict, and how do you resolve one?
6. git reset vs git revert; --soft vs --hard
7. How do you undo a pushed commit?
8. What is git stash? What is cherry-pick?
9. What is a detached HEAD?
10. How do you recover a deleted branch or lost commit? (reflog)
11. What is .gitignore, and why does it matter?
12. What branching strategy have you used?

12. Practice plan

Create a repository, make five commits on a branch, merge it, then deliberately create and resolve a conflict between two branches. Practise reset, revert, stash and reflog on a throwaway repo. Then host a project on GitHub with a polished README. Git is a prerequisite for Docker and CI/CD and for working in any team.