By Jason Kurtz and Alex Garnett
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://email@example.com/repository.git
- git remote -v
Outputorigin ssh://firstname.lastname@example.org/repository.git (fetch) origin ssh://email@example.com/repository.git (push)
The first command adds a remote, called “origin”, and sets the URL to ssh://firstname.lastname@example.org/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://email@example.com/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.
Next, you may want to learn about using Git branches, or how to make a pull request on Github. You can also refer to the Git reference guide.
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.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
Click below to sign up and get $200 of credit to try our products over 60 days!
this helped http://git-scm.com/book/en/Git-on-the-Server-Setting-Up-the-Server
Here are the steps you need for pushing local machine code changes to your VPS:
Follow the steps mentioned in the article above before the “Pushing changes to a remote server” section.
On your local machine command line:
If you want to check which Git remotes you have on your local machine:
If you want to remove existing Git remotes on your local machine:
@tommillard81: Your droplet is running out of memory. Try adding swap: <a href=“https://www.digitalocean.com/community/articles/how-to-add-swap-on-ubuntu-12-04”>https://www.digitalocean.com/community/articles/how-to-add-swap-on-ubuntu-12-04</a>.
Nice article, but the whole thing was pasted in twice, near this text. It would be nice to get that fixed.
>This article assumes that you have git installed and that your global configuration settings By Jason Kurtz > (namely username and email) are properly set. If this is not the case, please refer to the git introduction tutorial.<^>
I am working on a project which I committed and supposedly pushed onto the server using Bitbucket. I committed and pushed it via Pycharm, and was able to see it also on Bitbucket website under “Recent Activities” that it was committed and pushed to the server. However, the changes did not reflect on my website - Do I need to setup or tweak anything on DigitalOcean Droplets for the changes to take effect?
I get Internal Server Error after finish the git clone, all files are there on /var/www/html/
how do i fix?
This comment has been deleted
I’m trying to push from my local machine to my droplet. I can access the droplet using Putty and my SSH private key.
How does git know what my private key is?
Example: from my local machine I type
git remote add live ssh://root@wp-test/var/repo/site.gitthen I add and commit the files on my local machine but when I try
git push live masterit gives me an error “please make sure you have the correct access rights and the repo exists”. I’m pretty sure I setup the repo on the remote server correctly from this explanation. I suspect this is happening because it doesn’t know where to find my private key.
In Putty I added a path to the private key so it logs me in automatically. How does it know where this private key is when I use git from my local machine(I’m trying to push from my local machine using windows cmd to the remote server)? I’m confused, clearly.
In the server setup tutorials it’s advised not to use the root user on the server. So we use sudo for all commands. But there’s a problem when working with Git.
This won’t work:
It gives back a ‘command not found’. Without the sudo it will work fine. But then we you do command like “sudo git clone…” or any other git commands, it will not use the same keys: You should not be using the sudo command with Git. If you have a very good reason you must use sudo, then ensure you are using it with every command (it’s probably just better to use su to get a shell as root at that point). If you generate SSH keys without sudo and then try to use a command like sudo git push, you won’t be using the same keys that you generated. - Github (https://help.github.com/articles/error-permission-denied-publickey/)
Cloning without sudo won’t work as well, as the server doesn’t allow that.
So now i’m not sure what to do. Is there some way to still use Git without the root user? Or should I just use the root user on my server?
Hey, thanks a ton for the well written tutorial. However, I think think there’s a lot to learn before the term “effectively” can be used.