
99% of the Git commands you'll need at work, demonstrated in a single script - carodgers
https://bitbucket.org/BitPusher16/dotfiles/raw/49a01d929dcaebcca68bbb1859b4ac1aea93b073/refs/git/git_examples.sh
======
trevor-e
Maybe my workflow is a lot easier than others, but I work on a team of 10+
engineers and my Git usage is dead simple. I do everything from a GUI (Fork
for macOS) and very rarely have to deal with any complicated issues that
require a terminal.

\- Always pull w/ rebase for the current branch.

\- Always merge other branches into your current branch, eg master -> feature.

\- Always stage individual chunks of code one at a time to make sure I'm
committing the right stuff.

\- Always squash feature branches into a single commit when merging back.

\- Stash changes if needed when switching branches.

\- Cherry-pick one-off commits if needed.

\- Append a previous commit that I haven't pushed yet if I happened to forget
something.

\- For complicated merge conflicts I switch to Visual Studio Code which also
has a great GUI.

I think this covers 99% of the stuff I encounter in my day-to-day.

~~~
mav3rick
I will never understand why people use a UI for git. 99% of the time people
who do that don't understand how git works. When something deviates from the
normal workflow they struggle.

~~~
SQueeeeeL
Never understand? I mostly use Git CLI, and it's a big pain. Weird
terminology, needing to memorize branch names for easy use, differences
between staged and pushed commits. And when you mess your incantation you
ripped from SO up you get errors with strange terminology. I understand it's
benefits and use it, but older simpler versioning systems like SVN had their
own benefits.

~~~
pizza234
While there are definitely UX problems, the following aren't:

\- needing to memorize branch names for easy use: there is tab completion for
this;

\- differences between staged and pushed commits: I'm not sure what you refer
here. the closest concept to the "stage" term is "staged changes". this is by
design; the idea is that while one applies changes within a single commit,
some are definitive, some are evolving; for this workflow, it's very
convenient. if one doesn't want, they can just add all and commit
(preferrably, with a single alias ;-)).

The "most extensive" Git UX problem is possibly the excess of functionality
given to the `checkout` command, which in fact is being split.

(I don't imply that Git UX is good, though)

------
Munksgaard
I know this has been mentioned a million times on here, but for the off chance
that someone hasn't heard about it before I'm going to completely disregard
that and say that Magit for Emacs is an incredibly helpful tool for
interfacing with git repositories that I couldn't imagine working without it.
It's by far the best interface to a version control system that I've ever
used. It has helped me understand how git works behind the scenes, and allows
me to effortlessly work with branching, stashes, merging, rebasing, remotes
and much more, without remembering a bunch of arcane git commands.

~~~
hwj
Magit sounds great. If I only could use it without remembering a bunch of
arcane emacs commands.

~~~
phalangion
Spacemacs makes emacs commands both less arcane and more discoverable. Give it
a shot.

~~~
giancarlostoro
Spacemacs is my favorite way to use Emacs, I leave the Emacs keybindings for
it, but you can still use some of the ergonomic shortcuts from it. I have
never used Magit however, I just prefer using a GUI: Sourcetree on Windows /
Mac is A+, Gitkraken is fine, but idk if I can justify $60 a year, and
SublimeMerge doesn't "feel" ready for me just yet, but if it ever does I may
consider it. The main way I do things overall is IntelliJ and Co's built-in
git utilities. If something gets complex I switch out and into GitKraken or
Sourcetree.

------
panpanna
I feel the list of useful for commands should be much shorter:

    
    
        git add/rm/commit/status/push
        git branch/checkout/merge/rebase
        git tag/push --tag
    

Anything else should be handled by _policies_. If you get bad PR, reject it
instead of trying to fix it using some complex sequence of git commands.

~~~
simiones
You need to add `git stash` to move to a different branch while having changes
wide open.

You also need `git log` with all sorts of arcane options if you actually want
to use the history.

~~~
dahart
Git log is probably the single git command I use most often.

Stash can be useful, but it’s good to know that you can get by without it very
easily, there’s nothing you can do with stash that you can’t do with commits &
branches, and stash doesn’t have the same safety mechanisms that commits have.
I think the biggest git accidents I’ve seen, where people have gotten confused
in the middle of a merge and lost their work, are due to using stash.

~~~
panpanna
I prefer using "tig" for browsing the commit log. "git log" is just not usable
in real world.

Stash is something I try to avoid after multiple accidents.

~~~
dahart
Full disclosure, I have a wrapper script to make git log output a lot more
readable for me, it columnizes and shortens and colors the output. I’d agree
the defaults are not amazing, and even with log’s many arcane options it’s
very difficult to make it feel smooth.

~~~
liquidify
love to see that.

~~~
dahart
Sure, customize to suit. YMMV.
[https://gist.github.com/dahart/5e70702242ac23bc78b30d5a4c073...](https://gist.github.com/dahart/5e70702242ac23bc78b30d5a4c073d12)

------
carodgers
I got a little tired of running to Google every time I needed a non-trivial
git command, so I set out to identify all (and only) the git commands I
require for my day-to-day and capture them in one place. The result is this
script. It can be run fully on your local machine, no remote accounts
required. (But it still shows how to use remote repos!)

I'd also be interested to hear what git commands others use frequently (that
don't involve a GUI). I'm curious to know which workloads might require some
of git's more advanced features on a regular basis.

~~~
katet
A couple of random addendums (although these aren't necessarily what you'd use
day to day)

git diff --color-moved

(seriously, read through the man page for git diff sometime)

git log -p --all -- <path/to/file>

(I use this with multiple remotes, so I can track changes in my fork and in
upstream when looking for context around a file)

git cherry-pick -x

(for automatically adding a reference to the original commit)

A couple more, but I think they're really quite specific to my personal
workflow and responsibilities

~~~
Myrmornis
(shameless plug):
[https://github.com/dandavison/delta](https://github.com/dandavison/delta) is
a syntax-highlighting pager for git that adds syntax highlighting and within-
line edit detection to all diffs displayed by git.

I agree about `git log -p`. A good trick with that is to use it as a quick way
to search for a commit that includes a certain string (since the pager is
less, one can search back in time with `/`).

Same trick for `git reflog -p`.

`git stash show -p` is another less-known diff command (look at a stash
without applying it).

------
RealityVoid
I just found out today about git worktree[1], and I think it's a very powerful
feature more people should know about, but it seems used less than it could.

Basically, you can do a working copy of the git environment without pulling
the repo again, so you have only one .git folder.

A godsend if you, like me, work on gigantic repos that build unbearably slowly
and want to be able to use multiple instances of the same repo at the same
time.

[1] [https://git-scm.com/docs/git-worktree](https://git-scm.com/docs/git-
worktree)

~~~
jomar
Compared to the previous technique of creating a new separate local clone for
unrelated simultaneous work on a project, it's also glorious when it comes
time to clean up and delete no-longer-needed extra working directories.

After `make clean` and `git status --ignored` shows nothing worth preserving,
you can delete the worktree (via `git worktree remove`) with impunity. No more
paranoid checking that there is no valuable work stashed or hiding in other
branches before typing `rm -rf`, as those are shared with the main worktree so
won't be lost.

------
aequitas
Try Gitless[0]. It's an alternative 'UI' to Git which is kind of build top
down instead of bottom up. The commands are much higher in the abstraction
tree and clear single operations and dropping some concepts like the staging
area. It operates on the Git database the same way 'normal' Git does so you
can always fall back.

[0] [https://gitless.com/](https://gitless.com/)

~~~
sidpatil
> It's an alternative 'UI' to Git

Also known as a _porcelain_ , as opposed to the low-level commands known as
the _plumbing_.

~~~
etbebl
My understanding is that in git-land, "porcelain" and "plumbing" usually refer
to a specific dichotomy of high-level vs. low-level git commands, rather than
further abstractions over the commands such as a GUI.

------
vfc1
Thanks for sharing, but I feel like it's more like 99.999%. The essential
commands for development are really a lot less than this. Maybe it's a list
for release managers / sys admins?

Committing, pushing, handling local branches, updating, merging, rebasing,
cherry-picking, squashing and stashing is almost all that everyone uses, and
several of those not even on a daily basis.

------
lbenes
When I want to get back to a pristine state, I prefer

$ git reset --hard origin/master

over the suggested

$ git reset --hard HEAD

If you use git and don't know the difference, read this:
[https://stackoverflow.com/questions/8196544/what-are-the-
git...](https://stackoverflow.com/questions/8196544/what-are-the-git-concepts-
of-head-master-origin)

------
niark
After years of wanderings, I've settled with Fork which is a a delightful GUI.
Polished, feature-rich, and still improving on a regular basis. Kudos to the
authors!

[0] [https://git-fork.com/](https://git-fork.com/)

~~~
liquidify
hmm why no linux?

~~~
johncoltrane
He is a MacOS developer (Swift, Cocoa), she is a Windows developer (.NET,
WPF).

------
HocusLocus
Ran this script, it uploaded my whole network to Github as an open source
project and sent a broadcast notification to Krebs On Security.

~~~
hnhg
Is that what you wanted?

------
pastrami_panda
'git add -i' is my new favorite. When you want to stage certain files but
don't want to type out the paths over and over again to deeply nested files

------
wyclif
One tip I give people who feel overwhelmed by Git is that unless you are an
edge case, you can probably do most of what you need to get done with these
six commands:

branch checkout add commit pull push

Reading and understanding the documentation for those six core commands isn't
a big investment, and it will pay off if you're doing software or
documentation development.

------
JamesQuigley
I'm personally a huge fan of
[https://www.gitkraken.com/](https://www.gitkraken.com/) (I also used to work
there.) Don't have to memorize git cli commands and get beautiful visuals on
top of that.

~~~
mroche
It’s been a long span of time since I’ve used GitKraken or Atlassian
Sourcetree, but GK had some serious performance issues with larger repos in my
experience. Very clean app, though, and I did enjoy it.

Right now, Im partial to Sublime Merge[0] as it’s fast, has a clean UI for
diffing, shares many similarities with Sublime, and also shows the use what
git commands they’re running by hovering. It can be a very effective tool for
learning git. It has the same evaluation structure as Sublime, so that’s a
bonus as well.

[0] [https://www.sublimemerge.com/](https://www.sublimemerge.com/)

~~~
JamesQuigley
Yeah there definitely used to be some perf issues. There have been some
massive improvements recently though for big repos. You should give it a try
again!

------
thrower123
This kind of thing is why I'm very glad that the Team Explorer git plugin in
Visual Studio has become decent enough that I don't have to drop into the cmd
line, pretty much ever.

------
ShteiLoups
I used to live and die by the command line.

Then I met sublime-merge. And fell in love. It is the only Gui I find more
efficient and beautiful than my terminal. I highly reccomend it.

------
KuhlMensch
I'd say I literally use pickaxe (-S) and the -G one a few times a week. Often
to answer questions I hear around the office. If you are not familiar with it,
I think its an amazing. Err... I guess...check it:

[http://www.philandstuff.com/2014/02/09/git-
pickaxe.html](http://www.philandstuff.com/2014/02/09/git-pickaxe.html)

Also I do allot of

git reset --soft HEAD;

(pick-hunks-with-GUI);

git stash -u -k;

run-test.sh;

git commit -m "blah"`

------
anreekoh
If you want git on the command-line, but don’t want to remember commands, try
lazygit[0], it’s changed what I’m comfortable doing with git because it can
tell me at any given moment what I can do.

[0]:
[https://github.com/jesseduffield/lazygit](https://github.com/jesseduffield/lazygit)

------
jeena
The example commit messages are triggering me.

------
shaneos
I took all my most common Git commands and made them far easier to type -
here's the script in case it's helpful to you
[https://github.com/shaneosullivan/git-
shortcuts](https://github.com/shaneosullivan/git-shortcuts)

------
jnurmine
Silly little alias, "git top".

    
    
      [alias]
              # top 10
              top = !sh -c 'git log --oneline|head -10'
    
    

It shows the top 10 commits. I use it several times every day, to orient
myself while flipping between multiple repositories and branches.

~~~
mhd
Isn't that just 'git log --oneline -10'?

~~~
jnurmine
Indeed, thanks. I've had the alias for years and never thought to optimize it.

------
psv1
Can anyone point to a good guide and/or tool for resolving merge conflicts?

~~~
coldpie
Set merge.conflictstyle=diff3!!!! The default merge style is utterly useless,
I have no idea why it is the default. diff3 gives you three pieces of
information: the status before at the common ancestor; the status on the
current branch; and the status on the to-be-merged branch. You can then
understand what changes were made on each branch, and decide how to merge them
intelligently. Without that common ancestor, it's way way harder to understand
what you're looking at.

------
stunt
Developers having hard time to master GIT after so many years is just a good
argument to "Why we need GO more than Scala" and a very disappointing reality
at the same time.

------
hansdieter1337
"UNEXP_CONT=$(ls sandbox/..." this will ignore hidden files. So does the "rm
-rf"

------
darnir
Awesome! Now show me how this is done in Mercurial

------
B1FF_PSUVM
#CodeSmell

(i.e. that this is necessary speaks volumes)

------
karmakaze
git reflog # for those times you get lost and want to go back

