Set Up Git | PageDeploy

Configure Git

Before creating your first Git repository, configure the name and email address that Git will associate with your commits.

First, check whether Git already has your identity configured:

git config --global user.name
git config --global user.email

If both commands display the expected values, Git is already configured and you can continue to initialize the repository.

If either value is missing, configure them with:

git config --global user.name "Your Name"
git config --global user.email "[email protected]"

Replace the example values with the name and email address you want Git to associate with your commits.

These settings identify the author of your commits. They are not your GitHub password or authentication credentials.

Initialize the Repository

Once Git is configured, initialize a Git repository inside the root directory of your project.

Open your terminal, navigate to the project folder, and run:

git init

Git creates a hidden .git directory containing the information required to track the repository and its history.

The .git directory is managed by Git. You normally do not need to open or modify its contents manually.

Important

Run git init from the root of the project you want Git to manage. Initializing Git in the wrong directory can cause Git to track files you did not intend to include.

.gitignore

A .gitignore file tells Git which files and directories should not be included in version control.

This is particularly useful for files that are generated automatically, contain local machine information, or contain secrets that should never be committed.

A typical project might contain entries such as:

node_modules/
.env
.env.local
.DS_Store

Build output such as dist/ is also commonly ignored when it is generated by the project’s build process:

dist/

Do not blindly copy every possible .gitignore entry into every project. The entries should match the tools and files used by your particular project.

Warning

Never commit passwords, API keys, private credentials, or other secrets to a Git repository.

A .gitignore rule helps prevent a file from being tracked, but it is not a security system. Always check what you are staging before committing.

git status

Use git status to see the current state of your Git repository.

git status

Git can report files that are untracked, modified, or staged for the next commit.

At this point, many of your project files will normally appear as untracked because Git has just been initialized and no commit has been created yet.

git status is one of the most useful commands in Git. You will use it repeatedly before and after making changes, staging files, committing, and switching branches.

git add

Git does not automatically include every changed file in your next commit. You first select the changes that should become part of that commit by staging them.

To stage the changes in the current project, run:

git add .

The period means the current directory. When you run this command from the project root, it stages the changes under that project directory that are not excluded by .gitignore.

After staging, run git status again to see which files are ready to be committed.

git status

The staging area gives you an opportunity to review what will be included before creating the commit.

git commit

A commit records the changes currently in the staging area as a new point in the repository’s history.

git commit -m “Initial commit”

The -m option lets you provide a message describing the commit.

A good commit message briefly describes what the commit contains. Later in the guide, you will use more focused commit messages as you work on individual features.

First Commit

The first commit establishes the initial version of your project in Git. Later commits will record subsequent changes.

Understanding Commits

One of the most important concepts in Git is understanding the relationship between your working files, the staging area, and commits.

Working Directory
     ↓
  git add
     ↓
Staging Area
     ↓
 git commit
     ↓
Repository History

The working directory contains the files you are currently editing.

The staging area contains the changes you have selected for the next commit.

A commit records the staged changes as a new point in the repository history.

git status

Inspect the current state of the working directory and staging area.

git add .

Stage changes for the next commit.

git commit -m “message”

Record the staged changes as a new commit in the repository history.

Your First Git Workflow

The basic sequence you will use repeatedly throughout this guide is:

git status
git add .
git status
git commit -m "Initial commit"
git status

Running git status before and after the other commands helps you see what Git is doing at each stage.

Once the first commit exists, the project has a local version history. The next step is to connect that local repository to a remote repository on GitHub.