keepcalculator

06 Numbers and Powers

Learn Git: A Beginner’s Step-by-Step Guide

Card No. 06·61184 · Updated · Standard formula, shown below

Git helps you track changes to files, revisit earlier versions, and work on projects without losing useful work. This beginner’s guide shows you how to install Git, save changes in a repository, and use branches and remotes. You’ll need a computer, a terminal or command prompt, and a project folder; an online hosting account is optional.

What You’ll Need

  • A computer running Windows, macOS, or Linux.
  • Git installed. Download it from the official Git website or use your operating system’s package manager. On macOS, Git may be available through Command Line Tools.
  • A terminal app: Terminal on macOS or Linux, or Git Bash, PowerShell, or Command Prompt on Windows.
  • A text editor and a folder containing files you can safely change.
  • Optional: an account on a Git hosting service if you want to back up or share a repository online.

Step-by-Step

  1. Check that Git is installed. Open your terminal and run git --version. If it prints a version, Git is available. If the command is not recognized, install Git and reopen the terminal. Follow the installer’s standard options unless you have a specific setup requirement.
  2. Set your commit name and email. Git records this information with each commit. Enter a name and email you are comfortable associating with your work:
    git config --global user.name "Your Name"
    git config --global user.email "you@example.com"

    The --global setting applies to your user account. You can check the values with git config --global --list. If you later need a different identity for one project, run the same commands inside that repository without --global.

  3. Create a practice project and initialize Git. Make a new folder, move into it in the terminal, and initialize a repository:
    mkdir git-practice
    cd git-practice
    git init

    A repository is a project directory whose changes Git tracks. Git creates internal repository data in a hidden .git folder. Do not delete that folder unless you intend to remove the repository’s history.

  4. Create a file and inspect the status. Add a file such as README.md using your editor, write a short description, and save it. Then run:
    git status

    Git should report that the new file is untracked. Status is one of the most useful commands: run it whenever you are unsure what Git sees or what your next action will affect.

  5. Stage the change. Staging selects the changes to include in your next commit. Add the file with:
    git add README.md

    Check git status again. The file should appear under changes ready to be committed. To stage all changes in the current directory, use git add ., but inspect the status first so you do not include unwanted files.

  6. Make your first commit. A commit is a saved snapshot of staged changes. Create one with a concise description:
    git commit -m "Add project readme"

    Use a message that explains the change, not just “update.” Run git status afterward; if everything is committed, Git reports a clean working tree.

  7. Practice the edit-stage-commit cycle. Change the README, save it, and run git diff to review unstaged edits. Then run git add README.md and git diff --staged to review what will enter the commit. Commit the change. The usual cycle is edit, inspect, stage, inspect again, and commit.
  8. Review your history and compare versions. Run git log --oneline to see recent commits. To inspect a particular commit, use git show followed by its identifier from the log. Git stores committed snapshots, so you can compare how files changed rather than relying on filenames such as “final-version-2.”
  9. Use a branch for separate work. A branch is a movable line of development. Create and switch to one with git switch -c add-notes. Edit a file, stage it, and commit the change there. To return to the main line, run git switch main; if your default branch has another name, use that name instead. Avoid switching branches with uncommitted changes unless you understand how Git will carry them over.
  10. Merge the branch when its work is ready. First switch to the branch that should receive the changes, commonly main, then run git merge add-notes. If Git can combine the changes, it completes the merge. You can remove the finished local branch with git branch -d add-notes after confirming its work is merged.
  11. Optionally connect to an online remote. Create an empty repository on a hosting service, then use the remote address it provides. In your local project, run git remote add origin ADDRESS, replacing ADDRESS with that address. Confirm it with git remote -v. The first time you publish a branch, use git push -u origin main, adjusting the branch name if needed. Later, git push sends your commits; git pull fetches and integrates changes from the remote. Read any hosting-service authentication prompts carefully.

Common Mistakes

  • Confusing Git with a hosting service: Git tracks versions on your computer. A remote service is optional and provides online storage and collaboration features.
  • Forgetting to stage: A commit includes staged changes, not every edit in your folder. Check git status before committing.
  • Staging everything without checking: git add . can include generated files, downloads, or secrets. Review the list first and use a .gitignore file to exclude files that should not be tracked.
  • Expecting a commit to upload work: Commits are local until you push them to a remote.
  • Using vague commit messages: A message such as “stuff” makes history harder to understand. Describe the purpose of the change.

Tips

  • Make small commits that each represent one understandable change.
  • Use git status often and review both git diff and git diff --staged.
  • Learn commands in a disposable practice folder before using unfamiliar commands on important work.
  • Create a .gitignore file for files that can be regenerated or should stay local. Never commit passwords, private keys, or other secrets; removing them in a later commit does not erase them from earlier history.
  • Remember the basic roles: add stages, commit saves locally, push uploads, and pull brings remote work into your local branch.

Troubleshooting

“Not a git repository”: You may be outside the project folder. Use cd to move into the repository and check your location. If it is a new project, run git init there.

Your edit is missing from the commit: Run git status. If the file is unstaged, add it and make another commit. If you committed on another branch, check git log --oneline --all and switch to the correct branch.

Git says there is nothing to commit: The file may not have changed, may be ignored, or may already be committed. Check git status and inspect the relevant .gitignore rules.

A merge conflict appears: Git could not automatically combine edits to the same area. Open each conflicted file, find the conflict markers, choose or combine the intended content, and remove the markers. Then stage the resolved files and finish the merge with a commit if Git requests one. Do not accept a resolution you have not reviewed.

Push or pull fails: Check the remote with git remote -v, confirm the branch name, and follow the hosting service’s authentication steps. If a push is rejected because the remote has newer work, fetch or pull and resolve any conflicts before pushing again. Avoid force-pushing while learning; it can overwrite shared history.

Frequently Asked Questions

Is Git the same as GitHub or another hosting service?
No. Git is version-control software; hosting services store Git repositories online and add collaboration tools.

Do I need internet access to use Git?
No. You can initialize repositories, commit changes, make branches, and review history offline. Internet access is needed to exchange work with an online remote.

What is the difference between a branch and a commit?
A commit records a snapshot of staged changes. A branch is a named pointer that moves as you add commits on that line of work.

Can I undo a commit?
Often, yes, but the safest method depends on whether it has been shared. For a beginner, avoid rewriting shared history; ask a collaborator before changing commits that others may already have downloaded.

What should I learn after the basics?
Practise resolving merge conflicts, using .gitignore, reading logs, and collaborating through branches and pull requests on your chosen hosting service.

Related

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.

More cards in this drawer

The whole Numbers and Powers drawer →