Archive for the ‘git’ Category

Commit only part of a file in Git

April 21, 2020 Leave a comment

You can use git add –patch (or -p for short), and git will begin to break down your file into what it thinks are sensible “hunks” (portions of the file). It will then prompt you with this question:

Stage this hunk [y,n,q,a,d,/,j,J,g,s,e,?]?

Here is a description of each option:

y – stage this hunk for the next commit
n – do not stage this hunk for the next commit
q – quit; do not stage this hunk or any of the remaining hunks
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
g – select a hunk to go to
/ – search for a hunk matching the given regex
j – leave this hunk undecided, see next undecided hunk
J – leave this hunk undecided, see next hunk
k – leave this hunk undecided, see previous undecided hunk
K – leave this hunk undecided, see previous hunk
s – split the current hunk into smaller hunks
e – manually edit the current hunk
? – print hunk help

If the file is not in the repository yet, you can first do git add -N . Afterwards you can go on with git add -p .

Afterwards, you can use:

git diff –staged to check that you staged the correct changes
git reset -p to unstage mistakenly added hunks
git commit -v to view your commit while you edit the commit message.

Note this is far different than the git format-patch command, whose purpose is to parse commit data into a .patch files.

Reference for future: Git Tools – Interactive Staging


Categories: git

Mastering Markdown

February 27, 2019 Leave a comment

What is Markdown?

Markdown is a way to style text on the web. You control the display of the document; formatting words as bold or italic, adding images, and creating lists are just a few of the things we can do with Markdown. Mostly, Markdown is just regular text with a few non-alphabetic characters thrown in, like # or *.

Categories: git

Naming Branches

February 26, 2019 Leave a comment

I was wondering if there is a convention for naming git branches. Though this really depends on what your organization has, what do you follow when there are no standards?

After a quick google I opted to go for:

* feat-short-name
* test-short-name
* fix-short-name
* bug-short-name
* chore-short-name

When naming branches. Then still have

* develop for most of the work and
* master for releases.


Categories: git Tags: ,

How to use `git mergetool` to resolve conflicts

February 18, 2019 Leave a comment

Have the following in .gitconfig

    tool = vimdiff  
Categories: git Tags: ,

How can I change the author name / email of a commit?

December 3, 2018 Leave a comment

I needed to change the email address for multiple commits.

Followed the steps under this section in the source.

Using Interactive Rebase

Interactive Rebase is the Swiss Army Knife of tools in Git: it allows you to do and change almost anything. However, being as powerful as it is, this also means you can very easily shoot yourself in the foot. Use it with care (and possibly read up on it)!


Categories: git, Interesting Tags:

pre-commit: A framework for managing and maintaining multi-language pre-commit hooks.

October 16, 2018 Leave a comment


Git hook scripts are useful for identifying simple issues before submission to code review. We run our hooks on every commit to automatically point out issues in code such as missing semicolons, trailing whitespace, and debug statements. By pointing these issues out before code review, this allows a code reviewer to focus on the architecture of a change while not wasting time with trivial style nitpicks.

As we created more libraries and projects we recognized that sharing our pre-commit hooks across projects is painful. We copied and pasted unwieldy bash scripts from project to project and had to manually change the hooks to work for different project structures.

We believe that you should always use the best industry standard linters. Some of the best linters are written in languages that you do not use in your project or have installed on your machine. For example scss-lint is a linter for SCSS written in Ruby. If you’re writing a project in node you should be able to use scss-lint as a pre-commit hook without adding a Gemfile to your project or understanding how to get scss-lint installed.

We built pre-commit to solve our hook issues. It is a multi-language package manager for pre-commit hooks. You specify a list of hooks you want and pre-commit manages the installation and execution of any hook written in any language before every commit. pre-commit is specifically designed to not require root access. If one of your developers doesn’t have node installed but modifies a JavaScript file, pre-commit automatically handles downloading and building node to run eslint without root.

Categories: git, Interesting


September 28, 2018 Leave a comment

Git hooks are scripts that Git executes before or after events such as: commit, push, and receive. Git hooks are a built-in feature – no need to download anything. Git hooks are run locally.

These hook scripts are only limited by a developer’s imagination. Some example hook scripts include:

* pre-commit: Check the commit message for spelling errors.
* pre-receive: Enforce project coding standards.
* post-commit: Email/SMS team members of a new commit.
* post-receive: Push the code to production.

Categories: git, Interesting

Tips for using a git pre-commit hook

September 26, 2018 Leave a comment
Categories: git, Interesting

How to Write a Git Commit Message

September 4, 2018 Leave a comment

The seven rules of a great Git commit message

  1. Separate subject from body with a blank line
  2. Limit the subject line to 50 characters
  3. Capitalize the subject line
  4. Do not end the subject line with a period
  5. Use the imperative mood in the subject line
  6. Wrap the body at 72 characters
  7. Use the body to explain what and why vs. how

Categories: git, Interesting

Multiple git user profiles

August 28, 2018 Leave a comment

How to have two git user profiles on one machine?

From stackoverflow.

Global config ~/.gitconfig

name = John Doe
email = john@doe.tld

[includeIf “gitdir:~/work/”]
path = ~/work/.gitconfig

Work specific config ~/work/.gitconfig

email = john.doe@company.tld
name = Nickname # If you do not want to use John Doe


Categories: git