Learning Git can seem like a daunting task. Like, what do all these commands even mean? Why are my changes not saving correctly? This article aims to provide the basics of how Git works through a small example of creating a new repository on GitHub. I hope that by creating a new repository, you will gain new confidence in how to use Git and potentially how to use it more effectively.

Prerequisites

There are some requirements before getting started with using Git. You will either need a GitHub account or access to an Azure DevOps org. You can sign up for GitHub here. Otherwise, you can just sign into your DevOps org and access the Repos tab. This will be necessary when creating a remote repository in Git so that you can collaborate with others.

Install Git from https://git-scm.com/downloads. Git is supported on Mac, Linux, and Windows. The commands discussed in this article are universal across all three operating systems, but in our examples, the commands are performed on a Windows system.

When installing Git, make sure to select the default options. We will mainly be using Git Bash to perform our Git commands.

I also recommend changing the default editor used by Git from Vim to another text editor. Unless you are comfortable using Vim, feel free to select your preferred text editor from the dropdown. In this article, we will be using Visual Studio Code (VS Code) as the default editor.

Once Git is installed, we can move on to creating a repository.

Initializing a repository

A Git repository is the main source of history for the project. It tracks all your changes to files in the current folder. Creating a new repository is easy by following the steps below.

New repository

To start, I have a test project that has not been initialized as a Git repository.

To create a new repository in the current folder, we can right click into an empty space and select “Open Git Bash here.”

Once Git Bash is open, type the command “git init”. This will initialize an empty Git repository (for now) in the current directory.

If you go back to the current directory in File Explorer, you will notice a new folder named .git. This marks the current folder as a Git repository, and it will be now source controlled. It is also important to note that this repository is local on your machine—it is not in GitHub or Azure DevOps yet. If we were to push this repository into Git, there would be nothing in it, because it is still an empty repository, after all. This is where the following three main Git commands come into play: add, commit, and push.

.gitignore

Before continuing with the main commands, we should add a .gitignore file to the repository. This will exclude the files or folders that we may not want to source control. For example, it isn’t necessary to include the Debug folder because it’s generated after creating a build of the Application1.sln.

To create a new .gitignore file, from Git Bash in the current directory, type “touch .gitignore”. Open this file in your desired text editor, and then we can add the folders and files we want to ignore and not have them be source controlled. This is necessary to avoid cluttering the repository with unnecessary files and folders, not to mention that we don’t want to add sensitive information into source control either. Here’s an example of what the current .gitignore file looks like for our example repository.

The .gitignore file accepts wildcards, so we can exclude the bin and obj folders from any directory. For more useful .gitignore templates, visit https://www.toptal.com/developers/gitignore. This website does a great job of creating .gitignore templates for specific languages, and you can fine-tune it for specific files and folders afterward.

The three main Git commands

Add

A “git add” will add modified files into a staging area of the repository. Think of the staging area as “Are you sure you want to save and track these files?” Another useful command before using “git add” is “git status”. The status command will show you what files have been modified before adding them to the staging area.

After running “git status”, we can see which files are not tracked. Running “git add” followed by a filename will add the specified file to the staging area. Here’s what it looks like after running “git add Application1.sln” followed by a “git status”:

We can see that a new file has been added under the “Changes to be committed” block. If we want to add all the files, we can use “.” instead of a filename as a shortcut. For example,

Here we can see we added every file from the folder, including files from the inner folders that are necessary to run the project. This example also shows the power of the .gitignore file. If we did not have .gitignore in place, we would be including unnecessary files. For example,

We don’t want to bloat our new repository with the /obj or .intellisense folder because these files were generated after using the project in Visual Studio. We would much rather just keep the core files that run the program for the project: the .sln, .synproj, Common.props, and .dbl files. Adding .gitignore is also necessary so that anyone who wants to use the repository can benefit from excluding certain files without adding .gitignore again.

Commit

A “git commit” comes right after a “git add”. In simple terms, “git commit” means “Please save and track these files in the repository.” After using the “git commit” command, you will be prompted by the text editor that you selected at installation to provide a commit message. In this case, VS Code started up and the message “Initial commit” was added. Closing the window saves the commit.

When files are committed, they move from the staging area into the local repository. Thus, our local repository is no longer empty.

Another way to add a message without opening a text editor is to use

git commit -m "<Insert message here>"

In the following example, I added another file and committed with the message “Initial commit” but then decided I didn’t want this file anymore. I deleted the file from the folder and used “git status” to figure out which files have been modified. Afterward, I added the deleted file into the staging area with “git add .”, followed by

git commit -m "Deleted new text document"

Now New Text Document.txt is deleted from the repository and is no longer tracked in source control.

Push

Everything we’ve done so far has been done in our local repository. These changes are saved and tracked on your own machine; they are not yet in GitHub or in Azure DevOps. For this example, we’ll be pushing into GitHub. I won’t cover how this is done in Azure DevOps, but it will be roughly the same steps because you will need to create the remote repository first before performing the first push.

In GitHub, create a new repository. Add any licenses as necessary for your code. Add a README file as necessary. (Since this is just an intro, I’ll skip adding it in this example.)

After we select “Create repository,” another page with some commands will be displayed, and this is where we would push an existing repository. This page is also technically an empty repository because there are no files in there yet. I’ll explain the following commands in more detail instead of just performing them.

git remote add origin https://github.com/sunny-synergex/GitExample.git

The above command is where your remote repository lives. In this example, the remote repository is at https://github.com/sunny-synergex/GitExample.git. You can think of “origin” as an alias to the whole repository URL. This is where the files we have committed will go when pushed to the remote repository.

git branch -M main

This command simply sets the first branch of your remote repository to main. We discuss branches further in the next section.

git push -u origin main

This command pushes all your changes from your local repository main branch into the remote repository main branch of https://github.com/sunny-synergex/GitExample.git. Instead of using the whole URL, we use origin instead. The -u option means we are setting the upstream of the branch, which could be interpreted as mapping the changes between your local changes to the remote changes.

This command is usually only done once, generally with each new branch. Any “git push” afterward does not require the -u option unless you are setting a new upstream to another remote repository.

Going back to Git Bash, enter the following commands, as described above.

After pushing, refresh the page for the newly created repository in GitHub. You should see the files that you initially committed from your local repository that is now being tracked by the remote repository. You have just created a new repository that can be used from GitHub!

To be clear, any changes that you make locally on your machine for this repository are not immediately reflected in GitHub. But by combining the add, commit, and push commands, Git can become very powerful. Now that we have an official remote repository, let’s say that we were already doing some work, but we just realized that a README must be added to the repository.

Performing a “git status” shows that there is a new modification to a file and a new README.

We can simply perform a “git add” on the README.md file and then commit the changes so we can track any changes to the file. This commit is now stored in our local repository.

If we want to push the changes into the remote repository so that others can contribute to the README, a simple “git push” will push this new README into GitHub. We didn’t need to use the “-u origin main” option because a stream (or in other words, a mapping) was already created for the main branch when we did our first initial commit.

Branches

We just created our initial repository with one main branch. In an ideal scenario, the main branch is reserved for tested and production-ready code. This is where branching can come in handy. We can split off from the main branch to make a new feature, knowing that the main branch will be our control until the new feature is fully developed.

In Git Bash, to make a new branch, use the following command:

git checkout -b <branch name>

This command allows you to create and switch to a new branch named “new-feature”. Any development in the new branch is isolated to this branch and will not affect the main branch, the parent branch from which this branch was derived. You can switch back to the main branch using the checkout command without specifying the -b option.

You can perform your add, commit, and push in the new-feature branch. However, since this is a new branch, you will need to set the upstream for this branch, as it is not in the remote repository yet.

In the following example, a new class has been added and the main project has been modified as part of development.

To share this new feature for further development by others, we can add, commit, and push this branch to GitHub.

We can see that a new branch is created, and if we check the GitHub remote repository, a new branch will appear in the dropdown as well.

If we select the branch, we can see that there were modifications to the Application1 folder with the commit message.

Merges

Merging is where things start to get a little difficult, but not by much. Usually merging is done with a “git merge”, a “git pull”, or pull requests.

The “git merge” command brings changes from a specified branch into your current branch. For example, if we create another new branch, named “new-feature2,” we can try to merge it into the new-feature branch. The following example demonstrates what this would look like:

Here are the Git commands on the left:                             Modified to add Hello2 method in Class1

Now to merge correctly, we would need to switch back to the new-feature branch, because we want to apply these changes on top of new-feature.

new-feature2 –> new-feature

After merging, we can see six lines were added to Class1.dbl, meaning that the merge was successful. If we add, commit, and push these changes, they’ll be reflected in the remote repository branch for new-feature in GitHub. If we click the commit message, we can see these changes as well.

Other useful commands

A “git log” shows you the commit history of the current branch you’re on in case you want to review the changes.

Conclusion

Learning how to use Git gives you a powerful tool to keep track of development. We covered how to initialize a new local repository through Git Bash, followed by creating a remote repository on GitHub. These procedures help set up the foundation of collaboration among those who want to work on a project together. Additionally, we covered the bare basics of branching and merging to spark ideas on how to implement and integrate new features using Git. These steps are just the beginning of using Git, but hopefully they will stir your interest in learning how to get the most out of it.