Search icon CANCEL
Cart icon
Close icon
You have no products in your basket yet
Save more on your purchases!
Savings automatically calculated. No voucher code required
Arrow left icon
All Products
Best Sellers
New Releases
Learning Hub
Free Learning
Arrow right icon
Git for Programmers
Git for Programmers

Git for Programmers: Master Git for effective implementation of version control for your programming projects

By Jesse Liberty
$43.99 $29.99
Book Jun 2021 264 pages 1st Edition
$43.99 $29.99
Free Trial
Renews at $15.99p/m
$43.99 $29.99
Free Trial
Renews at $15.99p/m

What do you get with eBook?

Product feature icon Instant access to your Digital eBook purchase
Product feature icon Download this book in EPUB and PDF formats
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want
Table of content icon View table of contents Preview book icon Preview Book

Git for Programmers

Creating Your Repository

In this chapter, you will learn how to create an account on GitHub, and how to create and clone your first repository so that you have a link between the repository on your computer and that on GitHub.

This chapter will cover:

  • Creating your repository
  • Git pull
  • Push me, pull you
  • Starting at the command line
  • Commits – best practices

We'll start by creating your GitHub repository.

Creating your repository

There are a number of different ways to create your repository. We'll cover creating a repository on GitHub and cloning it to your disk, as this is the most common way.

Creating your repository on GitHub first

Your first step is to register with GitHub. Go to and click Sign Up. Fill in your username (it will tell you if the name is taken) and your email and it may ask you to verify that you are a human. Assuming you are, click Create Account.

Fill out their micro-survey and click Create Account. You will be asked to verify your email, and once you do, you'll see the (one-time) opening page asking what you want to do first. Choose Create a repository:

Figure 2.1: Getting started with GitHub

If you already have an account, sign in and press New Repository. You may not find this at first glance, in which case click the big plus sign in the corner.

Either way, you will be brought to the Create A New Repository page. The first job is to give your new repository a name. I'll use ProGitForProgrammers. Feel free to use any name you want as long as GitHub doesn't complain that the name is taken.

Now it is time to fill in the form:

Figure 2.2: Creating the repository

Start by entering a short description of your project. Next, and very importantly, choose whether you want this repository to be public (anyone can see it) or private (only people you invite can see it).

I strongly recommend checking Add a README file. This will be what is shown to users when they come to your repository. You can fix the file up later using Markdown.

Be sure to add a .gitignore file. This tells Git which files to ignore when checking your files into the repository. This can be very important so that you don't overwrite another programmer's metadata files. Click the dropdown and admire how many languages are supported; for C# I recommend you search for and choose Visual Studio.

If your repository is public, be certain to choose a license for the code. I chose the MIT License. You can learn more about this license at

That's it! You are ready to click Create repository. When you do, you'll be brought to the home page for your new GitHub repository:

Figure 2.3: Initial view of your repository

Notice that you have the three files you asked for, and that you can see a preview of the README as well as the description you entered.

Right now, this repository exists only on the server. You want to put a copy on your disk so that you can add code and use commands to keep them in sync. Therefore you will "clone" the repository; that is, you'll make an exact copy of the remote repository in your local repository.

How you will do this will depend on whether you are using the command line, Visual Studio, or a GUI.

Cloning to your computer – command line

Cloning to your local repository is easy. Open your terminal (or PowerShell) and change the directory to where you want the repository to go (in my case GitHub/the command line).

Switch back to your GitHub repo on, and see the green button in the upper right-hand corner marked Code. Click that button and a small dialog box will open. Choose HTTPS unless you know you have SSH (as I do). In either case, click on the clipboard icon to copy the address:

Figure 2.4: Copying the address of the repo

Return to the command line, enter git clone, and then paste in the address:

git clone

You should see something like this:

Figure 2.5: Cloning at the command line

Change the directory to ProGitForProgrammers and you'll see that the three files that were on the server are now here as well:

Figure 2.6: Files in the directory

Now let's take a look at how to do this in Visual Studio.

Cloning to your computer – visual studio

Go to your directory (in my case GitHub) and make a directory called VisualStudio.

Open Visual Studio with no project. Select File | Clone Repository. Fill in the fields and click Clone:

Figure 2.7: Cloning to your local repository using Visual Studio

A few seconds later you will see the three files, now shown in the Solution Explorer:

Figure 2.8: Cloned files in Visual Studio

There are a number of ways to clone from a GitHub repository to your own. One way is to use a dedicated GUI tool such as GitHub Desktop.

Cloning to your computer – GitHub for Desktop

Once again, return to your root directory (GitHub) and make a new directory. This time call it GitHubDesktop.

Now, return to GitHub and click Code:

Figure 2.9: Cloning directly through GitHub Desktop

Notice that one of the choices is Open with GitHub Desktop. Click on that. A dialog will open. The only field you need to fill in is the local path. Click Clone:

Figure 2.10: Cloning to GitHub Desktop using HTTP

Notice that GitHub Desktop wants the https URL for your repository.

You now have three copies of your original repository, each in its own directory: CommandLine, VisualStudio, and GitHubDesktop. These might represent three programmers working on the same solution, or various ways for one programmer to choose to clone their project.

Creating a project

We need a project. Using Visual Studio (or your favorite editor) create a project called ProGitForProgrammers in the CommandLine directory. When you are done, you should have the three original files and a folder for your program. In that folder will be the .sln file as well as a folder for the code.

Open the command line and navigate to the same directory. When you get there your command line should look something like this:

Figure 2.11: The command-line prompt

Look at the yellow, where you see +1 ~0 -0. The +1 means you've added a file or a directory; the ~0 indicates that no files have been modified; the -0 indicates that no files have been deleted. Let's see what was added. Enter:

git status

You should see something like this:

Figure 2.12: Untracked files

Git is telling you that you are on the branch main (the only branch for now) and that you have "untracked files" – that is, files that are in the directory but that are not being tracked by Git. If they are untracked, Git can't store them; in fact, Git knows nothing about them. Let's fix that. Enter these commands:

git add ProGitForProgrammers/
git commit -m "First commit – from command line"

add tells Git that this is a file it should pay attention to and commit brings it into the local repository.

Every commit must have a message, and if you don't provide one, you'll be prompted by Git to add one. Here I've added it by using the -m flag.

Once again, all this is happening locally and so GitHub doesn't know about it. We can fix that by pushing our commit up to the server:

git push

Now if you go to GitHub and refresh the page your project will be there. You can click your way down through the folders, and even into Program.cs, to see the code:

Figure 2.13: Viewing your code on GitHub

Notice in the upper left that it tells you that you are on the main branch. Next to that is the path to get to Program.cs. Below that is the message you added, and then the file itself.

Git pull

Having pushed your commits to the server, other developers may want to pull them to their own directory, to keep in sync.

Pulling down using GitHub Desktop

Having put the project up on the server, we can simply pull it down into the other locations. For example, open GitHub Desktop. It will tell you that there have been changes in the repository and helpfully offer a button for you to update your local repo.

If you open a file explorer and navigate to the GitHubDesktop directory, you'll see that there is now a replica of the files you pushed from the command line.

Pulling down to Visual Studio

Click on the Git menu and choose Pull. Visual Studio is updated with the code from the server. Now all three repositories are up to date. This is the heart of Git:

  • Save your files to a local repository
  • Push your files to the remote repository
  • Pull down any files that are on the remote repository but not on your local repository

Push me, pull you

Generally, you want to push your changes and pull down changes from other developers. Also, generally, you will not be working on the same files, and certainly not in main. We'll discuss how to avoid this in Chapter 4, Merging Branches. For now, we'll just be very careful.

Open Visual Studio in the directory GitHub/VisualStudio/ProGitForProgrammers. Add a line to Program.cs as shown here:

namespace ProGitForProgrammers
    class Program
        static void Main(string[] args)
            Console.WriteLine("Hello World!");
           Console.WriteLine("I just added this in Visual Studio");

Having made your change, you want to check it in. Since we are in the VisualStudio directory, we'll do the work right within Visual Studio. Click the Git menu and choose Commit or Stash. A Git window will open as a tab next to Solution Explorer. Enter a commit message and press Commit All:

Figure 2.14: Git window in Visual Studio

Note that if you drop down the Commit All menu, you have a number of shortcuts for adding, committing, and pushing your changes.

As you can see, and will see often in this book, you can do almost anything in Visual Studio that you can do at the command line.

Pushing to the server

You have now committed your changes to your local repository. The GitHub repository, however, doesn't know about your changes. (You can prove this to yourself by returning to GitHub and drilling down to Program.cs.)

The other programmers' repositories (for example, CommandLine and GitHubDesktop) are equally oblivious. To disseminate this change, you first push your changes up to the server (GitHub) and then pull them down to the other repositories.

From within Visual Studio's Git window, press Staged. This will stage your changes for committing. Next, click Commit. This will put your changes into your local repository (be sure to give the commit a meaningful message).

Examine the Git window; there is a lot of information:

Figure 2.15: The Git window in Visual Studio

You are told that the commit was created locally (and locally is the important part!). Below that is the status of your commit. You have one to push up to the server (outgoing) and none to bring down (incoming):

Figure 2.16: Uploading a commit from Visual Studio

Now, find the up-pointing arrow in the upper-right corner. Hover over it and you'll see that it says Push. Click that button to push your changes to the server. When it is done, it will give you a success message. Ignore the offer to create a pull request for now.

Look to the left of your Git menu and see the local history of your commits:

Figure 2.17: The history of commits

Each dot signals a commit, and next to each dot is your commit message (and now you can see why meaningful commit messages are both hard to write and worth the effort). There is also an indicator that main is pointing to your last commit.

If you check GitHub (remember to refresh the page) you will now see the line in Program.cs. Make sure you understand why: this is because after we committed the change, we pushed it to the remote repository.

Downloading the changes at the command line

We created the changes in the VisualStudio directory. CommandLine and GitHubDesktop know nothing of the changes, even though they are now on GitHub.

For these directories to know about the changes, you need to pull the changes down.

Change directories to CommandLine. Examine the contents of Program.cs; the new line is not there. Open your terminal and enter pull. This will pull any changes from the server to your local repository.

The result should look like this:

Figure 2.18: Pulling from the remote repository

Git is telling you that it formatted and compressed your files and passed them down to your repository. Toward the bottom it says that it used Fast-forward. We'll discuss this in Chapter 4, Merging, Pull Requests, and Handling Merge Conflicts.

Take a look at Program.cs now in your command directory; the new addition should now be there.

Want to do something cool? Open the Program.cs file before updating. After the update you will see the second WriteLine pop into view. What is actually happening is that the code that was in your directory is replaced by the new code on the pull.

Downloading the changes using GitHub Desktop

Change directories to GitHubDesktop and open the GitHub Desktop program. It will give you a lot of information about the status of your repository (No Local Changes) and it will automatically check and inform you that there is one commit to update your local repository with:

Figure 2.19: The view from the remote repository

Go ahead and click Pull origin. It does the pull, and the button disappears. Check your code; the change should now be in your Program.cs (and is recorded in your local repository).

All three local repositories and the server repository are now in sync.

Starting at the command line

You can start the process at any of our repositories. Last time we started in the VisualStudio repository and then pulled the changes down to the CommandLine and GitDesktop repos. This time, let's start at the command line.

Open Visual Studio and point it to the project in your CommandLine directory. Just to be certain, right-click on Solution, select Open Folder in File Explorer, and make sure you are in the right directory.

To keep this example very simple, we'll just add another line to Program.cs:

class Program
    static void Main(string[] args)
        Console.WriteLine("Hello World!");
        Console.WriteLine("I just added this in Visual Studio");
        Console.WriteLine("I just added this in the command line repo");

Normally you would make many more changes before checking in, but again, this is a demo and we're more interested in using Git than we are in fussing with this silly program. Save all your files and at the command line get the status by entering:

git status

This will give you output that looks like this:

Figure 2.20: The command line indicating one file has been modified

The key piece of information is the modified file. That is just as it should be, as that is the file we modified. You can now add it to the index and then commit it:

git add ProGitForProgrammers/ProGitForProgrammers/Program.cs
git commit -m "Add writeline indicating we are in command line"

On the other hand, you can combine these two steps with the -a flag:

git commit -a -m "Add writeline indicating we are in command line"

You will want to draw a distinction between untracked files and modified files. Untracked files are outside of Git and cannot be manipulated inside Git until they are added; modified files are tracked by Git but have changed since the last commit.

If we are happy with the commit we've added, we can (optionally) push it to the server:

Figure 2.21: Pushing our commit to the remote repository

We'll want to do that because we want to share this code with the other programmers.

Pulling to GitHub Desktop

Switching to GitHub Desktop, we see that it already knows there is something to pull, as we saw last time. (If it doesn't, push the Fetch button, which will go to the server to see if there is anything to bring back.)

That's two repos that are identical, but the VisualStudio repo is not yet up to date. Let's return to Visual Studio in the VisualStudio folder.

Pulling to Visual Studio

Open the Git menu item, and select Pull. Watch your source code and see the third line pop into existence. Once again, the three local repositories and the remote repo are all in sync.

Commits – best practices

Like everything else in programming, best practices in commits are, to some degree, controversial. The first issue is frequency.

How often should I commit?

There are those who say a commit should be atomic: representing exactly one unit of work (one task, one bug fix). No more and no less. So, according to this line of thought, if you are in the middle of work and you get called away, you should not commit, but you should use the stash. The stash is an area where you can put files that you want to come back to later. You can name sets of files that you stash, and then pick the one you want to restore by name.

This is a defensible position, but I hold the opposite: commit early and commit often.

Commits are cheap and fast in Git, and interactive rebase (see Chapter 6, Interactive Rebasing) allows you to "squash" commits together. Therefore, if you are working on a feature and you make five interim commits before you are done, you'll have the opportunity to squash them into a single commit with a single message. This is the best of both worlds: you secure your interim work with a commit, and you present only one commit (rather than five) to the server.

Keep your commit history clean

The first way that a programmer reviews your code is to look at the list of commits and then dive into those that are interesting. A good history of commits with well-written messages is a delight to review. A long, tedious history with meaningless messages is only slightly more fun than eating glass.

A note on commit messages

As you will see later in this book, commit messages are very important for anyone (including you) reviewing your commit history. By convention, commit messages should be in the imperative, and should tell you exactly what is in that commit.

Fixing some files                        // bad
Fix WriteLine in helloworld.cs           // good

In practice you'll often find comments in the past tense:

Fixed WriteLine in helloworld.cs         // good enough
"In theory, theory and practice are the same; in practice, they never are." -- Pat Johnson

It pays to get into the habit of writing good messages in the right format. Your teammates will thank you.

When the title isn't enough

The message title should be kept to 50 characters. Most of the time this is enough, but if it isn't, leave the -m message off and let Git open your editor. There you can add additional information. Skip a line after the header and consider using bullet points or other ways of making the things you want to convey easy to read.

Important: By default Git uses vi (a Unix editor). You'll want to enter:

git config ––global core editor "code -w"

This ensures that Visual Studio Code is your default editor:

Figure 2.22: Editing in Visual Studio Code

Note that # is the comment character, and all lines that begin with # will be ignored.

When you use log (see Chapter 9, Using the Log) to see your history (or view history in Visual Studio, etc.) you'll see the entire message:

Figure 2.23: The output of the log command

You can see just the headers if you want, using git log -–oneline, but we'll leave the details for Chapter 9, Using the Log:

Figure 2.24: log using the oneline flag


In this chapter, we have covered a number of topics relating to creating and interacting with your repository. We discussed:

  • Creating your repository
  • The relationship between your local and remote repositories
  • Git pull
  • Git push
  • Starting at the command line
  • Using Visual Studio
  • Commits: best practices

In the next chapter, we'll take a look at the various places Git keeps your files, and the relationship between adding an untracked file and committing a tracked file.

Left arrow icon Right arrow icon

Key benefits

  • Master Git and maintain your projects better through version control
  • Get to grips with Git’s typical workflows, advanced functions, and their implementations
  • Learn the key Git commands to better manage your repository


Whether you’re looking for a book to deepen your understanding of Git or a refresher, this book is the ultimate guide to Git. Git for Programmers comprehensively equips you with actionable insights on advanced Git concepts in an engaging and straightforward way. As you progress through the chapters, you’ll gain expertise (and confidence) on Git with lots of practical use cases. After a quick refresher on git history and installation, you’ll dive straight into the creation and cloning of your repository. You’ll explore Git places, branching, and GUIs to get familiar with the fundamentals. Then you’ll learn how to handle merge conflicts, rebase, amend, interactive rebase, and use the log, as well as explore important Git commands for managing your repository. The troubleshooting part of this Git book will include detailed instructions on how to bisect, blame, and several other problem handling techniques that will complete your newly acquired Git arsenal. By the end of this book, you’ll be using Git with confidence. Saving, sharing, managing files as well as undoing mistakes and basically rewriting history will be a breeze.

What you will learn

Create remote and local repositories and learn how to clone them Understand the difference between local and remote repositories Use, manage, and merge branches back into the main branch Utilize tools to manage merge conflicts Manage commits on your local machine through interactive rebasing Use the log to gain control over all the data in your repository Use bisect, blame, and other tools to undo Git mistakes

Product Details

Country selected

Publication date : Jun 30, 2021
Length 264 pages
Edition : 1st Edition
Language : English
ISBN-13 : 9781801075732
Category :
Concepts :

What do you get with eBook?

Product feature icon Instant access to your Digital eBook purchase
Product feature icon Download this book in EPUB and PDF formats
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want

Product Details

Publication date : Jun 30, 2021
Length 264 pages
Edition : 1st Edition
Language : English
ISBN-13 : 9781801075732
Category :
Concepts :

Table of Contents

16 Chapters
Preface Chevron down icon Chevron up icon
1. Introduction Chevron down icon Chevron up icon
2. Creating Your Repository Chevron down icon Chevron up icon
3. Branching, Places, and GUIs Chevron down icon Chevron up icon
4. Merging, Pull Requests, and Handling Merge Conflicts Chevron down icon Chevron up icon
5. Rebasing, Amend, and Cherry-Picking Chevron down icon Chevron up icon
6. Interactive Rebasing Chevron down icon Chevron up icon
7. Workflow, Notes, and Tags Chevron down icon Chevron up icon
8. Aliases Chevron down icon Chevron up icon
9. Using the Log Chevron down icon Chevron up icon
10. Important Git Commands and Metadata Chevron down icon Chevron up icon
11. Finding a Broken Commit: Bisect and Blame Chevron down icon Chevron up icon
12. Fixing Mistakes Chevron down icon Chevron up icon
13. Next Steps Chevron down icon Chevron up icon
14. Other Books You May Enjoy Chevron down icon Chevron up icon
15. Index Chevron down icon Chevron up icon

Customer reviews

Top Reviews
Rating distribution
Empty star icon Empty star icon Empty star icon Empty star icon Empty star icon 0
(0 Ratings)
5 star 0%
4 star 0%
3 star 0%
2 star 0%
1 star 0%
Top Reviews
No reviews found
Get free access to Packt library with over 7500+ books and video courses for 7 days!
Start Free Trial


How do I buy and download an eBook? Chevron down icon Chevron up icon

Where there is an eBook version of a title available, you can buy it from the book details for that title. Add either the standalone eBook or the eBook and print book bundle to your shopping cart. Your eBook will show in your cart as a product on its own. After completing checkout and payment in the normal way, you will receive your receipt on the screen containing a link to a personalised PDF download file. This link will remain active for 30 days. You can download backup copies of the file by logging in to your account at any time.

If you already have Adobe reader installed, then clicking on the link will download and open the PDF file directly. If you don't, then save the PDF file on your machine and download the Reader to view it.

Please Note: Packt eBooks are non-returnable and non-refundable.

Packt eBook and Licensing When you buy an eBook from Packt Publishing, completing your purchase means you accept the terms of our licence agreement. Please read the full text of the agreement. In it we have tried to balance the need for the ebook to be usable for you the reader with our needs to protect the rights of us as Publishers and of our authors. In summary, the agreement says:

  • You may make copies of your eBook for your own use onto any machine
  • You may not pass copies of the eBook on to anyone else
How can I make a purchase on your website? Chevron down icon Chevron up icon

If you want to purchase a video course, eBook or Bundle (Print+eBook) please follow below steps:

  1. Register on our website using your email address and the password.
  2. Search for the title by name or ISBN using the search option.
  3. Select the title you want to purchase.
  4. Choose the format you wish to purchase the title in; if you order the Print Book, you get a free eBook copy of the same title. 
  5. Proceed with the checkout process (payment to be made using Credit Card, Debit Cart, or PayPal)
Where can I access support around an eBook? Chevron down icon Chevron up icon
  • If you experience a problem with using or installing Adobe Reader, the contact Adobe directly.
  • To view the errata for the book, see and view the pages for the title you have.
  • To view your account details or to download a new copy of the book go to
  • To contact us directly if a problem is not resolved, use
What eBook formats do Packt support? Chevron down icon Chevron up icon

Our eBooks are currently available in a variety of formats such as PDF and ePubs. In the future, this may well change with trends and development in technology, but please note that our PDFs are not Adobe eBook Reader format, which has greater restrictions on security.

You will need to use Adobe Reader v9 or later in order to read Packt's PDF eBooks.

What are the benefits of eBooks? Chevron down icon Chevron up icon
  • You can get the information you need immediately
  • You can easily take them with you on a laptop
  • You can download them an unlimited number of times
  • You can print them out
  • They are copy-paste enabled
  • They are searchable
  • There is no password protection
  • They are lower price than print
  • They save resources and space
What is an eBook? Chevron down icon Chevron up icon

Packt eBooks are a complete electronic version of the print edition, available in PDF and ePub formats. Every piece of content down to the page numbering is the same. Because we save the costs of printing and shipping the book to you, we are able to offer eBooks at a lower cost than print editions.

When you have purchased an eBook, simply login to your account and click on the link in Your Download Area. We recommend you saving the file to your hard drive before opening it.

For optimal viewing of our eBooks, we recommend you download and install the free Adobe Reader version 9.