Git is difficult. On top of that, for many new developers, it’s the first tool with a command line interface (CLI) that they use. It can be a bit too much if you’re learning all the following at the same time: how to use CLI how to use Git and last but not least: programming In this article, I’ll show you a few tricks to make your Git experience less painful and more fun! Check your state Git is generous enough to offer many commands to check the state of your repository, yet prudent enough not to overwhelm the beginner with verbosity. In short—you should ask Git to give you the details you need. You have following command for it: git status A key command to get a glimpse of where you are in Git. Example outputs: $ git status
On branch main
Your branch is up to date with 'origin/main'.

nothing to commit, working tree clean for when you are on clean branch and up to date $ git status
HEAD detached at abc01e7
nothing to commit, working tree clean for when you are in . detached HEAD state $ git status
On branch main
Your branch is up to date with 'origin/main'.

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        lorem-ipsum.txt

nothing added to commit but untracked files present (use "git add" to track) When you have some new files in your working copy. git show This is a command that allows you to see changes that happened in a commit. When run without an argument, it shows you the current commit: $ git show
commit abc01e761cb9cc14c4d5aecae2488810c834c0f9 (HEAD -> main, origin/main, origin/HEAD)
Author: Marcin Wosinek <marcin.wosinek@gmail.com>
Date:   Wed Nov 2 11:57:33 2022 +0100

    Add lorem ipsum to readme

diff --git a/README.md b/README.md
index 8ae0569..9dca8b4 100644
--- a/README.md
+++ b/README.md
@@ -1 +1,2 @@
 # Test
+Lorem ipsum You get all the details about the commit: its author, time, message and diff of each file that was changed. You can specify any commit you want to see: $ git show edd3504
commit edd3504f6edc722482fa4383443fa1729acc9a87
…rest of the output… Note! This command works on . Thus, if you use branch name, it will show the most recent commit from that branch: commits $ git show main
commit abc01e761cb9cc14c4d5aecae2488810c834c0f9 (HEAD -> main, origin/main, origin/HEAD)
Author: Marcin Wosinek <marcin.wosinek@gmail.com> —a custom alias I recommend to everybody git tree I recommend defining a tree alias to see the graph of all the branches—you can learn more about it in this . With it in place, you can run: article $ git tree
* 11f7f3c (test) add test.txt file
| * 2dbd30f (origin/test) add test.txt file
| * e7be203 (test-2) add new file
|/
* abc01e7 (HEAD -> main, origin/main, origin/HEAD) Add lorem ipsum to readme
* edd3504 Add readme And get a nice overview of the entire repository. Check what your default editor is In some cases, Git wants you to provide input to it by editing a temporary file it created. This workflow can be confusing at first, and even more so if you don’t know your default editor. Here’s how to check it by listing Git’s logical variables and filtering them to the one that contains . On my MacOS, it’s : EDITOR vi $ git var -l | grep EDITOR
GIT_EDITOR=vi Similarly, on Ubuntu: $ git var -l | grep EDITOR
GIT_EDITOR=editor On Ubuntu, is a command that starts what is configured as your default text editor. One machine I have access to, it’s : editor nano $ update-alternatives --display editor
editor - auto mode
  link best version is /bin/nano
  link currently points to /bin/nano
… No matter your editor, make sure you know how to do the following things: edit the file—which can be challenging for beginners in , due to the various modes of its interface Vim save the changes exit the editor Or, change the editor to something you know how to use. Use tab while typing commands Git commands, all the attributes, and branch names are long; and the interface accepts no mistakes. The key productivity trick is not to type them whole. In most shells, when you press tab key, the shell either: shows you all available command auto completes picks command if there is only one available So, for example, with the shell I use, let’s see these options after typing : zsh git co<tab> $ git co
Completing main porcelain command
commit        -- record changes to repository
Completing ancillary manipulator command
config        -- get and set repository or global options
Completing ancillary interrogator command
count-objects -- count unpacked objects and display their disk consumption
Completing plumbing manipulator command
commit-graph  -- write and verify Git commit-graph files
commit-tree   -- create new commit object
Completing plumbing internal helper command
column        -- display data in columns And just complete the word when I type : git com<tab> $ git commit Similarly, it provides autocomplete for parameters, branch names, etc. It makes a big difference while typing. Use arrows Watching someone retype the whole command they used a few moments ago is a painful experience. Most shells allow you to reuse the last command by just using arrow keys. Arrow up brings the most recent command, you type it again to get the previous one, and so on. After finding the one you need, you can edit it to match the operation you’re performing right now. Get remote changes all the time I sync my local repository with remote all the time—even in my private repos, where I know, I’m working alone. It’s too easy to mess up stuff by not paying attention to what others are changing. And it takes only one command to make sure everything is up to date: $ git fetch After running it, you know that every reference you see locally is in the same place as it is on remote. origin/<branch-name> Start your new branches from the updated main Conflicts are sometimes painful to fix, but nothing hurts more than conflicts that could have been easily avoided. One of the common scenarios when people introduce an unnecessary conflict, is when they start a new branch behind the most recent commit. This can be easily avoided by: doing fetch all the time paying attention to where in the history tree you are Short-lived branches Having branches that are merged quickly has a few benefits: New features are integrated sooner into the codebase. If they are not completely ready, they can always be hidden by a feature flag. Fewer changes in both the main and another branch mean there is less risk of conflicts. Smaller branches mean less code to review. Short-lived branches are a way to progress via small interactions—something I recommend in . another article Things to avoid I often see beginners coming with problems I mostly don’t have to deal with because I avoid the following things in Git: git pull In Git, pull combines two operations into one: , and git fetch or Depending on your configuration git merge git rebase I always want to double-check my remote state doing either merge or rebase. So my typical flow would be: before —to get updates from remote, git fetch —the alias I mentioned above, to make sure the repo is in the state I expect it to be, git tree —when there are changes remote and locally, or git rebase origin/<branch-name> `git merge origin/—when there are changes on remote but not locally. That is, it can be done as a fast-forward merge. Git submodules Finally, submodules are a way of embedding a Git repository or repositories inside another. The internal repository maintains its separate history, whereas the containing one keeps only the reference to the origin and the current commit that the internal repo should be at. My main issue with Git submodules is that they complicate an already difficult problem—version control—and add more layers of complexity. Git submodules provide an alternative solution for the problem that is better addressed with: using some package manager (like npm) for external dependencies merging multiple repositories into one for internal dependencies What’s next Git has many confusing aspects, but it gets way simpler once you understand it. If you are interested in learning more about Git, sign up to get updates about my Git-focused content. here Originally published here.

The Graph

Fetch

Keep

2022 - HackerNoon Contributor of the Year - Beginners Guide

2022 - HackerNoon Contributor of the Year - Code Quality

2022 - HackerNoon Contributor of the Year - Learning

2022 - the Greatest Storyteller

Newsletter

Senior JS developer

Too Long; Didn't Read

A Guide to Staying Sane While Working with Git  

A Guide to Staying Sane While Working with Git

Too Long; Didn't Read

People Mentioned

Companies Mentioned

Coin Mentioned

@marcinwosinek

RELATED STORIES