Git and GitHub for Beginners: Commits, Branches and Pull Requests

Core Git terms: repository, commit, staging area and branch

• Repository (repo): a project folder that Git tracks, with its full history stored in a hidden .git folder.
• Commit: a saved snapshot of the project with a message, an author and a unique ID (a hash such as a1b2c3d).
• Staging area: the list of changes you have chosen to include in the next commit. It lets you commit some edits and leave others for later.
• Branch: a movable pointer to a line of commits. The default branch is usually called main; you create other branches for features and fixes.
• Merge: combining the history of one branch into another.
• Remote: a copy of the repository on another machine, usually GitHub, named origin by default.

Git and GitHub are not the same thing. You can use Git with no internet connection at all, and other services such as GitLab and Bitbucket also host Git repositories.

How Git works: working directory, staging and history

Every file change moves through three places. You edit files in the working directory, choose changes with git add to put them in the staging area, and record them permanently with git commit into the repository history. Pushing sends those commits to a remote; pulling brings other people's commits down.

git config --global user.name "Asha Verma"
git config --global user.email "[email protected]"
git config --global init.defaultBranch main

mkdir portfolio && cd portfolio
git init
git status

The first three commands run once per computer and set the name and email attached to your commits, and the default branch name for new repositories. git init turns the current folder into a repository, and git status shows which files are untracked, modified or staged. Run git status often; it is the quickest way to know where you are.

Everyday Git commands with examples

git add index.html style.css      # stage specific files
git add .                         # stage every change in this folder
git commit -m "Add home page layout"
git log --oneline                 # short history, newest first
git diff                          # unstaged changes
git diff --staged                 # staged changes, ready to commit

git branch                        # list branches
git switch -c contact-form        # create a branch and switch to it
git switch main                   # go back to main
git merge contact-form            # merge the branch into main

To work with GitHub, you connect your local repository to a remote, or clone an existing one:

git clone https://github.com/your-username/portfolio.git
git remote add origin https://github.com/your-username/portfolio.git
git push -u origin main           # first push; -u remembers the upstream
git push                          # later pushes
git fetch                         # download new commits without changing your files
git pull                          # fetch and then merge into your current branch

Keeping files out of Git with .gitignore and protecting secrets

A .gitignore file in the project root lists files and folders Git should not track, such as dependencies, build output, logs and local configuration.

# Dependencies
/vendor/
/node_modules/

# Environment and secrets
.env

# Logs and editor files
*.log
.DS_Store
.vscode/

Never commit secrets such as passwords, API keys or database credentials. Keep them in an .env file that is ignored, and commit a .env.example with blank values so others know which settings exist. If a secret is ever pushed, deleting it in a new commit is not enough because it stays in the history: revoke or rotate the key immediately, then clean up. This matters especially for PHP security and for database passwords used with MySQL.

Resolving a merge conflict

A conflict happens when two branches change the same lines of a file differently and Git cannot decide which version to keep. Git stops the merge and marks the file:

<<<<<<< HEAD
<h1>Welcome to Fresh Bakes</h1>
=======
<h1>Fresh Bakes, Pune</h1>
>>>>>>> update-heading

1. Run git status to list the files with conflicts.
2. Open each file and find the markers. The part above ======= is your current branch; the part below is the incoming branch.
3. Edit the section into the final version you want and delete all three marker lines.
4. Save, then run git add on the file to mark it as resolved.
5. Run git commit to complete the merge, and test the page before pushing.

If you want to start again, git merge --abort returns the branch to its state before the merge. Small, frequent merges keep conflicts small.

The pull request workflow on GitHub

Teams rarely commit straight to main. Instead, each change goes on its own branch and is reviewed through a pull request (PR) before it is merged.

1. Update your local main with git switch main and git pull.
2. Create a branch for one change, for example git switch -c fix-navbar-links.
3. Make small commits as you work, then push the branch with git push -u origin fix-navbar-links.
4. On GitHub, open a pull request from your branch into main. Describe what changed, why, and how to test it.
5. Reviewers comment on the code; you push further commits to the same branch to address them, and automated checks run on each push.
6. Once approved, the PR is merged into main, and you can delete the branch.

This workflow suits every kind of project, from a WordPress theme to a framework-based app organised around the MVC pattern.

Good commit messages and undoing changes safely

A good commit message has a short summary line in the imperative mood, such as "Fix broken link in footer", ideally around 50 characters, followed by a blank line and an optional body explaining why the change was needed. Each commit should contain one logical change.

Practical exercise: publish a project with a pull request

1. Create a folder with an index.html page built with semantic HTML, run git init, and make your first commit on main.
2. Add a .gitignore that excludes an .env file, and confirm with git status that .env is not listed.
3. Create an empty repository on GitHub, add it as origin and push main.
4. Create a branch called add-styles, add a stylesheet using CSS, commit and push the branch.
5. Open a pull request on GitHub, review your own diff, and merge it. Then pull main locally.

You are done when GitHub shows at least two commits on main, one merged pull request, and no .env file anywhere in the repository. The PHP Foundation course uses version control like this throughout its projects.

Common mistakes

• Committing passwords, API keys or .env files, which stay in the history even after deletion.
• Working directly on main for every change instead of using short-lived branches.
• Writing vague commit messages such as "update" or "fix stuff" that explain nothing later.
• Using git reset --hard or force-pushing on a branch other people use, which rewrites shared history.
• Leaving conflict markers in a file after resolving a merge, which breaks the page or script.
• Running git add . without checking git status, and committing files that were never meant to be tracked.

Frequently asked questions