Effective And Efficient Git Workflows — Part 2. Creating And Cloning Repositories And Branching.

Creating And Cloning New Git Repositories And Branches.

Introduction

Every post builds upon the previous ones so please try not to skip and go sequentially even if you think you know some of the information already. You will probably pick up one or two golden nuggets along the way.

Part 1 In this series is in the link below if you haven’t read it already.

Effective And Efficient Git Workflows — Part 1.

Objectives

• Install Git on your local machine.
• Create a new Git repo from scratch.
• Create new Git branches and navigate between the different branches.
• Create new files and make changes in different branches and permanently add the changes to Git for tracking.

Prerequisites

Please read and refer back to the first post in this series as we are building upon it as we go along. We will constantly refer to concepts already discussed there so it will make it easier to follow along. Also a basic grasp of the command line is required to follow along.

Installing Git

The first thing you want to do is to install Git if you haven’t done so already. If you have it installed already it’s always a good idea and best practice to update to the latest version as well to get the latest and greatest features.

I am not going to go into details about how to install Git here so here is a link to the installation instructions for both Mac/Linux and Windows from the official Git website.

https://git-scm.com/book/en/v2/Getting-Started-Installing-Git

After completing the instructions in the link you need to make sure that Git was installed properly by running the following command in the terminal.

git –version

Depending on your environment you might need to restart the terminal window before it picks up on the new Git installation. If you see no output it means that Git wasn’t installed properly or is not in your command line path.

As of the time of writing this post the latest version of Git is 2.36.0. Once you have Git installed you can proceed and follow along with the rest of the post. It’s important that you manually type out all the commands especially if you are new to Git because it makes it much easier to retain the information.

Cloning and Initializing New Repos. Two Main Ways To Get A Git Repo On Your Local Machine.

Now that we have Git installed it doesn’t automatically track and manage our projects so we have to let Git know which projects/folders we want it to keep track of.

There are two ways we can get Git to create a repository and start tracking changes on our local machines.

The first is to initialize a brand new Git repo from scratch. The second is to clone an existing repo. Cloning is basically copying an existing repo from another machine to yours. We will take a look at how to do the first one now and clone an existing repo later.

How To Create A Brand New Git Repo From Scratch.

To create a new repo we run the following command in the folder we want to create the new repo in. This will create a new Git repo and Git will start tracking and managing any changes we make in that folder going forward.

git init

As you can see from the init output above Git created a new repo in the folder and has an initial branch called master. Master is usually the default branch created and this default can also be changed in the configs or by renaming directly as described in the command output.

There should also be a new hidden directory in the same folder named .git. Don’t touch or delete anything in that folder as it’s where Git actually keeps everything in the repo so it’s easy to mess it up if you start making changes in that directory.

Note how the Git output also gives us a lot of information including what just happened and also how to proceed. It’s really important to pay attention to the Git output as it usually gives us hints on what to do next or how to proceed if something goes wrong.

What is a branch?

Git Branching Example. Copyright Lexical Magazine.

To understand what a branch is we just have to look at what Git does. It’s a version control system which means it keeps and manages different versions of our projects. A branch is just one of those versions that Git keeps track of.

Branches allow us to keep track of the different versions and changes within our project without overwriting other versions. Just like branches in a real tree Git branches can branch from the trunk or also from other branches thus sharing common content until the branches diverge.

Git status

Now we have initialized a new Git repo from scratch we can use git status to check the status of our repo.

As you can see from the output Git tells us that we are on the master branch. It also gives additional information. E.g. we haven’t made any commits into the repo yet.

We can also see that we have nothing staged to be committed. Once you start adding files and doing other things the status message will also have more details on the state of your repo.

You can review and refer back to this Git Lifecycle diagram to fully understand what’s happening when we do all the Git operations in the rest of the post.

Git Life Cycles. Copyright Lexical Magazine

Adding files to Git.

Create a new file named ParentClass.js in the same folder that you initialized the new Git repo in. Run git status again to see the new state of the repo. You should see something similar to what’s below.

As you can see Git immediately recognizes that we have added a new file but it also lets us know that this file is still not being tracked. This is very important because if a file isn’t tracked yet we can still lose changes made in it permanently if we accidentally delete it. This is because the file is still in the working index of the Git lifecycle until we commit it into the local repo.

Add and save the following content to the file.

As suggested by the Git output we can stage this file before committing it by running the following command.

git add ParentClass.js

After running the add command above there is no output returned from Git at all. It doesn’t mean that nothing happened. A lot of Git commands don’t give any visible output but that doesn’t mean nothing happened. In most cases a lack of output often means that Git completed the operation without any issues.

We can check the new state of the repo by running git status again.

As you can see from the status the file was successfully staged and is ready to be committed now. We run the following command to commit the file.

git commit -m “Initialized a new Git repo and added the ParentClass file”

The commit command tells git that we are ready to permanently add the file to Git and start tracking any changes to the files. The -m flag is how we add a message/description of what we changed and added. It’s always a good practice to be as descriptive as possible in the message so others can easily tell what was changed or added.

After running the commit command Git lets us know that 1 file was added to the repo and also saves the message we added as part of that commit for reference. Git creates a pointer to every commit we make and also creates a snapshot of the whole repo at that point in time.

Each commit is named using a hash of the file contents, in this case 4673c19. The whole hash is 40 characters long but Git always displays a shortened version.

Note: Only changes that are staged will be committed so if you have changes or files that are not ready yet just don’t stage them and they won’t affect the rest of the repo yet.

We run git status again.

As you can see we now have nothing to commit and the working tree is clean. This just means we don’t have any changes in the working tree at this point.

Creating a new branch.

Git uses the checkout command to switch from one branch to another. git checkout branch2 will switch the local working tree to branch2. We only have a single branch, master, so we can let Git know we are creating a new branch and switching to it in one command by adding the -b flag to the checkout command.

git checkout -b branch1

We get the following output with Git telling us that we have now switched to a new branch called branch1 so we can start making changes in that branch without affecting what we have in the master branch.

Switched to a new branch 'branch1'

Now that we have switched to a new branch we can add the following function to the ParentClass file and save.

branch1Method() {
    // this is made in branch1
}

If we run Git status again we can see that Git tells us that we now have a modified file that we can stage and commit whenever we are ready. The main difference is that unlike when the file was new in the master branch it is now already being tracked although this is a new branch altogether.

We can add the file to be committed but before we do that we might need to know what has changed especially if we made a lot of changes to a file. To do this we can run git diff. This will tell us the differences between the file we are about to commit vs the version of the file that Git is already tracking.

Any lines in the output preceded by the + sign means that it’s a new net new line that was added. If we remove any lines they will also be preceded by a negative sign.

Now we have reviewed and are satisfied that these are the changes we really want to commit we can go ahead and do so. We just need to add the file to the staging area and then commit the changes.

git add ParentClass.js
git commit -m “Added a new function called branchMethod”

Now the new changes are being tracked in branch1 so we can switch back to the master branch and double check that nothing was changed there as well.

git checkout master

Once we switch back to master we can verify that the changes we made in branch1 are not on master branch also. That’s the behavior we want because we want to work on different versions of our project without interfering with other developers or existing files until we are ready to do so.

Conclusion.

As you can see Git is a very powerful and versatile tool that we can utilize to keep different branches and changes allowing us to test new features and experiment without the fear of losing work already completed.

This power can unfortunately also lead to a very complicated web of branches and files if it’s not managed properly. We are slowly building to the different strategies and workflows that can be used to manage these complexities in projects as they grow bigger and more complex over time.

In the next post in the series we will be looking at how to clone an existing repo and also go a little deeper into branches and commits.

Make sure to leave a comment below if you have any questions or input you want to add. Also follow us to get notified when any new posts in this series drop in the future.

You can read part 1 linked below if you haven’t already.

https://medium.com/lexicalmagazine/effective-and-efficient-git-workflows-part-1-a1a4e2a3b1ed