Git in a Nutshell

Let’s dive into version controlling with Git

Photo by Roman Synkevych on Unsplash

Hola, This is the first article on the series Git in a Nutshell. Here we’ll dive through version control with Git. I’m not going for detailed descriptions of Git, instead simple steps to use Git. One.. Two.. Three.. done

Here we go…

An overview look at Git

Git is commonly used in managing source code-related software projects as it is really good at managing text-based content. Git is a distributed version control system which means each user has a complete history of the project as a local copy enabling them to work offline and synchronize with the other repositories at any time later on.

There are two options you can go for when interfering with Git, either a command-line interface or a graphical user interface. I’ll go with the first option. Why?

• Command-line skills are assumed for most modern developer jobs
• Using command line goes hand in hand with automation
• Easy and Fast

Installation and Getting Started

First, check whether Git is already installed in your machine. Open the command line and check the version using the command below. If no version info is shown, you have to install Git first.

git --version

Use the link here to find installation instructions.

Now let’s get familiar with Git syntax. Basic Git syntax is as follows. All Git commands start with the word “git” followed by a space and then the specific command. Following the command can be any number of flags either starts with a single or double dash. As the final section of the Git command arguments can be added.

git [command] [ — flags] [arguments]

Getting help with Git

• Online search on any topic(obviously)
• Within Git itself

git help [command]

Configuring user information and default editor

• Setting username and email

git config [--local | --global | --system] <key> [<value>]

— system : applies to every repository for all users on your computer

— global : applies to every repository that you use on your computer

— local : applies only to the current repository

• Reading username and email

Here the current value of the <key> will be returned. If this command is executed from inside a local repository, local value will be returned. If the local value is not specified, global value and id global value is not specified the system value will be returned.

git config <key>

1. View your current setting for the user name

git config user.name

2. If you want to change the username

git config --global user.name "Your Name"

3. View your current setting with the email address

git config user.email

4. If you want to change the email address

git config --global user.email "your@email"

• Setting Git’s default editor

1. View your current setting for the default editor

git config core.editor

2. If you want to change the default editor

git config --global core.editor your_preferred_editor

nano seems to be a good editor if you haven’t used vi or vim and other options will be Atom or Notepad++.

Commit to a Local Repository

• View file status

git status

Use this command to view the status of the files in the working tree and the staging area.

• Stage content

git add <file-or-directory>

Use this command to add files to the staging area. Staged content is part of the next commit.

• Commit content

git commit -m "initial commit"

Add staged content to the local repository as a commit. Creates a snapshot of the current project.

• View commit history

git log

Can view the commit history of the local repository.

Create a Remote Repository

• Remote repository

This is a professionally managed repository that is held on a data center or a cloud. Center of the truth or the official stage of the project.

Hosted Options:

1. GitHub
2. BitBucket

On-premise Options:

1. GitHub Enterprise
2. BitBucket Server
3. open-source software

A remote repository is a bare repository as nobody works on it locally. Usually, there’s no working tree or a staging area, the root directory of the remote repository is similar to the “.git” directory in the local repository.

• Create Remote Repository

You can use either GitHub or the BitBucket from the hosted options and create a remote repository there. Both pretty much similar and easy, it’s just a matter of clicking buttons :)

• Importing a Repository

Instead of creating an empty repository, you can import an existing remote repository.

Push to a Remote Repository

There are two fundamental options to work with a remote repository. This depends on the availability of the local repository.

1. git clone — no local repository
2. git remote add — have a local repository

We’ll first discuss the first option, where you do not have an existing local repository where you need to create a local repository that is associated with the remote repository.

git clone <url/to/projectname.git> [ localprojectname]

This command creates a local copy of a remote repository where you can work with committing to and pulling new commits. You can copy the URL from the git hosting provider.

When we consider the second option where you already have commits in a local repository and you want to add an association to a remote repository, you can go for the following command.

git remote add <name> <url>

Now you have to push commits to a remote repository. Before pushing you should have an understanding of “branches”.

A quick note:

• All commits belong to a branch
• By default, there’s a single branch — master

We’ll discuss branching and merging in a coming-up article until we’ll push all commits to the master here.

git push [-u] [<repository>] [<branch>]

This command writes commits for a branch from the local repository to the remote repository. Successful push synchronizes local and remote repositories so that both contain the same commits.

For the first push, you should pass the repository URL or the shortcut name which is usually the origin. Also should include the branch name. -u is used to set up a tracking relationship between the local branch and the corresponding remote branch.

The values after the git push are optional because git will assume default information or use previous values after the execution of the first push.

Hope you got an idea of the basic use of Git. Let’s meet with the second part of this article where branching and merging happens.

Cheers..!!