AND WHAT DO YOU KNOW ABOUT GIT?

Today we will speak about git. Git is a distributed system for managing file versions which was created by Linus Torvalds in 2005.

It synchronizes work with the site and stores/updates versions of files, what is very useful if several developers work on the project at the same time. This allows you to update and edit project files, taking into account changes made by others.

If you want to refresher knowledge, you can do this by clicking on the link https://git-scm.com/. Here you can find more interesting and useful information about git.

BASIC GIT COMMANDS

Create a new project

If you want to create a new local repository you need to use this command:

> git init

Checkout a repository

When you need to create a working copy of a local repository you need run this command:

> git clone <PATH_TO_REPOSITORY>

For a remote server command will be as follows

> git clone username@host:<PATH_TO_REPOSITORY>

Add and commit

If you need to add one or more files to staging then you need to use

> git add <FILENAME>

The next command allows you to commit changes to head:

> git commit -m "Commit message"

Pushing changes

Command

> git push origin master # or git push (origin, master is default parameters)
allows send changes to the master branch of your remote repository.

In the case if you haven't cloned an existing repository and want to connect your repository to a remote server, you need to use this command.

> git remote add origin <server>

Branching

We use branches for developing features which isolated from one another. When you create a repository the master branch is the “default” branch. To create new branches with name develop and switch to it use next command:

> git checkout -b develop

To switch back to master branch use:

> git checkout master

And if you want to delete the branch then you need the following command:

> git branch -d develop

If you want to have a remote branch, then push it to your remote repository:

> git push origin <BRANCH_NAME>

Merge and update

For updating local repository with remote use command:

> git pull

To merge another branch with your active one use:

> git merge <BRANCH_NAME>

In both cases git tries to auto-merge changes, but sometimes there are conflicts that can not to be automatic resolved. You can merge those conflicts manually by editing the files shown by git and after changing just add files with command:

> git add <FILENAME>

Diff

Before merging changes, you can also preview them by using diff command:

> git diff <SOURCE_BRANCH> <TARGET_BRANCH>

ADVANCED COMMANDS

Tagging

It’s recommended to create tags for your software releases. This is concept also exists in SVN. For example, if you want to create a new tag named 1.1.0 need to execute:

> git tag 1.1.0 1e3s11ff3a

1e3s11ff3a is the first 10 characters of the commit id you want to reference with your tag.

Log

If you want to get the repository history then execute this:

> git log

You can use a lot of options to make the log return different results. To see only the commits of a certain author (example, opengeek):

> git log --author=opengeek

To see commits compressed to one line comment:

> git log --pretty=oneline

If you want to see commits which files have changed:

> git log --name-status

To see more options of log use command:

> git log --help

Pull upstream changes with rebase

The merge is always recorded with a merge commit. Of course, they can be used to indicate that a new feature has been merged into a release branch. However, when big team work on a single project and often sync branches with a git pull, the commit timeline have a lot of unnecessary merge commits. A better method might be to use git rebase to rebase a develop branch into a master branch instead of merge it (and create another unnecessary commit):

> git checkout develop
> git rebase master

This command move the entire develop branch to begin on the tip of the master branch. If you want to get a much cleaner project history then you will find useful to use rebase instead of merge.

Clone a specific remote branch

Sometimes you want to clone only a specific branch from a remote repository. You can simply git clone all branches but here is alternative command to solve it:

> git init
> git remote add -t <REMOTE_BRANCH> -f origin <REMOTE_REPO_URL>
> git checkout <LOCAL_BRANCH>

Cherry pick commit to your branch

If you want to get only a specific commit from a remote repository on your branch then use git cherry-pick to get the commit with a given SHA and merge it into the current branch:

> git cherry-pick <SHA>

Ignore changes in a tracked file

Sometimes you can have environment-specific configuration files, which you want to don’t trach and don’t push to server. You can use the following command to tell git not to track a file:

> git update-index --assume-unchanged <PATH_TO_FILE>

Clean

If you want to clean the working tree by removing files that are not under git then use the following commands:

> git clean -f     # remove untracked files
> git clean -fd    # remove untracked files and directories
> git clean -nfd   # list all files and directories that would be removed

CONFIGURING

At first we will create a .gitconfig file which is the main for all git customizations, configurations and aliases. Here is example of .gitconfig file:

[user]  
   email = opengeeklab@gmail.com
   name = Open Geek
[core]
   editor = vim
   ignorecase = false
[color]
ui = true
interactive = auto
branch = auto
diff = auto
status = auto
[push]
   default = simple
[color "branch"]
current = green bold
local = green
remote = red bold
[color "diff"]
   meta = yellow bold ul  
   frag = cyan bold ul
   old = red bold  
   new = green bold
[color "status"]  
   added = green bold  
   changed = yellow bold  
   untracked = red bold
[grep]
   break = true
   heading = true
   lineNumber = true
[alias]
c = commit
g = grep --break --heading --line-number
s = status
d = diff

Git will preload and use these configurations for all subsequent commands once the file exists. If you run the command git diff you will see how colors have changed.

Also you can see a git alias, which is basically shorthand for commands. In this case, git grep can be executed with shorthand command:

> git g # is equivalent for command “git grep --break --heading --line-number”

Also in the section for [grep] you can specify arguments and options which will be applied every time when you use git grep.

So, for each command there are a lot of settings with extensive number of options. If you want to know more about it you can read the official gitconfig documentation.

Commit template

In case when you set way to the file on your system git will use it like default message when you commit.

For example, suppose that you create a template file at ~/.gitmessage.txt. This will be looks like this:

subject line
what happened
[ticket: X]

To use this commit template as default message that appears then your run git commit, you need to add commit.template to configuration:

$ git config --global commit.template ~/.gitmessage.txt
$ git commit

Then, your editor will open to something like this for your placeholder commit message when you commit:

subject line
what happened
[ticket: X]
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
# modified:   index.android.js
#
~
~
".git/COMMIT_EDITMSG" 14L, 297C

GOOD COMMIT MESSAGES

Good commit messages allow us to speed up the reviewing process and help write a good release note. So, let’s talk about how to write good commit messages. There are 7 rules:

1. Separete by blank line subject from body

On the git commit manpage you can read the next:

Though not required, it’s a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough description. The text up to the first blank line in a commit message is treated as the commit title, and that title is used throughout Git. For example, Git-format-patch(1) turns a commit into email, and it uses the title on the Subject line and the rest of the commit in the body.

2. 50 characters is limit for the subject line

50 characters it is not hard limit, it is only rule which is recommended for good commit messages. These characters are enough to explain what’s going on.

3. Use capital letter in the subject line.

Which of these two lines looks better?

I think we can all agree that the first line looks better.

4. Do not put a period at the end of subject line.

In this case period is unnecessary thing.

5. In the subject line use the imperative mood

All 7 rules which you are reading now are written in the imperative mood. Imperative mood is perfect for git commit subject line.

6. Wrap the body at 72 characters

You need to know that git never wraps your text automatically. So, when you write the body of a commit message you need to wrap text manually. Doing this is recommended at 72 characters. For this you can use text editor. You can easily to configure Vim and when you write a commit message the text will wrap at 72 characters.

7. Use the body line to explain why, what and how

Don’t tell about how a change has been made. Code is generally self-explanatory. If not that’s what source comments are for (some complex library for example). Just focus on making clear the reasons why you made the change and what was wrong before