Git cheat sheet for day-to-day work
By: Abhishek Saurabh
Tags: Software Development, Git, Cicd

This is the first in the series of articles I plan to write on CI/ CD. It covers a few Git commands that a developer usually needs in her day-to-day work. In addition, I have also included a few best practices.

Please note that in the explanations in the sections on scenarios, I have assumed that the Git workflow being used has a master of which the developers branch off while they are working on a new feature. The commands won’t change regardless of the Git workflow you are working with.

By no means, the command cheat sheet or the scenarios covered should be construed as an exhaustive list. I plan to extend it as-and-when time permits. That said, if you spot any mistake or if there is anything which you feel ought to be a part of such an article before it is worthy of being called a Git cheat sheet, please leave your comments.

Installing and configuring Git

Installation

To install git first time on your machine: sudo apt-get install git

To check where git is installed: which git

To get the version: git --version

Git configurations

git config helps us configure Git installation from the command line on a global or local project level. These configuration levels correspond to .gitconfig text files.

Git stores configuration options in three separate files which lets us define scope at local, user or system level. These configurations can be set up by using the flags --local , --global and system respectively. The order of priority for configuration levels mimics the aforesaid order meaning when looking for a configuration value, Git will start at the local level and bubble up to the system level.

--local : These configurations are applied to the repository in which git config is invoked. By default, git config will write to a local level if no configuration option is passed. Local configuration values are stored in a file that can be found in the repo's .git directory: .git/config .

: These configurations are applied to the repository in which is invoked. By default, will write to a local level if no configuration option is passed. Local configuration values are stored in a file that can be found in the repo's directory: . --global : These configurations are user specific meaning they are applied to an operating system user. On unix systems, these configurations can be found in a user's home directory: ~ /.gitconfig

: These configurations are user specific meaning they are applied to an operating system user. On unix systems, these configurations can be found in a user's home directory: --system : These are applied system-wide meaning applicable to all users and all repos. The system level configuration file lives in a gitconfig file off the system root path. $(prefix)/etc/gitconfig on unix systems.

Configurations are defined as dot delimited strings composed of a ‘section’ and a ‘key’ based on their hierarchy. For example, in git config user.email , email is a child property of the user configuration block. Here is an example of a config file.

User name: Name will be used for all commits by the current user.

git config --global user.name <name> # Typically we'll use the global option for user name

User email: Email will be used for all commits by the current user for the current local repository.

git config --local user.email <email> # Local option for user email makes sense at the repository level.

Editor

Define the text editor used by commands like git commit for all users on the current machine. The <editor> argument should be the command that launches the desired editor (e.g., vi or nano). This example introduces the --system option. The --system option will set the configuration for the entire system, meaning all users and repos on a machine.

git config --system core.editor <editor>

Open the global configuration file in a text editor for manual editing.

git config --global --edit

To view git configurations: git config --list

Commands for managing branches

Show current branch: git branch List all branches, both local and remote: git branch -a Create branch: git branch <name_of_your_new_branch> Switch to the new branch: git checkout <name_of_your_new_branch> Step 3 and 4 can be combined into one: git checkout -b <name_of_your_new_branch> Rename branch: git branch -m <branch_name_existing> <branch_name_new>

Deleting a branch

It is common for the developers to work on feature branches. Once the work on a feature is done, it’s recommended to delete the feature branch to de-clutter the repository.

To delete the branch locally, make sure that you that the branch to be deleted is not checked out. For example, run git checkout master . Delete the branch with git branch -d <name-of-the-branch-to-be-deleted> . -d tells git to delete this branch only if it has been pushed and merged with the remote branch. Use -D when you want to forcefully delete the branch locally regardless of whether the changes have been pushed and merged.

To delete the branch remotely, run git push <remote> --delete <name-of-the-branch-to-be-deleted> .

Sync the branch list on local: git fetch -p . The -p flag stands for prune. After fetching, branches which no longer exist on the remote will be deleted.

Common scenarios

Scenario 1: Pull the latest update from a specific branch in the remote

Assume that you are on the master branch on your local machine. You want to update the feature branch on your local machine, say feature-branch-to-be-updated with the same branch in the remote.

git pull is our friend in such cases. Before running this command, make sure that the branch in question is checked out. Then to perform pull, simply specify which remote branch do you want to integrate with (say remote-branch-to-be-integrated )¹.

git checkout feature-branch-to-be-updated

git pull origin remote-branch-to-be-integrated

In most cases, however, your local branch will already have a proper tracking connection with a remote branch set up. This configuration provides default values so that the pull command already knows where to pull from without any additional options. Therefore, git pull alone would suffice.

Scenario 2: Push changes from the local feature branch to a remote feature branch

Assume that you are working on a local branch new-feature-branch . You have a branch with the same name in the remote. Work on the feature is done and now you want to push the changes from the local new-feature-branch to the remote new-feature-branch . Following commands can be used in such a scenario.

git checkout new-feature-branch

git add .

git commit -m "Commit message"

git push origin new-feature-branch

Scenario 3: Merge branches

Assume that you are done working on a feature branch my-feature-branch and you want to raise a pull request (PR). However, before you raise a PR, you want to integrate your changes into the remote master (say, the target branch). You will come across conflicts which ought to be resolved before a PR is raised.

Before merging, we have to make sure that the my-feature-branch and the master are up to date with the latest changes in the remote server. Run git pull to update my-feature-branch . For the sake of brevity, we will assume that there is no conflict at this stage meaning no one else changed anything on this feature branch in the remote.

Because we want to merge our changes into the master (i.e. the target branch), the HEAD should be pointing towards the master. Then we can go ahead with the merge.

git checkout master

git pull

git merge my-feature-branch

Best practices

Git commit messages

git commit -m : Use it only for small and clear fixes like git commit -m "Fix typo in README.md" .

: Use it only for small and clear fixes like . Commit messages using an editor

Configure an editor to write commit messages. nano or vim is recommended so that you don't have to leave the terminal in the process of code commit. Check the section Git configurations to configure your preferred editor. After editor is set up, git commit in the terminal will open the configured terminal. In the opened editor, the first line is the subject line (short description). Leave a blank line after it. Write the extended description (body).

<Summarize change(s) in around 50 characters or less. No full stop as characters are precious.>



<More detailed explanatory description of the change wrapped into about 72 characters>

4. Example of a good commit message. This is taken from this page which is an exhaustive write up on writing good commit messages.

Capitalized, short (50 chars or less) summary



More detailed explanatory text, if necessary. Wrap it to about 72

characters or so. In some contexts, the first line is treated as the

subject of an email and the rest of the text as the body. The blank

line separating the summary from the body is critical (unless you omit

the body entirely); tools like rebase can get confused if you run the

two together.



Write your commit message in the imperative: "Fix bug" and not "Fixed bug"

or "Fixes bug." This convention matches up with commit messages generated

by commands like git merge and git revert.



Further paragraphs come after blank lines.



- Bullet points are okay, too



- Typically a hyphen or asterisk is used for the bullet, followed by a

single space, with blank lines in between, but conventions vary here



If you use an issue tracker, add a reference(s) to them at the bottom,

like so:



Resolves: #123

See also: #456, #789

References