Git and GitHub for Absolute Beginners: The Handful of Commands You Will Really Use Every Day

Every developer has a story about overwriting a file, losing a day of work or emailing "final_v3_REALLYFINAL.zip" to a colleague. Git exists so that never happens again. It records every change, lets you try ideas on safe branches and makes teamwork possible. This teaches the Git you'll actually use daily, in the order you need it.

The idea

• Git runs locally and tracks history. GitHub hosts repositories online.
• The core loop: edit, stage, commit, push.
• A branch for every feature, a pull request for review.
• Commit small and often with clear messages.

Install and configure

Download Git from git-scm.com (Windows, macOS, Linux) and tell it who you are:

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

Create a free GitHub account and set up SSH keys or a personal access token so you can push securely. Use a strong unique password and two-factor authentication, see our password guide.

Core concepts in plain English

• Repository (repo): a project folder with its full history.
• Working directory: the files you see and edit.
• Staging area: a waiting room where you choose which changes go into the next commit.
• Commit: a saved snapshot with a message.
• Branch: a parallel line of work so experiments don't affect the main code.
• Remote: a copy of the repo on a server like GitHub (usually called origin).
• Merge: combining branches.
• Pull request (PR): a proposal to merge your branch, with review and discussion.

Your first repository

mkdir my-site
cd my-site
git init
echo "# My Site" > README.md
git status
git add README.md
git commit -m "Add README"
git log --oneline

git init created a repo, git add staged your file, git commit saved a snapshot and git log shows the history.

The daily loop

1. Edit files.
2. git status shows what changed.
3. git diff shows the exact line changes.
4. git add file.js (or git add . for everything, after checking status).
5. git commit -m "Clear, specific message".
6. git push to upload to GitHub.

Good commit messages

• A short summary in the imperative: "Fix cart total rounding".
• One logical change per commit.
• Explain why, not only what, when it isn't obvious.

Files you shouldn't track

Make a .gitignore listing things like node_modules/, .env, build folders and OS files. Never commit secrets like API keys or passwords. If you do, rotate them immediately.

Connect to GitHub

# create an empty repo on GitHub first, then:
git remote add origin git@github.com:yourname/my-site.git
git branch -M main
git push -u origin main

To work on an existing project, clone it:

git clone https://github.com/owner/project.git
cd project

Branching, the safe way to work

git switch -c feature/contact-form    # create and move to a new branch
# ...edit, add, commit...
git push -u origin feature/contact-form

• git branch: list branches.
• git switch main: move to main.
• git merge feature/contact-form: merge into the current branch.
• git branch -d feature/contact-form: delete a merged branch.

The pull request workflow

1. Update main: git switch main, then git pull.
2. Branch for one task: git switch -c fix/login-bug.
3. Commit small, logical changes.
4. Push the branch.
5. Open a pull request saying what changed, why and how to test.
6. Teammates comment. You push fixes to the same branch.
7. Merge once approved and checks pass. Delete the branch.

Tip: add automated tests and checks (continuous integration) so every PR is verified before merging.

Staying in sync

git fetch              # download changes without merging
git pull               # fetch and merge
git pull --rebase      # fetch and replay your commits on top (cleaner history)

Resolving merge conflicts

A conflict happens when two branches change the same lines. Git marks the file:

<<<<<<< HEAD
your version
=======
their version
>>>>>>> feature/other

1. Open the file and decide what the final code should be.
2. Remove the marker lines.
3. Run tests.
4. git add the file, then git commit (or git rebase --continue).

Our free diff checker is handy for comparing two versions of text or code.

Undoing mistakes

Be careful with git reset --hard and force pushes. They can destroy work and rewrite shared history. When in doubt, make a backup branch first.

Best practices

• Commit early and often, push at least daily.
• Keep branches short-lived.
• Protect main: require pull requests and passing checks.
• Never commit secrets or large binary files.
• Write helpful READMEs.
• Meaningful branch names like feature/, fix/, docs/.
• Review your own diff before opening a PR.

GitHub features worth knowing

• Issues and projects for tracking work.
• Actions for automated tests and deployments.
• Pages for free static hosting.
• Dependabot and security alerts for vulnerable dependencies.
• Forks and open source: fork, change, open a PR. A great way to build a portfolio. See our web developer roadmap.

Practice plan

1. Create a repo and make five commits with good messages.
2. Branch, change something, push it and merge through a pull request on your own repo.
3. Create a deliberate conflict and resolve it.
4. Fork a beginner-friendly open-source project and fix a typo.

Engineers who work this way

At Node-devs every project uses Git, pull requests, code review and automated checks, and clients receive the full repository. Learn more about our development process or talk to us about your project.