I recently advised some co-workers, who just started working with R and git, to learn a bit of git and to not rely exclusively on the RStudio git capabilities, since they are in the moment somewhat limited, compared to the full power of git that you can get if you run git commands in the terminal.

Inspired by hackernoon, I had a look at the first 10 commands that I use most:

> history | awk '{print $4 " " $5}' | grep '^git'  | sort | uniq -c | sort -nr | head -10

128 gits
 43 git add
 39 git rm
 31 git log
 31 git commit
 21 git checkout
 17 git grep
  9 git pub
  6 git sync
  5 git fetch

Before going into details, here is a list of my git related aliases (you can include them in your .bashrc):

> alias | grep git

alias git_synch_refs='git fetch --prune --tags'
alias gitg='git log --graph --abbrev-commit --decorate 
   --format=format:"%C(bold blue)%h%C(reset) %C(auto)%d%C(reset) 
   %C(white)%s%C(reset) %C(dim white)- %an%C(reset)'
alias gith='git log  --pretty="%d//%h//%s//(%aE)"  --tags  | cat'
alias gitl='git log --pretty=format:"%Cred %h %Cgreen %d %Creset %s %Cgreen %an"'
alias gits='echo -en "\e[92m" ; git branch -l | grep \*; 
  echo -en "\e[93m" || true;  
  git describe --tag || true; echo -e "\e[39m";
  git status || true; echo -e ""'
alias gitt='git describe --tag'

And here 2 aliases I use most from my ~/.gitconfig:

      pub = "!git push -u origin $(git rev-parse --abbrev-ref HEAD)"
      # https://hackernoon.com/git-going-with-aliases-a9706e23fa9c
      sync = !git fetch --all --prune && git rebase -p --autostash $1

I usually work on a feature branch. The branch creation does not appear in the commands above,  as I created the branch some time ago, and I only update it. As a beginner, I would recommend to checkout a branch for tracking and work there:

> git checkout --track <origin/some branch>

Hint: if you just want to switch between branches, you can use:

> git checkout - # that's a 'minus' sign

See more details here: git-checkout-minus.

As the statistics above shows, most often I look at the git status (gits). This tells what the current status of the git repository is (what files were changed/added/deleted etc).

Once I'm happy with the changes, I just stage the files:

> git add -u  # stage the updated files
> git add --all # stage all the files (not only the already indexed files, but also new files)

Sometimes I delete files using:

> git rm <file name>

You can of course use:

> rm <file name>

but then you have to

> git add <removed file>

You can do it all in one step if you stick to git rm.

I often look at the previous commits with

> git log

There are many options for this command, here a few examples:

When I'm ready to commit, I just proceed:

> git commit --amend -C HEAD

This way I amend (change) the top commit. I keep the original commit message, but this changes the SHA-1 hash of the commit. This could be a problem if your branch is already pushed and others already fetched your branch. So use this command with care.

When I search for a pattern, I also prefer to use git directly, instead of RStudio's find,  since with git I can get many more information at once, e.g.:

> git grep -n -C5 <pattern>
# -n: show line number
# -C5: show 5 lines before and 5 lines after the matching line

There are 2 most important aliases for me, which save me a lot of typing. The first one:

> git sync

This synchronizes my branch with my remote, i.e. it fetches the remote changes and rebases my branch on top of the remote, all in one go. It might be that there
are merge conflicts that I need to fix, but since I call this often enough,  the conflicts are quite rare. The credits for this very handy command go again to hackernoon.

The second one:

> git pub

This pushes my feature branch. Sometimes, if I amended a commit which was already pushed, I need to force push (again, use it with care):

> git pub -f

Another useful git feature that I use is interactive rebasing, for details see for example git-interactive-rebase-squash-amend-rewriting-history. While it might look scary in the beginning, once you do it a few times, it becomes very easy, and makes reviewing a breeze, since there is only one commit to look at.

If you are a beginner with git, you might want to have a look at https://learngitbranching.js.org/.



Final words:

> git help <command>

My advice: give it a try, since establishing a minimal workflow is, as I hopefully showed, relatively easy. If you still don't like it, no harm done, you'll then have arguments to sustain your opinion. After all, you need to first know the rules, in order to break them.


xkcd how it works


Make a promise. Show up. Do the work. Repeat.