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.
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:
- mkdir testing
Next, move into that working directory:
- 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 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.
You can initialize a Git repository in an existing directory by using the
git init command.
- git init
OutputInitialized 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.
- 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.
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:
- git commit -m "Initial Commit" -a
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:
- git commit -m "Initial Commit" file1 file2
In the next step, you’ll push this commit to a remote repository.
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:
- git remote add origin ssh://firstname.lastname@example.org/repository.git
- git remote -v
Outputorigin ssh://email@example.com/repository.git (fetch) origin ssh://firstname.lastname@example.org/repository.git (push)
The first command adds a remote, called “origin”, and sets the URL to ssh://email@example.com/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:
- git push origin main
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 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.
OutputCounting 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://firstname.lastname@example.org/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.
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.
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
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.