DEV Community

Cover image for Basics of Git: Adding and Committing
Mustafa Hashmani
Mustafa Hashmani

Posted on • Originally published at mustafahashmani.hashnode.dev

Basics of Git: Adding and Committing

Repository

  • A Git "Repo" is a workspace which tracks and manages files within a folder.
  • Anytime we want to use Git with a project, app, etc we need to create a new git repository.
  • We can have as many repos on our machine as needed, all with separate histories and contents
  • git status gives information on the current status of a git repository and its contents
  • Use git init to create a new git repository. Before we can do anything git-related, we must initialize a repo first!
  • Before running git init, use git status to verify that you are not currently inside of a repo.
  • This is something you do once per project. Initialize the repo in the top level folder containing your project

🚨 Do not INIT a repo inside of a repo

The Basic Git Workflow

  1. Make new files, edit files, delete files, etc
    1. Then run git status which will tell you the untracked and modified files
  2. Group specific changes together, in preparation of committing(git add)
  3. Commit everything that was previously added(git commit)

Image description

Adding

  • We use the git add command to stage changes to be committed.
  • It's a way of telling Git, "please include this change in our next commit"
  • Use git add to add specific files to the staging area. Separate files with spaces to add multiple at once.
  • Use git add . to stage all changes at once rather than typing the filenames
  • After adding git status , will show that the changes in the file are ready to be committed

    git add file1 file2
    git add .
    

Committing

  • Making a commit is similar to making a save in a video game. We're taking a snapshot of a git repository in time and marking a checkpoint.
  • When saving a file, we are saving the state of a single file. With Git, we can save the state of multiple files and folders together.
  • We have to make changes first and then save them to our files before we can commit. Once we have made changes and added them, we can group them together into a commit.
  • We use the git commit command to actually commit changes from the staging area.
  • When making a commit, we need to provide a commit message that summarizes the changes and work snapshotted in the commit
  • Running git commit will commit all staged changes. It also opens up a text editor and prompts you for a commit message. You can also use the -m flag which allows us to pass in an inline commit message, rather than launching a text editor.
  • git log --oneline gives a summary for the log of the commits for a given repository
  • You can also pass -a option to git commit which will add and commit altogether.
  • Use git config --global core.editor "code --wait” to configure VSCode to pass the commit messages when you are not using -m to pass longer messages

    git commit -m "my message"
    git commit -a -m "my message"
    

    Atomic Commits

    • When possible, a commit should encompass a single feature, change, or fix. In other words, try to keep each commit focused on a single thing.
    • This makes it much easier to undo or rollback changes later on. It also makes your code or project easier to review.

    Writing Commit Messages

    • Describe your changes in imperative mood, e.g. "make xyzzy do frotz" instead of "[This patch] makes xyzzy do frotz" or "I changed xyzzy to do frotz", as if you are giving orders to the codebase to change its behavior.
    • Many developers prefer the past tense “added head”

    Amending Commits

    • Suppose you just made a commit and then realized you forgot to include a file! Or, maybe you made a typo in the commit message that you want to correct.
    • Rather than making a brand new separate commit, you can "redo" the previous commit using the --amend option

      git commit -m 'some commit'
      git add forgotten_file
      git commit --amend
      

Ignoring Files

  • We can tell Git which files and directories to ignore in a given repository, using a .gitignore file. This is useful for files you know you NEVER want to commit, including:
    • Secrets, API keys, credentials, etc.
    • Operating System files (.DS_Store on Mac)
    • Log files
    • Dependencies & packages
  • You will have the file locally but you don’t want git to track it
  • Create a file called .gitignore in the root of a repository using touch .gitignore. Inside the file, we can write patterns to tell Git which files & folders to ignore:
    • .DS_Store will ignore files named .DS_Store
    • folderName/ will ignore an entire directory
    • *.log will ignore any files with the .log extension

Top comments (0)