
[Watch the video on YouTube](https://www.youtube.com/watch?v=uj_e_tGPfPE)

In this article I'll list 5 git tools that you must use today.

## Hub

[Hub](https://hub.github.com/) is my favourite tool and I use it a lot. If you use GitHub to store your repositories - this tool will save you a ton of time.

It automates creating new repos, making new pull requests, forking repos and filing issues. 

There are a ton of other features and options - so definitely check it out.

## Husky

I already have a video on my channel about [Husky](https://github.com/typicode/husky), but I'll still mention it here.

If you need to run scripts locally before you commit or push your changes - this tool will cover you.

You can use it to run tests or lints before or after you commit push or pull changes to and from your repository.

Husky allows you to define git-hooks in a simple config file and share them across the team.

## Commitizen

Yesterday I've read a blog post where some dude said that he set up a simple script that simplifies making git commit for him, by automatically adding message "Update".

Honestly I think it's a very bad idea, and if you do this - eventually you'll have a hard time navigating though history to find some bug introduced awhile ago.

A better option is to use [Commitizen](http://commitizen.github.io/cz-cli/).

It's a command line tool that automatically formats commits for you using conventional commits convention.

### Conventional Commits

[This convention](https://www.conventionalcommits.org) describes commit message format. 

Simply the format is as follows: `type`, ` scope` that is optional, then `descripion` and then you can have more details in commit `body` and `footer`.

Besides making your commit history tidy and easy to read it also unlocks two neat features: semantic versioning and automatic changelog generation.

### Semantic Versioning

For those who don't know [semantic versioning ](https://semver.org) is a system of versioning your packages in a `MAJOR.MINOR.PATCH` form.

Where you bump `MAJOR` when you make incompatible API changes, `MINOR` - when you add backwards compatible features and `PATCH` - when you make backwards compatible bug-fixes.

The opposite of that is [sentimental versioning](http://sentimentalversioning.org/). Where you have whatever inconsistent rules you can come up with. And you don't even have stick to one schema with sentimental versioning you bumb your numbers however you feel like.

### Automatic changelog

Another neat feature of having you commits well organized and having descriptive messages - is that you'll now be able to generate your [changelog](https://keepachangelog.com/en/1.0.0/) automatically.

So you'll be able to track notable changes to your project at basically zero cost.

## CommitLint

If you don't want to have your commits automated, but still want to have them tidy and organized - use [CommitLint](https://commitlint.js.org/#/) instead.

CommitLint can be run manually or using git hooks, remember Husky. And it will check if your messages conform to chosen format.

## gitignore.io

And last tool I want to share is [gitignore.io](https://gitignore.io) that allows you to easily generate `.gitignore` fily for any type of project.

It will save you from forgetting to add sensitive files and folders to your project.

Also there is a collection of `.gitignore` files [on Github](https://github.com/github/gitignore). 

## Final

Thank you for reading this far. If you know any other great tools - drop me a message in my [Telegram](https://t.me/satansdeer)


5 Git Tools You Must Use Today


[Watch the video on YouTube](https://www.youtube.com/watch?v=qod6E738cc4)

Git provides an interface to run some code as reaction on specific triggers. Those triggers are called githooks (hooks used by git). You can run code on every commit, push, pull or other actions.

> Hooks are programs you can place in a hooks directory to trigger actions at certain points in git’s execution.

You can check out the whole list on [git documentation page](https://git-scm.com/docs/githooks).

It might be quite cumbersome to manage githooks and make them available for the whole team.

Luckily there is a tool called [Husky](https://github.com/typicode/husky) that provides nice interface to manage githooks.

It is an **npm** package so it's usually used with Javascript projects.

## Install Husky

To start using [Husky](https://github.com/typicode/husky) you need to install it as def dependency first:

```sh
npm install husky --save-dev
```

Then you need to add husky configuration section to `package.json`:

```json
// package.json
{
  "husky": {
    "hooks": {
      "pre-push": "npm test",
    }
  }
}
```

In this config specify that we want to run `npm test` before every `push` to remote repo.

Alternatively you can specify your settings in `.huskyrc`, `.huskyrc.json` or `.huskyrc.js` file

```json
// .huskyrc
{
  "hooks": {
    "pre-commit": "npm test"
  }
}
```

## Supported Hooks

Husky supports all Git hooks except server side hooks (`pre-receive`, `update` and `post-receive`).

* `applypatch-msg` - This hook is invoked by `git-am`. It takes a single parameter, the name of the file that holds the proposed commit log message. Exiting with a non-zero status causes git am to abort before applying the patch.

* `pre-applypatch` - This hook is invoked by `git-am`. It takes no parameter, and is invoked after the patch is applied, but before a commit is made.

* `post-applypatch` - This hook is invoked by `git-am`. It takes no parameter, and is invoked after the patch is applied and a commit is made.

* `pre-commit` - This hook is invoked by `git-commit`, and can be bypassed with the `--no-verify` option. It takes no parameters, and is invoked before obtaining the proposed commit log message and making a commit. 

* `prepare-commit-msg` - This hook is invoked by `git-commit` right after preparing the default log message, and before the editor is started.

* `commit-msg` - This hook is invoked by `git-commit` and `git-merge`, and can be bypassed with the `--no-verify` option. It takes a single parameter, the name of the file that holds the proposed commit log message. 

* `post-commit` - This hook is invoked by `git-commit`. It takes no parameters, and is invoked after a commit is made.

* `pre-rebase` - This hook is called by `git-rebase` and can be used to prevent a branch from getting rebased.

* `post-checkout` - This hook is invoked when a `git-checkout` is run after having updated the worktree.

* `post-merge` - This hook is invoked by git-merge, which happens when a git pull is done on a local repository. 

* `pre-push` - This hook is called by `git-push` and can be used to prevent a push from taking place.

* `pre-auto-gc` This hook is invoked by `git gc --auto`. 

    `git-gc` runs a number of housekeeping tasks within the current repository, such as compressing file revisions (to reduce disk space and increase performance), removing unreachable objects which may have been created from prior invocations of git add, packing refs, pruning reflog, rerere metadata or stale working trees.  

* `post-rewrite` - This hook is invoked by commands that rewrite commits (`git-commit` when called with `--amend` and `git-rebase`.

There are other less popular hooks, you can check them in [git documentation](https://git-scm.com/docs/githooks)

## Access Git params and stdin

Git hooks can access parameters via command-line arguments and stdin.

Husky makes them accessible via `HUSKY_GIT_PARAMS` and `HUSKY_GIT_STDIN` environment variables.

```json
{
  "husky": {
    "hooks": {
      "commit-msg": "echo $HUSKY_GIT_PARAMS"
    }
  }
}
```

## Using In Monorepos

If you have a multi-package repository, it's recommended to use tools like [lerna] and have husky installed **ONLY** in the root `package.json` to act as the source of truth.

## Running Multiple Commands

By design, husky will run hook scripts as a single command. Just like scripts defined in `package.json` are run.

```json
{
  "pre-commit": "cmd && cmd && cmd"
}
```

Automate Git With Hooks And Husky


Sometimes you have uncommited changes and you need to switch to another branch. Here is where `git stash` is very handy.

## Basic Usage

[Watch the video on YouTube](https://www.youtube.com/watch?v=7aVmVbpEdjc)

When switching between tasks you sometimes have uncommited work. In this case you can temporarily save changes in git without commiting them. Here's how it looks.

First make sure your changes are staged (use `git add`). Git stash can only be applied to **staged** changes.

```bash
$> git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        new file:   script.js
        new file:   stylesheet.css
        new file:   webpage.html
```

OK, here we have 3 new files that we don't want to commit yet, but we need to switch to another branch.

So we use `git stash` and after applying this command we see a message indicating that changes are stashed successfully.

```bash
Saved working directory and index state WIP on master: bccdab5 Initial commit
```

If you check the repo with `git status` now you'll see that there is no uncommited changes.

After switching to another branch and fixing the bug you can get back to your original branch and apply stashed changes using `git stash apply`.


Git Stash


You know that `git add` adds files to index. But did do you know that it can add **specific&nbsp;lines** of files? Or even add files, ignoring their contents? Let's check this out!

First let's get familiar with `git add --patch` command or it's shorthand `git add -p`. What does it do?

Let's imagine that you've been working on some task. During the process you've got carried away and introduced some changes not related to your current task.

Now it's time to commit the changes, but some of them are irrelevant. It would be wrong to put everything in that commit.

This is where `git add --patch` comes into play.

## See The Example

Imagine we had a file _poem.txt_ with two unfinished couplets:

```bash
Roses are red
Violets are blue

Roses are red
Violets are blue
```

After a full day of dedicated hard work we've completed both:

```diff
➜  git_add_patch (master) ✗ git diff

diff --git a/poem.txt b/poem.txt
index 39f13e6..f4b70ab 100644
--- a/poem.txt
+++ b/poem.txt
@@ -1,5 +1,9 @@
 Roses are red
 Violets are blue
+Sugar is sweet
+And so are you

 Roses are red
 Violets are blue
+Onions stink
+And so do you.
```

But now we are a bit concerned about the second couplet and want to commit only the first part.

```diff
➜  git_add_patch (master) ✗ git add -p

diff --git a/poem.txt b/poem.txt
index 39f13e6..f4b70ab 100644
--- a/poem.txt
+++ b/poem.txt
@@ -1,5 +1,9 @@
 Roses are red
 Violets are blue
+Sugar is sweet
+And so are you

 Roses are red
 Violets are blue
+Onions stink.
+And so do you.
Stage this hunk [y,n,q,a,d,/,s,e,?]?
```

See the last line, **Stage this hunk [y,n,q,a,d,/,s,e,?]**? Here it gives you some options where the most important are:

* **y** - stage this hunk
* **n** - do not stage this hunk
* **q** - quit; do not stage this hunk or any of the remaining ones
* **a** - stage this hunk and all later hunks in the file
* **d** - do not stage this hunk or any of the later hunks in the file
* **s** - split the current hunk into smaller hunks
* **e** - manually edit the current hunk

There are some more options, you can see them by choosing the **?** option.

Here we want only the first part about the sugar and sweetness, so we choose the option&nbsp;**s**.

```diff
Stage this hunk [y,n,q,a,d,/,s,e,?]? s
Split into 2 hunks.
@@ -1,5 +1,7 @@
 Roses are red
 Violets are blue
+Sugar is sweet
+And so are you

 Roses are red
 Violets are blue
Stage this hunk [y,n,q,a,d,/,j,J,g,e,?]? y
```

We chose to stage that hunk, and now it asks if we want to stage the second one:

```diff
Stage this hunk [y,n,q,a,d,/,j,J,g,e,?]? y
@@ -3,3 +5,5 @@

 Roses are red
 Violets are blue
+Onions stink
+And so do you.
Stage this hunk [y,n,q,a,d,/,K,g,e,?]? n
```

And we don't want to stage this one, so we choose **n**.

Great, let's see what we have now.

```bash
➜  git_add_patch (master) ✗ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	modified:   poem.txt

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   poem.txt
```

Cool beans, time to commit this thing.

```bash
➜  git_add_patch (master) ✗ git commit -m "Complete the first couplet"
```

Git splits hunks by the empty lines, but what if you really need to stage only **specific&nbsp;lines**.

## Behold The Power Of E

Imagine you have a `diff` like this:

```diff
➜  git_add_patch (master) ✗ git diff

diff --git a/poem.txt b/poem.txt
index 9737e9f..a2baecd 100644
--- a/poem.txt
+++ b/poem.txt
@@ -5,3 +5,6 @@ And so are you

 Roses are red
 Violets are blue
+Flowers smell good
+Onions stink
+And so do you.
```

And you are really concerned about that onion part, but you don't want to remove it. So you want to stage only the _"Flowers smell good"_ and _"And so do you"_ lines.

Now the **s** option won't help us, because those lines aren't separated by empty lines, and git considers them as one hunk.

**e** option to the rescue.

```bash
➜  git_add_patch (master) ✗ git add -p
diff --git a/poem.txt b/poem.txt
index 9737e9f..a2baecd 100644
--- a/poem.txt
+++ b/poem.txt
@@ -5,3 +5,6 @@ And so are you

 Roses are red
 Violets are blue
+Flowers smell good.
+Onions stink.
+And so do you.
Stage this hunk [y,n,q,a,d,/,e,?]? e
```

It will open the default text editor and you'll be able to manually edit that hunk.

![editor](/edit_hunk.png)

Just remove the part about onions and here you go:

```diff
➜  git_add_patch (master) ✗ git add --staged

diff --git a/poem.txt b/poem.txt
index 9737e9f..a2baecd 100644
--- a/poem.txt
+++ b/poem.txt
@@ -5,3 +5,6 @@ And so are you

 Roses are red
 Violets are blue
+Flowers smell good
+And so do you.
```

Nice, now you can decide what to do about those stinky onions later.

But what if you need to add some specific lines from the new file?

## Use The Intent To Add

Use `git add --intent-to-add` or `git add -N` to add specific file, but not its contents.

Imagine that we had our poem written from scratch.

Now `git diff` shows nothing, and if we'll use `git add -p` it will say `No changes.`

No problem, let's tell git that the file exists.

```bash
➜  git_add_patch (master) ✗ git add -N poem.txt
```

Now we can use `git add -p` and then edit the hunk to remove the lines about onions.

[Watch the video on YouTube](https://www.youtube.com/watch?v=b0t8XL6ZoeQ)




Add Specific Lines With Git Patch


Once I was working on a big feature. Everything was going fine until I got carried away and started to commit everything in one branch instead of splitting to multiple smaller ones. As a result I ended up with a huge PR that no one was able to review properly.

Let's see how can you avoid getting in that situation and what to do if you already did.

First of all – do some planning and break task in parts. This is the only way you'll be able to avoid creating this monstrosity of a pull request.

Then you'll have two options, with both of them you create small PR's with gradual improvements:

* Merging PR's to master early and often.
* Having a long running feature PR with small reviewable child PR's.

The difference is what you are basing them off. In first case you base them on `master` and in second you base them on a feature branch.

## Merging Early And Often

This is the **preferred option**. You better have a good plan of what you are going to do though. You don't want to end up creating meaningless pull requests with lonely components that don't interact with anything. Like models that no one uses.

Do it as incremental improvements. In your first PR set the base structure and then gradually improve it by adding more components and upgrading the old ones.

## Long Running Feature PR

You'll have to rebase the base branch with master and then rebase it's children as well.

This approach might require some cherry-picking between branches if you'll be working in parallel with someone else.

Don't forget to do the housekeeping and creating small PR's for every new feature or you are going to end up with…

## The Worst Case

It started as a long running feature PR approach. But then I kinda slacked off with the housekeeping and started to commit everything in one of the child PRs.

Eventually I ended up with a huge PR with 100+ commits and 1.5k lines of code.

This is a very bad situation. Even if someone would dare to review it, he'll be more likely to overlook something.

So if you found yourself in similar situation – you need to do something to this PR to make it reviewable. For example you can…

## Break It Into A Stack Of PRs

When searching for a solution I found [this blog-post](https://graysonkoonce.com/stacked-pull-requests-keeping-github-diffs-small/) of Grayson Koonce where a he proposed to close the original PR, copy it's changes to a new branch and then create a stack of dependent PRs with incremental changes one on top of another.

## First step

First you want to create a new branch based on `master` with all the changes from that huge PR unstaged.

```bash
$ git checkout master
$ git checkout -b stacked-pr-example-1 branch-of-that-huge-pr
$ git reset master
$ git status
```

Now you'll see all the changes that were introduced in that huge PR in uncommited state.
You can start commiting the changes and making stacked PRs.

## First Pull Request

You'll have to use `git add --patch` to add specific changes to a commit. I have a [post&nbsp;about&nbsp;this&nbsp;command](/posts/git-add-patch).

But if you have unstaged new files – git won't be able to add them this way. To fix it apply `git add -N` or `--intent-to-add` to a file you want to see in your commit. This will tell git to add file itself but not it contents. After that you will be able to add lines from that file easily.

At this point you might want to check how many changed lines you've already added. Use `git diff --staged --stat` for this.

Once you've staged all the needed changes, stash everything else and verify that it still works.

```bash
$ git stash --include-untracked --keep-index
```

`--keep-index` will make it stash only files that have not been added and `--include-untracked` will allow it to stash untracked files as well.

Time to commit the changes and create the PR.

```bash
$ git commit -m "Make some change to x"
$ git push -u origin stacked-pr-example-1
```

There is a nice CLI tool `hub` that will allow us to create a PRs easier:

```bash
$ hub pull-request
```

It will open the default editor and you'll be able to add PR description.

## Next Pull Requests

Now create the branch for your next PR and pop the stash back:

```bash
$ git checkout -b stacked-pr-example-2
$ git stash pop
```

Repeat the `add`, `stash`, `commit` steps.

Now create new PR, but make sure to base it off of the previous branch with the -b flag:

```bash
hub pull-request -b stacked-pr-example-1
```

Repeat the process until the changes are packed into PRs.

## After You've Got Your PRs Reviewed

Here Grayson gives an important tip to propagate additional commits via `git merge` instead of `git rebase`.
This way you'll be able to resolve conflicts in multiple commits in one go.

```bash
$ git checkout stacked-pr-example-2
$ git commit -am "Addressed this feedback"
$ git commit -am "Addressed that feedback"
$ git push stacked-pr-example-2

$ git checkout stacked-pr-example-3
$ git merge stacked-pr-example-2 # integrate changes from stacked-pr-example-2
```

Now, after you've applied all feedback and got you PRs approved – time to land the stack.

As Github [supports updating the base branch](https://github.com/blog/2224-change-the-base-branch-of-a-pull-request) since August 2016, you can merge your stack in any order.

[Watch the video on YouTube](https://www.youtube.com/watch?v=Lqczzlh7420)


Git

5 Git Tools You Must Use Today

Automate Git With Hooks And Husky

Git Stash

Add Specific Lines With Git Patch

Getting Schwifty With Pull Requests