Git is widely adopted by the development community. However, some developer’s haven’t gotten to cut their teeth with it for various reasons. This article is designed to help people get started using Git for the first time.
This article uses the command line to work with Git. Although GUIs exist, I found it helpful to learn the concepts through the command line. If you aren’t comfortable with the command line djangogirls.com can help you get started.
Let’s get started. There are a couple of different ways to install Git depending on your operating system.
I prefer to install the Github Desktop application. This install adds GUI and command line support as well as some authentication features that make some things easier. If you’d rather have the official tools you can get them from the Git website.
Mac has a Github Desktop application as well. Just make sure you include the command line tools when you install it. Git also comes with XCode, or you can use Homebrew to install it.
Generally, you’ll use the package management system for your operating system. In Debian based systems you would use:
sudo apt install git-all
Note: You can also compile the source if you would like. Click here for more info.
In a lot of instances you’ll be using a remote Git service. There are a lot of different ones out there, but GitHub is the most popular. We can quickly create a remote repository to use for free. This is an optional step to demonstrate dealing with distributed code when you’re on a team.
The first step is to go to GitHub and create an account if you don’t already have one:
Now that you’re logged in you can create a new repository:
The “Repository name” field determines the URL of the repository so make it something simple. Keeping it public is fine, but make sure you check the “Initialize this repository with a README” checkbox. When you click “Create Repository” you should land on a page with a shiny new repository!
It’s finally time to do some things with Git. Open up a command line and make sure you have git installed with the
git --version command. It should return something like this:
Now you can configure your information with the
git config command.
git config --global user.name "Name" git config --global user.email "[email protected]"
At this point, we’re ready to download the repository we created. First, you’ll want to copy the URL of the repository you created. On the right of the screen, there’s a “Clone or download” button that will give you the URL to the repository.
Switch back to the command line and change directories to the one where you want to download source. Run the
git clone command with the repository URL.
git clone https://github.com/youruser/your-repository.git
Again, it should return something like this:
Now if you navigate into the directory you should see the shiny new README.md file.
git status command lets you see what’s changed in the repository.
I’ll explain more of that later. Just notice how it says nothing to commit. Let’s add a file to the directory. After you add the file and execute
git status again you’ll see that the changes show up.
Git’s saying there is an untracked file that was added. You can use
git add command to start tracking the file.
git add .
Then you can see the status again with the
git status command.
Now Git is letting you know that there is a new file that is being tracked, but we need to commit the changes with the
git commit command.
git commit -am "Added a bacon.txt file that we're going to work on."
-am to git commit saying commit all files and add a message. Always make sure you add a good message to explain what you’ve done.
Awesome. Let’s make another change to get used to the workflow. Open the README.md and add some text. Save the file and run
git status again to see that git picked up the change.
Since the file is already being tracked we can just commit the changes.
git commit -am "Added an awesome sentence to the README file."
git status and we can see that we’ve committed everything.
Great! Now let’s push those changes to the server.
You may have noticed that Git said Your branch is ahead of ‘origin/master’ by 2 commits. Git knows that this repository is connected remotely to GitHub. The remote for GitHub is called origin, and Git is saying you have two more commits than what the server has. Luckily, the
git push command can send your commits to GitHub.
git push origin master
This command says push commits to the remote server (origin) to the specific branch (master). A quick
git status and you can see the server is now up to date.
We can verify that the changes went to the remote server by going to our GitHub account and clicking on the repository that we created. Since we changed the README.md file we can see the update right on the homepage.
So we’ve made changes and pushed them to GitHub. Let’s play with some more advanced features.
The ability to diverge from the main source and make changes is very important. Git branches are extremely lightweight so it’s easy to make changes without worrying about hurting your primary source. So let’s create a branch with the
git checkout command.
git checkout -b newtextchange
git checkout command switches to the newtextchange branch and
-b signals to create a new one. Git says the branch was created, but you can run
git status to see which branch you’re currently in. Make another change to the README.md file. Go ahead and commit those changes to the branch.
git commit -am "Updated the new feature"
Now the changes are committed. Switch back to the master branch.
git checkout master
Notice that your changes disappeared. That’s because they are on the newtextchange branch. You can jump from branch to branch at any point with the
git checkout command. Let’s switch back to the newtextchange branch.
git checkout newtextchange
You should now have all your changes back.
You can push branches to the remote server in order to work on branches with other people or have them for continuity. Let’s push the branch to GitHub.
git push -u origin newtextchange
git push command pushes branch commits to the remote server. The
-u argument specifies that we’re creating a new upstream connection, and
origin newtextchange says we are pushing the branch to the origin remote and the newtextchange branch. If you go to GitHub you can see the branch.
When it is time to merge the newtextchange commits into the primary master branch we use the
git merge command. Switch branches to our master branch.
git checkout master
Then we can merge the newtextchange commits to master.
git merge newtextchange
This creates a commit of the merge. We can now push master to GitHub.
git push origin master
And there you have it.
I highly encourage reading the documentation on Git. We’ve only touched the surface, and if it’s a part of your daily workflow you’ll need to know some of the nuances. It’s a fantastic product with tons of features.