Englishবাংলা
SubscribeWrite
Latest
Big-O notation explained: time and space complexity for interviewsSoftware testing basics: the test pyramid and what to testClean code and code review habits that make you a better developerREST API design best practices: URLs, status codes and errorsJavaScript and TypeScript roadmap: from first script to full stackPython learning roadmap: from basics to real projectsRead documentation and debug like a developerFrontend developer roadmap: HTML, CSS, JavaScript and beyond

Git and GitHub for beginners: a daily workflow that works

Git saves the history of your code and lets teams work together. Learn the few commands and habits you will use every day.

••3 min read
A branching commit history merging back into main

Git is a version control system: it records the history of your project so you can see what changed, go back and work with others. GitHub (and GitLab, Bitbucket) is a website that hosts Git repositories and adds collaboration tools like pull requests. Git is the tool; GitHub is a place to store and share.

Core ideas

  • Repository (repo): your project folder plus its history.
  • Commit: a snapshot of your changes with a message.
  • Branch: a separate line of work, so you can experiment safely.
  • Remote: a copy of the repo on a server, usually called origin.
  • Clone, pull, push: copy a remote repo, fetch others' changes, send yours.

Files go through three places: your working directory (edits), the staging area (what will go into the next commit) and the repository (committed history).

Setup (once)

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

The daily loop

git status                  # what changed?
git add file.js             # stage a file (or: git add .)
git commit -m "Add login form validation"
git push                    # send to the remote
git pull                    # get others' changes
git log --oneline           # history
git diff                    # see unstaged changes

Write commit messages that say what and why, in the present tense: "Fix crash when the cart is empty". Make small, focused commits.

Start a project

git init                    # new repo in this folder
git clone https://github.com/user/repo.git    # copy an existing one

To publish a local repo, create an empty repo on GitHub, then:

git remote add origin <url>
git push -u origin main

Branches

git switch -c feature/search      # create and switch to a new branch
# ...work and commit...
git switch main
git merge feature/search          # bring the work into main
git branch -d feature/search      # delete the finished branch

Keep main working. Do new work on a branch.

The pull request workflow

This is how most teams work:

  1. Update main: git pull.
  2. Create a branch for your task.
  3. Commit your work and push the branch.
  4. Open a pull request (PR) on GitHub. Describe what and why.
  5. Teammates review, comment, and automated checks (tests) run.
  6. Fix feedback with more commits.
  7. Merge the PR, then delete the branch and pull main.

Merge conflicts

A conflict happens when two changes touch the same lines. Git marks them in the file:

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

Edit the file to the correct final text, remove the markers, then git add the file and git commit (or continue the merge or rebase). Do not panic. Pulling often keeps conflicts small.

Undoing mistakes

  • Unstage a file: git restore --staged file
  • Discard local edits to a file: git restore file (this loses the edits)
  • Fix the last commit message (not yet pushed): git commit --amend
  • Undo a pushed commit safely: git revert <commit> makes a new commit that reverses it.
  • Look before you destroy: commands like git reset --hard and force push (git push --force) can delete work or rewrite shared history. Avoid them on shared branches unless you are sure.
  • git reflog often lets you recover "lost" commits.

.gitignore and secrets

A .gitignore file lists what Git should not track:

node_modules/
.env
*.log
dist/

Never commit secrets such as passwords, API keys and private keys. Bots scan public repos within minutes. Removing a secret in a later commit does not remove it from history. If a secret is committed, revoke and rotate it immediately, then clean the history if needed.

Keep secrets in environment variables or a secrets manager, and commit an .env.example with fake values.

Good habits

  • Commit often, push regularly (it is also a backup).
  • Pull before you start work.
  • One purpose per branch and per PR.
  • Review the diff (git diff, git status) before every commit.
  • Use a clear README in every project.
  • Protect main on GitHub: require PR review and passing checks.
  • Turn on two-factor authentication for your account and use SSH keys or tokens.

Takeaway: learn status, add, commit, push, pull, branch and merge. Work on branches with pull requests, keep secrets out with .gitignore, and look before you use destructive commands.

Programming roadmaps series, Part 1 (getting started): 2 of 5. Previous: How to start programming: a realistic roadmap for beginners.

Keep reading