Getting Started with Git

Traducciones al Español
Estamos traduciendo nuestros guías y tutoriales al Español. Es posible que usted esté viendo una traducción generada automáticamente. Estamos trabajando con traductores profesionales para verificar las traducciones de nuestro sitio web. Este proyecto es un trabajo en curso.
Create a Linode account to try this guide with a $ credit.
This credit will be applied to any valid services used during your first  days.

What is Git?

Git is a distributed version control system. Git was designed and developed by Linus Torvalds for Linux kernel development. Git provides support for non-linear, distributed development, allowing multiple contributors to work on a project simultaneously. Git is the most popular distributed version control and source code management system. This guide will walk you through the basics of getting started with Git, from installing the software to using basic commands on both local and remote repositories (repo).

If you are new to version control systems (VCS), see our guide SVN vs Git: Which Version Control System Should You Use? to learn more about each VCS.

Configure Git

After you install Git, configure it for first time use using git config, a built-in tool that obtains and sets configuration variables. These configuration variables are located in three different places on a GNU/Linux system:

  • /etc/gitconfig - stores the configuration information for all system users and their respective repositories.
  • ~/.gitconfig - stores user-specific configuration files on the system.
  • .git/config - this is the configuration file of your current working repository.

For a Windows system, the .gitconfig file is located in the $HOME directory of the user’s profile. The full path is C:\Document and Settings\$USER or C:\Users\$USER

After installing Git make sure your username and email address are set correctly. To verify, use the command:

git config --list

If your name and email are not listed in the output, use the following commands to set them manually, replacing examplename and

git config --global examplename
git config --global

Set your default text editor, replacing editor-name with your desired editor:

git config --global core.editor editor-name

The output of git config --list should show echo the information you inputted:

$ git config --list

Use Git with a Local Repository

A repository, or repo, is a collection of files and folders and the history of their changes. Changes are tracked through commits, which are like snapshots of a file at various points in the file’s history. These commits are not automatic, you need to manually stage a commit after each of series of file changes. Commits allow you to refer or revert back to a place in the file’s timeline if there are bugs or errors in your code.

If you have an new or existing project and you want to start using Git to keep track of its changes, run git init from the existing project’s directory:

git init

git init creates a new .git subdirectory in the current directory. This is where Git stores your configurations. The git add command tells Git to add a file to the repository and track that file’s changes:

git add filename

After you have added the file, stage a commit and leave a commit message. Commit messages serve as a reminder of the changes that were made to a file:

git commit -m "Initialized a Git repository for this project. Tracking changes to a file."
It’s good practice to provide clear and descriptive commit messages for every commit you stage, as this helps collaborators to understand what a commit encompasses.

There may be files or folders in your project directory that you do not wish to include in your Git repository. You can include these files in a .gitignore file, and Git will ignore them. A sample .gitignore file might look like the following:

File: .gitignore

To learn how to undo Git commit, see our guide How to Undo a Git Commit: A Step-by-Step Guide.

Basic Git Commands

This table lists basic commands, a description, and an example of the command in use:

git addAdd a file to a repository.git add filename
git rmRemove a file from a repository.git rm filename
git mvMove or rename a tracked file, directory, or symlink.git mv file_from file_to
git branchList all the local and remote branches.git branch branchname
git commitCommit all staged objects. Optionally, you can append a message with the -m flag.git commit -m "updates"
git pullDownload all changes from the remote repo and merge them in a specified repo file.git pull repo refspec
git pushPublish the changes to the remote repo.git push repo


Branches are used for editing files without disturbing the working portions of a project. The main branch is normally named master and is usually reserved for clean, working code. When making changes to your code, it’s customary to create a new branch and name it after the issue being fixed or the feature being implemented. Because Git keep tracks of file changes, you can jump from branch to branch without overwriting or interfering with other branches in the repo.

The basic options used with the git branch command are:

-rList the remote branches
-aShow both local and remote branches
-mRename an old branch
-dDelete a branch
-r -dDelete a remote branch

Example Usage

Consider an application with a single master branch. The author of the application wants to develop a new search feature. They would add a new feature branch:

git branch new-search-feature

Then, they would switch to that branch using the checkout command:

git checkout new-search-feature

Now they can safely develop and commit their changes to this feature branch without altering the working code of the master branch. At any time they could switch back to the master branch:

git checkout master

A shortcut for creating a branch and switching to that branch is to use the -b flag with the checkout command:

git checkout -b new-search-feature

Once the new search feature is finalized, the author of the application can merge the new-search-feature branch into the master branch:

git checkout master
git merge new-search-feature

Now the master branch has the new search feature.

Use Git with a Remote Repository

GitHub, GitLab, and Bitbucket all provide ways to store Git repositories remotely and facilitate collaboration. Many of these services also include a number of other features that are vital to content development, including pull requests, continuous integration / continuous delivery pipelines (CI/CD), wikis, and webhooks. If you’d rather use a self-hosted solution, GitLab and Gogs offer free locally hosted versions of their software that can easily be managed on a Linode. Check out our guides on installing GitLab and installing Gogs for more information on hosting your own remote repository software. GitHub and Bitbucket also offer paid enterprise versions of their software for local hosting. When discussing remote repositories, usually one of the aforementioned services is being referenced.

This section provides some basic information on navigating remote Git repositories.

To copy every file from a remote repository to your local system, use git clone followed by the remote repository’s URL:

git clone

You can typically find a remote repository’s URL by clicking on the Clone or Download buttons of a remote repository’s user interface.

To check the status of the files within the current branch of your repository, use status:

git status

The output of the status command will tell you if any tracked files have been modified.

Use remote to view which remote servers are configured:

git remote

The remote command will display the short names of your remote repositories. If your repository was cloned, you will see a repository called origin. The default name origin comes from the cloned repository. To view more information about the remote repositories, use the command:

git remote -v

Git Remote Repository Commands

Below are some basic commands for working with remote repositories:

git remote add [remote-name] [url]Add a new remote repository.
git fetch [repository [refspec]]Gather all the data from a remote project that you do not have yet.
git pullObtain and merge a remote branch into your current branch.
git push [remote-name] [branch-name]Move your data from your branch to your server.
git remote show [remote-name]Display information about the remote you specified.
git remote rename [old-name] [new-name]Rename a remote.
git remote rm [name]Remove the remote you specified.

Example Usage

Continuing the example posed in the previous section, let’s say that someone wants to add a functionality to an application in a remote repository. The first step would be to fork that repository. This feature, like cloning, is usually available in the user interface of the remote repository software. Forking creates a remote repository, which is a copy of the forked repository, on the user’s own account. From their the user would clone the fork locally use the clone command discussed above.

git clone

Once the repository is cloned, the user would create a branch for the new feature using either the branch or checkout -b command.

git checkout -b new-special-feature

After the branch is made, the user would make the necessary updates or changes to the codebase, and commit them.

git commit -m "A new special feature"

With the commit staged, the user would then push their changes to their fork of the remote repository:

git push origin new-special-feature

The result of the push command is that now the new feature branch exists on the user’s fork. To contribute those changes to the initial repository, known as the upstream repository, the user must now submit a pull request (PR). A PR is a feature that most remote repository software has that allows the user to safely contribute a commit, or series of commits, to an upstream repository. This is accomplished by navigating through the user interface to the pull requests page, selecting the master branch of the upstream repository as the target, and selecting the origin repository’s feature branch as the source. A pull request will be created and the code will be up for review before being merged into the master branch of the upstream repository.

While creating PRs is a healthy standard within the development community, it is not the only way to contribute to a remote repository. You could simply push your commits directly to the upstream repository:

git push my-repo new-special-feature

The downside of this approach is that there is no option to hold the pushed commits for review. However, if you are the only contributor to a project then obviously there will be no one to review your changes, so creating a fork and contributing PRs is not necessary.

If you are collaborating with another developer, it is necessary to be able to retrieve their work. To do so, issue the pull command:

git checkout new-special-feature
git pull

Git will grab the new code from the chosen remote repository branch and merge it into your local branch.

Sometimes two developers will edit the same section of a file at the same time and attempt to merge their changes into the codebase. When this happens, Git will throw an error called a merge conflict. Because Git will be unable to determine which set of changes is the correct set of changes, it will prompt you to fix the merge conflict before it moves forward with the merge.

More Information

You may wish to consult the following resources for additional information on this topic. While these are provided in the hope that they will be useful, please note that we cannot vouch for the accuracy or timeliness of externally hosted materials.

This page was originally published on

Your Feedback Is Important

Let us know if this guide was helpful to you.

Join the conversation.
Read other comments or post your own below. Comments must be respectful, constructive, and relevant to the topic of the guide. Do not post external links or advertisements. Before posting, consider if your comment would be better addressed by contacting our Support team or asking on our Community Site.
The Disqus commenting system for Linode Docs requires the acceptance of Functional Cookies, which allow us to analyze site usage so we can measure and improve performance. To view and create comments for this article, please update your Cookie Preferences on this website and refresh this web page. Please note: You must have JavaScript enabled in your browser.