This series covers the installation and usage of git on an Ubuntu 14.04 server. After completing the series, the reader should feel comfortable installing and using git, as well as how to create two branches (master and develop) and how to merge code from the development stage to production.

Introduction to Git: Installation, Usage, and Branches

### Introduction

An indispensable tool in modern software development is some kind of version control system. Version control systems allow you to keep track of your software at the source level. You can track changes, revert to previous stages, and branch to create alternate versions of files and directories.

One of the most popular version control systems is `git`, a distributed version control system. Many projects maintain their files in a git repository, and sites like GitHub and Bitbucket have made sharing and contributing to code simple and valuable.

In this guide, we will demonstrate how to install git on an Ubuntu 14.04 VPS instance. We will cover how to install the software in two different ways, each of which have benefits.

This tutorial assumes you are signed in as a [non-root user](https://www.digitalocean.com/community/articles/initial-server-setup-with-ubuntu-14-04) which you can learn how to create here.

## How To Install Git with Apt

By far the easiest way of getting `git` installed and ready to use is by using Ubuntu's default repositories. This is the fastest method, but the version may be older than the newest version. If you need the latest release, consider following the steps to compile `git` from source.

You can use the `apt` package management tools to update your local package index. Afterwards, you can download and install the program:

```command
sudo apt-get update
sudo apt-get install git
```

This will download and install `git` to your system. You will still have to complete the configuration steps that we cover in the "setup" section, so feel free to skip to [that section](https://www.digitalocean.com/community/tutorials/how-to-install-git-on-ubuntu-14-04#how-to-set-up-git) now.

## How To Install Git from Source

A more flexible method of installing `git` is to compile the software from source. This takes longer and will not be maintained through your package manager, but it will allow you to download the latest release and will give you some control over the options you include if you wish to customize.

Before you begin, you need to install the software that `git` depends on. This is all available in the default repositories, so we can update our local package index and then install the packages:

```command
sudo apt-get update
sudo apt-get install build-essential libssl-dev libcurl4-gnutls-dev libexpat1-dev gettext unzip
```

After you have installed the necessary dependencies, you can go ahead and get the version of git you want by visiting the [git project's page on GitHub](https://github.com/git/git).

The version you see when you arrive at the project's page is the branch that is actively being committed to. If you want the latest stable release, you should go change the branch to the latest non-"rc" tag using this button along the left side of the project header:

![git change branch](https://assets.digitalocean.com/articles/git_install_1404/change_branch.png)

Next, on the right side of the page, right-click the "Download ZIP" button and select the option similar to "Copy Link Address":

![git download zip](https://assets.digitalocean.com/articles/git_install_1404/download_zip.png)

Back on your Ubuntu 14.04 server, you can type `wget` and follow it by pasting the address you copied. The URL that you copied may be different from mine:

```command
wget <^>https://github.com/git/git/archive/v1.9.2.zip<^> -O git.zip
```

Unzip the file that you downloaded and move into the resulting directory by typing:

```command
unzip git.zip
cd git-*
```

Now, you can make the package and install it by typing these two commands:

```command
make prefix=/usr/local all
sudo make prefix=/usr/local install
```

Now that you have `git` installed, if you want to upgrade to a later version, you can simply clone the repository and then build and install:

```command
git clone <^>https://github.com/git/git.git<^>
```

To find the URL to use for the clone operation, navigate to the branch or tag that you want on the [project's GitHub page](https://github.com/git/git) and then copy the clone URL on the right side:

![git clone URL](https://assets.digitalocean.com/articles/git_install_1404/clone_url.png)

This will create a new directory within your current directory where you can rebuild the package and reinstall the newer version, just like you did above. This will overwrite your older version with the new version:

```command
make prefix=/usr/local all
sudo make prefix=/usr/local install
```

## How To Set Up Git

Now that you have `git` installed, you need to do a few things so that the commit messages that will be generated for you will contain your correct information.

The easiest way of doing this is through the `git config` command. Specifically, we need to provide our name and email address because `git` embeds this information into each commit we do. We can go ahead and add this information by typing:

```command
git config --global user.name "<^>Your Name<^>"
git config --global user.email "<^>youremail@domain.com<^>"
```

We can see all of the configuration items that have been set by typing:

```command
git config --list
```
```
[label git configuration]
user.name=<^>Your Name<^>
user.email=<^>youremail@domain.com<^>
```

As you can see, this has a slightly different format. The information is stored in the configuration file, which you can optionally edit by hand with your text editor like this:

```command
nano ~/.gitconfig
```
```
[label ~/.gitconfig contents]
[user]
 name = <^>Your Name<^>
 email = <^>youremail@domain.com<^>
```

There are many other options that you can set, but these are the two essential ones needed. If you skip this step, you'll likely see warnings when you commit to `git` that are similar to this:

```
[label Output when git username and email not set]
[master 0d9d21d] initial project version
 Committer: root 
Your name and email address were configured automatically based
on your username and hostname. Please check that they are accurate.
You can suppress this message by setting them explicitly:

 git config --global user.name "Your Name"
 git config --global user.email you@example.com

After doing this, you may fix the identity used for this commit with:

 git commit --amend --reset-author
```

This makes more work for you because you will then have to revise the commits you have done with the corrected information.

## Conclusion

You should now have `git` installed and ready to use on your system. To learn more about how to use Git, check out these articles:

* [How To Use Git Effectively](https://www.digitalocean.com/community/articles/how-to-use-git-effectively)
* [How To Use Git Branches](https://www.digitalocean.com/community/articles/how-to-use-git-branches)

<div class="author">By Justin Ellingwood</div>

Git is a powerful distributed version control system that can be used to track software development projects and other information.  In this guide, we'll demonstrate a few different ways to install git on an Ubuntu 14.04 server and how to get started.

How To Install Git on Ubuntu 14.04

### Introduction
 
Version control systems like Git are essential to modern software development best practices. Versioning allows you to keep track of your software at the source level. You can track changes, revert to previous stages, and branch to create alternate versions of files and directories.

Many software projects’ files are maintained in Git repositories, and platforms like GitHub, GitLab, and Bitbucket help to facilitate software development project sharing and collaboration.

After installing Git, you’ll need to spend some time getting familiar with the core commands for maintaining a project repository. This tutorial will take you through the first steps of creating and pushing a Git repository on the command line.


## Prerequisites

- The version control tool [Git](https://git-scm.com/) available in your development environment. If you are working in Ubuntu, you can refer to [installing Git on Ubuntu 20.04](https://www.digitalocean.com/community/tutorials/how-to-install-git-on-ubuntu-20-04)


## Step 1 — Creating your workspace

If you are converting an existing project into a Git repository, you can proceed to step 2. Otherwise, you can begin by creating a new working directory:

 ```command
mkdir testing
```

Next, move into that working directory:

```command
cd testing
```

 
Once inside that directory, you will need to create a sample file to demonstrate Git’s functionality. You can create an empty file with the `touch` command:

```command
touch file
```

Once all your project files are in your workspace, you’ll need to start tracking your files with git. The next step explains that process. 


## Step 2 — Converting an existing project into a workspace environment

You can initialize a Git repository in an existing directory by using the `git init` command.

```command
git init
```

```
[secondary_label Output]
Initialized empty Git repository in /home/sammy/testing/.git/
```

Next, you’ll need to use the `git add` command in order to allow your existing files to be tracked by Git. For the most part, Git will never track new files automatically, so `git add` is a necessary step when adding new content to a repository that Git has not previously tracked.

```command
git add .
```

You now have an actively tracked Git repository. From now on, each of the steps in this tutorial will be consistent with a regular workflow for updating and committing to an existing Git repository.


## Step 3 — Creating a commit message

Each time you commit changes to a Git repository, you’ll need to provide a commit message. Commit messages summarize the changes that you've made. Commit messages can never be empty, but can be any length – some people prefer to use very long and descriptive commit messages, although some platforms like Github make it easier to read shorter commit messages.

If you are importing an existing project to Git for the first time, it’s typical to just use a message like “Initial Commit”. You can create a commit with the `git commit` command:

```command
git commit -m "Initial Commit" -a
```

```
[secondary_label Output]
[master (root-commit) 1b830f8] initial commit
 0 files changed
 create mode 100644 file
```

There are two important parameters of the above command. The first is -m, which signifies that your commit message (in this case "Initial Commit") is going to follow. Secondly, the -a signifies that your commit should include all added or modified files. Git does not treat this as the default behavior, but when working with Git in the future, you may default to including all updated files in your future commits most of the time.

In order to commit a single file or a few files, you could have used: 

```command
git commit -m "Initial Commit" file1 file2
```

In the next step, you’ll push this commit to a remote repository.


## Step 4 — Pushing changes to a remote server

Up until this point, you have worked exclusively in your own environment. You can, in fact, still benefit from using Git this way, by using advanced command line functionality in order to track and revert your own changes. However, in order to make use of its popular collaboration features on platforms like Github, you’ll need to push changes to a remote server.

The first step to being able to push code to a remote server is providing the URL where the repository lives and giving it a local name. To configure a remote repository and to see a list of all remotes (you can have more than one), use the `git remote` command:

```command
git remote add origin ssh://git@git.domain.tld/repository.git 
git remote -v
```

```
[secondary_label Output]
origin	ssh://git@git.domain.tld/repository.git (fetch)
origin	ssh://git@git.domain.tld/repository.git (push)
```

The first command adds a remote, called "origin", and sets the URL to ssh://git@git.domain.tld/repository.git.

You can name your remote whatever you'd like. `origin` is a common convention for where your authoritative, upstream copy of the code will live. The URL needs to point to an actual remote repository. For example, if you wanted to push code to GitHub, you would need to use the repository URL that they provide. 

Once you have a remote configured, you are able to push your code. You can push code to a remote server by typing the following:

```command
git push origin main
```

<$>[note]
**Note:** Prior to 2021, the first branch created in a Git repository was named `master` by default. There has since been a push to change the default branch name to `main` in order to use more neutral terminology. Although many Git hosting providers such as [Github](https://github.com/github/renaming) have made this change, your local copy of Git may still default to `master`. If you receive an error message about a nonexistent branch called `main`, try pushing `master` instead for now.
<$>

```
[secondary_label Output]
Counting objects: 4, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 266 bytes, done.
Total 3 (delta 1), reused 1 (delta 0)
To ssh://git@git.domain.tld/repository.git
 0e78fdf..e6a8ddc main -> main
```

In the future, when you have more commits to push, you can default to typing `git push`, which will inherit both the branch name and the remote name from your last push.


## Conclusion

In this tutorial, you created and pushed a starting Git repository. After committing and pushing your code to a repository such as GitHub, you can opt to spend more time collaborating in the web interface, but it will always be important to be able to work from a local machine on the command line. Maintaining or contributing to projects with multiple committers will involve more complex Git commands, but what you’ve covered in this tutorial is enough to work on personal projects.

Next, you may want to learn about [using Git branches](https://www.digitalocean.com/community/tutorials/how-to-use-git-branches), or how to [make a pull request on Github](https://www.digitalocean.com/community/tutorials/how-to-create-a-pull-request-on-github). You can also refer to the [Git reference guide](https://www.digitalocean.com/community/cheatsheets/how-to-use-git-a-reference-guide).

This tutorial contains a number of tips and strategies for using Git more effectively. It will cover how to create a workspace, how to convert an existing project into a workspace, best practices for writing commit messages, and how to push changes to a remote server.

How To Use Git Effectively

This article is the third installment in the "Using Git" series. 
It assumes that you have read both the 
<a href="https://www.digitalocean.com/community/articles/how-to-install-git-on-ubuntu-12-04">installation article</a> and the article on <a href="https://www.digitalocean.com/community/articles/how-to-use-git-effectively">how to use git effectively</a>. 

In the world of version control systems, GIT is arguably one of the best in terms of flexbility. It's very easy to learn the syntax and to figure out how git can best serve your workflow and your environment. 

This tutorial will teach you how to create two branches (master and develop) and how to merge code from the development stage to production.

A branch, at its core, is a unique series of code changes with a unique name. 
Each repository can have one or more branches.
 
By default, the first branch is called "master". 

<h2>Viewing branches</h2>
 
Prior to creating new branches, we want to see all the branches that exist. 
We can view all existing branches by typing the following:
 
<pre>git branch -a</pre>

Adding the "-a" to the end of our command tells GIT that we want to see all branches that exist, including ones that we do not have in our
local workspace. 

The output will look similiar to the following: 

<pre>
* master
 remotes/origin/master
</pre>

The asterisk next to "master" in the first line of the output indicates that we are currently on that branch. 
The second line simply indicates that on our remote, named origin, there is a single branch, also called master.

Now that we know how to view branches, it time create our first one.
 
<h2>Creating branches</h2>

As stated in the beginning of this article, we want to have a development and a production setup for our coding environment. 

We are going to treat the default "master" branch as our production and therefore need to create a single branch for development, or pre-production. 

To create a new branch, named develop, type the following: 

<pre>git checkout -b develop</pre>

Assuming we do not yet have a branch named "develop", the output would be as follows:

<pre>
Switched to a new branch 'develop'
</pre>

In the case of a branch by that name already existing, GIT would tell us so:

<pre>
fatal: A branch named 'develop' already exists.
</pre>

You can switch back and forth between your two branches, by using the git checkout command:

<pre>
git checkout master
</pre>

or
 
<pre>
git checkout develop
</pre>

Assuming the branch that you are trying to switch to exists, you'll see output similiar to the following:

<pre>
Switched to branch 'master'
</pre>

If you try to switch to a branch that doesn't exist, such as

<pre>
git checkout nosuchbranch
</pre>

Git will tell you:

<pre>
error: pathspec 'nosuchbranch' did not match any file(s) known to git.
</pre>

Now that we have multiple branches, we need to put them to good use. 
In our scenario, we are going to use our "develop" branch for testing out our changes and the master branch for releasing them to the public.

To illustrate this process, we need to switch back to our develop branch:

<pre>
git checkout develop
</pre>

<h2>Making changes to our develop branch</h2>

On this branch, we are going to create a new blank file, named "develop". 
Until we merge it to the master branch (in the following step), it will not exist there.

<pre>
touch develop 
</pre>

Just as in the previous tutorial, we need to tell git that we want to track this new file. 

We can add the "develop" file, by typing:

<pre>
git add develop 
</pre>

The above set of commands will create a blank file, named "develop", and add it to GIT. 

We also need to commit this file, which will attach this file to the branch we're currently on, which is "develop".

<pre>
git commit -m "develop file" develop 
</pre>

This file now exists on the develop branch; as we're about to find out, it doesn't exist on the master branch.

First, we are going to confirm that we are currently on the develop branch. We can do this by typing the following: 

<pre>
git branch 
</pre>

The output should appear similar to the following: 

<pre>
* develop
 master
</pre>

We learned earlier that the asterisk next to the branch name indicates that we are currently on that branch. 

Running the "ls" command will show us that the two files exist:

<pre>
ls
</pre>

The output will show us that both of our files, respectively named "file" and "develop", are found:

<pre>
develop file
</pre>

<h2>Merging code between branches</h2>

The interesting part comes after we switch back to our master branch, which we can do with the git checkout command:

<pre>
git checkout master
</pre>

To ensure that we are on the master branch, we can run type the following:

<pre>
git branch 
</pre>

The output will tell us which branch we are one, indicated by the asterisk.

<pre>
 develop 
* master
</pre>

Running "ls" again, it appears that our new file is missing. 

<pre>
file
</pre>

It's not missing - it's on our develop branch and we are on our master branch. 

In our scenario, this file represents any change to any file (or a whole new file) that has passed all testing on our development branch,and is ready to be in production. 
The process of moving code between branches (often from development to production) is known as merging. 

It is important to remember when merging, that we want to be on the branch that we want to merge to.
 
In this case, we want to merge from our develop branch, where the "develop" file exists, to our master branch. 

Keeping that in mind, considering that we are already on the master branch, all we have to do is run the merge command. 

One of the options that we can pass to the merge command, namely "--no-ff", means we want git to retain all of the commit messages prior to the merge. This will make tracking changes easier in the future. 

To merge the changes from the develop branch to the master branch, type the following:

<pre>
git merge develop --no-ff
</pre>

The output of the command will be similiar to the following: 

<pre>
Merge made by the 'recursive' strategy.
 0 files changed
 create mode 100644 develop
</pre>

Running the ls command again will confirm that our "develop" file is now on our master branch. 

<pre>
develop file
</pre>

The last thing we now need to do, to make this change on our remote server is to push our changes, which we can do with the help of the git push command. 

<pre>
git push
</pre>

You will see output similar to following, confirming that your the merge from your develop branch to the master branch on your remote server:

<pre>
Counting objects: 4, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 332 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
To ssh://git@git.domain.tld/repository
 9af2dcb..53649cf master -> master
</pre>

<h2>Conclusion</h2>

By following the above tutorial, you should have a working dual-branch workflow setup and hopefully a working understanding about how
branching works in GIT. Let us know what you think in the comments!

<div class="author">By Jason Kurtz</div>

A branch, at its core, is a unique series of code changes with a unique name. Each repository can have one or more branches. This tutorial will teach you how to create two branches (master and develop) and how to merge code from the development stage to production.

How To Use Git Branches

Senior DevOps Technical Writer

Sign up for Infrastructure as a Newsletter.

Working on improving health and education, reducing inequality, and spurring economic growth? DigitalOcean would like to help.

Working on improving health and education, reducing inequality, and spurring economic growth? We'd like to help.

Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.

You get paid; we donate to tech nonprofits.

DigitalOcean makes it simple to launch in the cloud and scale up as you grow – whether you’re running one virtual machine or ten thousand.