HOLIDAY SALE! Save 50% on Membership with code HOLIDAY50. Save 15% on Mentorship with code HOLIDAY15.

2) Tools of the Developer Trade Lesson

How to use Git

14 min to complete · By Ryan Desmond

Knowing how to use Git is essential for every programming job. This lesson will provide you the basics for getting started.

How to Check Git Installation?

First, you'll want to make sure that you have Git installed. Check your installation by running the following command:

$ git --version

After hitting enter, you should see something along the lines of git version 2.39.3 (Apple Git-146) (your version number/details will vary) printed out to the console. If you see command not found, that means that Git is not yet correctly installed on your system.

How to Install Git?

If you do not already have Git installed on your machine, please follow the directions here to install it.

What are the Basic Git Commands?

With a few basic commands, you can accomplish the majority of functionality you require to get started with Git. You'll first want to cd into the directory containing the project you just cloned in the previous section.

cd ~/Documents/CodingNomads/labs/online-java-fundamentals/

This directory you previously cloned from CodingNomads GitHub contains the labs and examples you'll use in this course.

So, look around using the ls -al command you learned in the CLI lesson. Once you've confirmed that you're in the right spot and everything looks good, it's time for you to git started ;).

Colorful illustration of a light bulb

Note on Git repositories

All files and folders within a Git repository will be tracked. It's important that you only set up Git repositories in directories that you want to track. It's a common mistake when people are first getting started to accidentally turn their entire computer (or large sections) into Git repositories. This is a mistake. You only want to track the directories that contain your coding projects.

1. Check the Status of Your Git Repository

Whenever you're in doubt, this command allows you to confirm the status of the files:

  • Changes to be committed (staging area)
  • Changes not staged for commit
  • Untracked files
$ git status

Now you'll see the following output:

On branch main

Your branch is up-to-date with 'origin/main'.

nothing to commit, working tree clean

That's because you're just getting started.

Modify a file to update Git

Modify a file to run through the process of adding and committing files to Git. You can do this quickly using the new text editor you learned in the previous lesson What is Vim?.

$ vim README.md

As a reminder, once inside the file with Vim, hit the i key to enter "insert mode". Make a minor edit to the file after the "#" symbol on the first line. After making your edit, hit the [esc] key and type :wq, then hit "enter" to save the file and exit.

Now run git status, and you can see that you have one modified file. The output will appear as follows:

Git status output of unstaged README file

It also tells that you can use git add to update what will be committed or git checkout -- <file> to discard changes in the working directory.

2. Add Files to Git

Go ahead and add the modified file to the staging area.

$ git add README.md

Now run git status to see the status of the git repo.

$ git status

Output:

Git status output of ready to be committed README file

Here, the output tells you that you have "changes to be committed", and you can use git reset HEAD to unstage the file from the staging area. This is helpful in cases where you need to make a few more changes to the file before actually committing.

3. Commit Changes to Git

Make your first commit and add the required commit message to the command by specifying the -m flag in the command. Your commit message can be "updating README".

$ git commit -m "updating README"

Output:

Git commit output with message: updating README

4. View Git History

Having completed your second commit, go ahead and check out the history of this Git repository by running git log.

$ git log

The output will show you the following:

  • the commit hash (which is the unique identifier of the commit)
  • the author of the commit
  • the date of the commit
  • the commit message.

Congratulations, you've just completed what you'll be doing most of the time you're using Git! Soon, you'll push your local Git repository to GitHub so you can share your code and collaborate with others.

How is Git Organized?

While it's fantastic to use Git to collaborate and track your files, it is crucial to understand how it works from a big-picture perspective in the real world.

Imagine you're a company with an application in the app store, and you're updating and improving your application. The image below is a visual representation of a potential Git flow.

Git flow diagram with main, develop, feature, quick fix, and release branch. The image explains a typical flow from v1.0, v1.1 to v1.2

If you're looking at this for the first time, then let's define its components:

  • The numbers follow the vertically aligned circles (or nodes) starting from the left and going to the right
  • Each node represents a commit on its respective branch
  • The four horizontal lines represent branches, which are four copies of the entire application's code

Now that you can read it, it's time to break it down one step at a time.

Example Git Flow Breakdown

The following steps show the flow of action in the image presented above.

  1. At the beginning (v1.0), a main and develop branch were made and have identical copies of the code base.
  2. There seems to have been a problem in the main branch, so the fix was made on a new branch created from main called Quicktfix. At the same time, a branch called Feature was created from Develop to presumably start working on a new application feature. Please note that the code written on the quickfix branch will not be present in the Feature branch or the Develop branch.
  3. The quickfix was merged into the main and the develop branches, creating v1.1. This means that main and develop are back to having identical code.
  4. The feature branch was updated with new code.
  5. The feature branch was updated with new code again. Multiple commits are typical like this since you'll often be changing ideas and correcting errors.
  6. The feature branch was merged into develop.
  7. A new branch release was created. This is typically done to have multiple people and teams test the new feature to ensure that clients using the production application (on the main branch) aren't surprised by any errors.
  8. The release branch was updated with new code, maybe because of an error or additional code deemed necessary.
  9. The new feature was confirmed and ready to merge, so both the main and develop branches were updated with the new code and created v1.2 of the app. Both branches are back to being identical as in the beginning, and new features can continue to be added.

This is a lot of information initially, but it is not essential to understand it all right now. It is important to have a big-picture view of how Git is used in the real world. Many specific practices are included in this flow, and many things still need to be addressed, but don't worry: in this course, that's for later down the road. If you'd prefer to build your Git knowledge right away, then check out our course on Git & GitHub.

For now, sit back, relax, and you'll get back to your slower introduction to the world of Git.

Summary: How to Use Git

  • Git can be installed following their online documentation
  • Files must be manually added for Git to track them
  • You commit files to save them in the Git history

Git Real-World Example

  1. git --version to check your current git version
  2. git status to view the status of your tracked and untracked files
  3. git add <file_name> to add a desired file to the staging area
  4. git commit -m <your_message> to commit all files in the staging area with a message
  5. git log to view the history of your previous commits