Computers & Electronics
199,904 views
25 min · 2 min read
7 steps
Intermediate

How to set up Git, create a repository, and commit code locally

Setting up Git and committing code locally is a small, reliable skill that pays off immediately. In about 10–20 minutes you can install Git, create a repository, and make your first commits so your work is tracked and easy to manage. Follow these clear steps to get a solid local workflow going.

Verified by pleasexplain editors
  1. Step 1: Install Git on your system

    Download and install Git for your operating system from the official source or use your package manager. On macOS use Homebrew: brew install git; on Ubuntu: sudo apt update && sudo apt install git; expect 2–5 minutes for installation. Installing ensures you have the git command-line tools and basic configuration files.

    [Illustration: computer screen showing terminal with git --version output and installer progress]

  2. Step 2: Set your identity

    Configure your name and email so commits are attributed correctly: git config --global user.name "Your Name" and git config --global user.email "you@example.com". Run git config --global --list to verify; this takes about 1–2 minutes and ensures readable commit metadata.

    [Illustration: terminal showing git config commands and output listing name and email]

  3. Step 3: Choose a project folder

    Create or pick a local directory for your project: mkdir ~/projects/my-app && cd ~/projects/my-app. Keep project folders organized—one per repository—and confirm you have write permission; this step should take under a minute and sets a clear workspace.

    [Illustration: file explorer with a highlighted projects folder and terminal showing mkdir command]

  4. Step 4: Initialize a Git repository

    Run git init in your project root to create a .git folder and start version control; expect under 10 seconds. Initializing converts an ordinary folder into a tracked repository so you can record changes and create commits.

    [Illustration: terminal showing git init and .git directory appearing in file list]

  5. Step 5: Create a .gitignore file

    Add a .gitignore listing files to exclude (for example: node_modules/, .env, *.log). Create it with a text editor and include at least 5 common patterns for your language or framework; this prevents committing unwanted or sensitive files and usually takes 1–3 minutes.

    [Illustration: text editor window showing .gitignore contents like node_modules/ and .env]

  6. Step 6: Stage files for commit

    Add files to the staging area with git add filename or git add . to add everything (use cautiously). Use git status to review staged changes; staging lets you craft focused commits and typically takes under a minute per change set.

    [Illustration: terminal showing git status and git add . followed by staged files list]

  7. Step 7: Commit changes with a message

    Commit staged changes: git commit -m "Short, descriptive message". Write concise messages (50 characters or fewer summary and optional longer body). Commit often—every logical change—and expect each commit to take 30–90 seconds to prepare and run.

    [Illustration: terminal showing git commit -m and the commit summary output]


  • Use clear commit messages starting with a verb and 50 characters max for the summary.
  • Run git status and git diff before committing to avoid accidental files and review changes; spending 30–60 seconds saves headaches.
  • Create small, focused commits that change a single concern—aim for 5–20 files or 100–300 lines max per commit when possible.
  • Use branches: git checkout -b feature/x to isolate work; branch creation takes less than a second.
  • Store sensitive settings in environment variables and list them in .gitignore to avoid accidental commits of secrets.
  • Set git config --global core.editor "code --wait" (or your editor) to make commit messages and rebase flows smoother.

  • Don’t commit secrets (passwords, API keys, private keys); once pushed they are hard to fully remove from history.
  • Avoid using git add . blindly in large repos—you may stage build artifacts or temporary files; run git status first.
  • Changing history with git reset --hard or git rebase -i can discard commits permanently; back up branches before destructive operations.

Was this guide helpful?