gophering on
HN Gopher Feed (2017-12-18) - page 1 of 10
Oh shit, git: Getting myself out of bad situations
921 points by adishaporwal
teilo - 7 hours ago
I stubbornly stuck with Mercurial for a long time because of the
complexity of git's UI. But when one moves beyond a few developers,
the available tooling and extensive ecosystem for git makes it
  dhimes - 2 hours ago
  Still with hg.  You've frightened me.
falcolas - 7 hours ago
A git off my lawn moment: Every time I see someone complaining
because they have to dive into the reflog to fix their own mistake,
all I can hear is "I was operating my table saw without using a
push stick and can't understand why I lost a thumb".Friends don't
let friends (especially those who don't learn how to use their
tools) rewrite shared git history. If you don't understand rebase,
amends, etc can do to your (and everyone else's) repo, DON'T DO IT.
  AlexCoventry - 7 hours ago
  On the other hand, doing it is the only way you're going to
  learn. Just do it in a safe environment, with a snapshot of the
    jsmthrowaway - 3 hours ago
    Yep. That is the important tip, right here.    $ pushd ..     $
    cp -a my-project my-project-before-I-did-git-surgery     $ popd
    Then relax. This is extremely important before playing with
    nasty Git surgical tools such as huge rebases. Borked it up?
    $ pushd ..     $ rm -rf my-project     $ cp -a my-project-
    before-I-did-git-surgery my-project     $ popd  Undo is a great
    thing, and it's also important to triple check the entire state
    of the repository before you push, because pushing is basically
    committing to whatever surgery you've done. If you're having to
    fix stuff with -f, you're going to run into trouble; try to
    avoid -f ever.
      xaphod - 2 hours ago
      This is so wrong. :) With git you exactly do not have to
      backup your local workspace, because it already is backed up
      in git.If it is committed, it is safe. You can go back to it.
      If you messed up your branch, just reset it to something that
      was good. No need to do manual backups.
        jsmthrowaway - 1 hours ago
        No, it isn't, if you're playing with surgical tools that
        disrupt Git history, which was my point. It's a lot easier
        to revert to before you started than attempt to abort out
        of a huge rebase/squash/ugly merge conflict hell/rewrite of
        history. I'm not saying back up before every commit. I'm
        saying when `git status` is three pages long, you have
        14,000 conflicts, and you're on a detached HEAD God knows
        where, it's your choice to spend the next hour typing the
        right Git commands to get back where you wanted to be, or
        just back out and try again. I know which one I'd prefer.
          xaphod - 16 minutes ago
          I'm sorry if I sound rude. I don't mean to be. I'm just
          saying that backing up your git workspace to recover from
          rebases or merges gone wrong is not necessary. Those are
          not "surgical tools", they don't modify existing commits.
          (edit: yes you can "edit commits", but they only create
          new commits, the old commits are not deleted in the
          process and they can still be found easily)When you
          commit in git, that saves the whole project as a
          "snapshot". If you find yourself lost in some rebase hell
          or whatever, just reset HEAD back to a previous commit.
          It's simple as that! (git reset --hard )Why I
          decided to reply to your comment was because this is a
          very crucial part of learning git. When you realize that
          you can always go back to what was before, you can start
          experimenting more freely.
          jsmthrowaway - 1 minutes ago
          > git reset --hard Unless part of your surgery
          involves files that do not yet live in the history.git
          reset --hard is a very scary operation unless you're 100%
          sure of the entire state of the repository. That is a
          very rapid way to lose work if you're not flawless in
          your approach.
        bpchaps - 1 hours ago
        Sure it's wrong if you know what you're doing. But that's
        not who the blog post is for.Sometimes it's okay to take
        liberties with good practices - especially when learning,
        or when the world is on fire and a push needs to happen
          richforrester - 37 minutes ago
          > or when the world is on fire and a push needs to happen
          now.The unwanted reality we live in.
      palunon - 2 hours ago
      >If you're having to fix stuff with -f, you're going to run
      into trouble; try to avoid -f ever.I disagree. I don't have
      much experience using git with big teams, but at least for
      small team where a developer usually owns a feature branch,
      force pushing to the branch to take into account criticism on
      commits can be helpful. Of course, in that case, feature
      branches are considered non shared.Git own "next" branch is
      actually force pushed to all the time, to remove patches
      which didn't make the cut for example.
        jsmthrowaway - 1 hours ago
        > force pushing to the branch to take into account
        criticism on commits can be helpfulHm? Criticism on commits
        should be additive. The commit was made, response was made,
        and a new commit addresses the response. Rewriting history
        breaks a lot of things and removes context. Another
        approach:1) Add commit addressing criticism.2) Squash when
        merging feature in to master, which is one of the only
        cases where I think rewriting history is OK.Much cleaner
        master history, no rewriting history (which you should
        never do once another checkout sees your branch, including
        GitHub), and a number of other benefits. If you're
        routinely force pushing feature branches, something is
        broken in your workflow, IMO.
    flowardnut - 6 hours ago
    practicing safe version control is better than abstinence
      pretentiousPear - 4 hours ago
      I see what you did there...
  swalsh - 6 hours ago
  rebase can be dangerous, but so productive.  I think it's
  important to teach new devs how to properly use it.  Especially
  if you're working in a continuous deployment environment, where
  you may need to quickly revert something.
    Nullabillity - 5 hours ago
    You already have git-revert, for reverting commits without
    rewriting history.
      swalsh - 4 hours ago
      You're misunderstanding the purpose i'm describing.  Imagine
      100 commits a day, maybe more.  (I worked at a company that
      averaged 500 or more commits a day to the master branch.
      There were 1000 developers working in a monorepo).  Some code
      is out in production, and suddenly we realize a specific
      commit is causing a problem.  The idea here is to revert the
      commit as soon as you can, and then spend your time fixing
      it.  When reverting code is easy, and the company has good
      logging to identify problems, you can deploy more often.
      It's a good thing.But to enable this "revert-first" culture,
      you have to design your commits to basically be super easy to
      revert.  That means no merges in the master branch, you want
      to keep your revision history as clean as possible.  One
      commit, as little dependencies as possible.  Rebase is the
      right tool to use for this. The goal is a tidy linear
        Yokohiii - 4 hours ago
        That sounds quite chaotic and impossible to keep stable. I
        wonder who was responsible to find problems and fix the
        master after messing up?
        lmm - 2 hours ago
        > But to enable this "revert-first" culture, you have to
        design your commits to basically be super easy to revert.
        That means no merges in the master branch, you want to keep
        your revision history as clean as possible.How are these
        concepts related to each other? Merges don't make reverting
        any harder.
        drdrey - 23 minutes ago
        git revert is exactly the tool for the situation you are
      sirmarksalot - 3 hours ago
      Git revert has undesired side effects for merges. If you have
      a merge-only workflow (GitFlow, for example), and your pull
      request breaks something, a revert commit will not help
      you.After a revert, all the commits that were merged, are
      still merged, but then they're deleted. The next time you
      pull, git will delete the changes in your working branch.In a
      merge workflow, you have to either fail forward (fix the
      problem, rather than backing out the merge), or reset/rebase
      the shared branch, and email repair instructions to everyone
      on the team.
        lmm - 2 hours ago
        Create a feature branch, revert the revert, and then fix
        the problem. It sounds a little weird but it works fine.
          falsedan - 2 hours ago
          It?s a lot of paperwork to avoid a perfectly safe and
          normal git command.
          sirmarksalot - 1 hours ago
          To be fair, rebasing a shared branch really isn't all
          that safe. You can potentially make life hard for a lot
          of people.
          falsedan - 51 minutes ago
          That?s not fair. That?s fear, uncertainty, doubt. Those
          people pulling that shared branch will see a big honking
          warning message, which can easily be resolved if you
          communicate what?s happening and why you rebased the
          upstream.When you say, it?s not safe, it sounds like you
          could lose work or someone could be hurt, when it?s more
          likely that the removed ancestors could be merged back in
          by someone not using ?git pull ?rebase?, or other devs
          being put out by having to resolve some conflicts. It?s
          not great, but it?s a far cry from unsafe or DANGEROUS!
    falcolas - 5 hours ago
    Reverting something does not require a rebase. It requires an
    aptly named command "git revert". Additionally, in the event
    that a deployed feature needs to be reverted, any halfway
    decent change management policy will want a history of what you
    reverted and why; a git revert commit can show both very
    cleanly.And, frankly, since all rebase does is re-write
    history, I fail to see how it's inherently productive,
    especially in the context of re-writing the history of
    previously shared commits. Yes, it is capable of cleaning up
    and reducing the number of commits you have to read through
    when looking at history, but that's such a rare event that
    optimizing for it (especially by normalizing dangerous commands
    like `git push -f`) seems, well, premature.
      Yokohiii - 4 hours ago
      Completely agree. Rebase is practically only safe on single
      developer feature branches which haven't been merged or
      completely isolated repos that produces patches only. Keeping
      track of all requirements in the former is hard, especially
      if the dev doesn't know git pitfalls. No one should default
      to rebase in a day to day workflow, but it is quite common.
      Sir_Cmpwn - 5 hours ago
      Rebase is mostly useful for cleaning up local commits or
      feature branches. You can rebase without force pushing
    madeofpalk - 6 hours ago
    driving can be dangerous, but so productive. I think it's
    important to each new adults how to properly use it.
  leggomylibro - 5 hours ago
  Reminds me of a time I saw a funny Makefile mistake. SRCS
  contained both .cpp and .c files, and someone copied a recipe
  that only replaced .c ones.Then they used the resulting variable
  in 'make clean'. That was more of an, 'oh shit, git pull' sort of
  thing though.
amelius - 7 hours ago
> Oh shit, I did something terribly wrong, please tell me git has a
magic time machine!?!Shouldn't it be easy for Git to remove objects
created after a given time, and then remove all objects that refer
to those objects iteratively?
  icebraining - 6 hours ago
  I think that's exactly what it does; the default is two weeks:
aeorgnoieang - 6 hours ago
I too felt this way once, and I still have to think (or even
lookup) about what the conventions are occasionally, but there
really is a point in learning Git at which you realize there really
are not many 'oh shit' situations in which you can find yourself
and not be able to escape unscathed.But beyond learning Git itself,
you need to develop suitable habits for using Git that are
appropriate for your development workflow.One habit I've
consciously developed is to use 'WIP' commits (i.e. a regular
commit with "WIP: Rebase me!" on the first line of the commit
message) instead of stashing. All too often a stash lives for much
longer than you'd naively expect and stashes are much harder to
work with than commits. Even if the modifications are applied right
away, commits are nearly as easy to 'apply' as a stash anyways.
trevor-e - 5 hours ago
I think Git would be way more approachable if things were named
better. A key part of Git is whether a file is
untracked/unstaged/staged, yet the terminology around this is very
confusing. Why aren't commands simply `git stage`, `git unstage`,
`git add` (to track files), `git remove` (to untrack), `git undo`,
etc? Not to mention the overloaded command names like `git
checkout`, how is `git checkout -- someFile` intuitive at all?
  satish-setty - 4 hours ago
  This is precisely one reason I like Mercurial over Git. Hg has
  commands which are more meaningful than those of git.
    dhimes - 2 hours ago
    +1 hg.  I see it mentioned so seldom here that I'm actually
    worried it may go away.
  omg_ketchup - 5 hours ago
  Why not `git track` and `git untrack`?
    trevor-e - 4 hours ago
    TBH I'm not sure why I left add/remove in, track/untrack is
    simpler and more in line with what I was saying. :)
burgerdev - 3 hours ago
In choose your own adventure style:
herogreen - 7 hours ago
In three years of using git I believe there is a single bad command
that I could not undo: `git checkout -- somefile` The second worst
thing I did is losing a commit in a `git rebase -i` but I was able
to find it back with `git reflog`. Which makes me think that git is
really well designed.
  anton_gogolev - 7 hours ago
  If by "designed" you mean "picking a content-addressable DAG as
  an underlying data structure", then yes, it is really beautiful.
  If you mean "provide a sane level of abstraction over said data
  structure", then hell no!
    _pmf_ - 6 hours ago
    Beautifully stated.
    jimktrains2 - 7 hours ago
    I think git provides a sane level of abstraction.I don't think
    it provides the most consistent UI or helpful help, though.
    Once you move away from "learning git commands" to "learning
    how git works" and kind of figuring out which parts the
    commands refer to has helped also. That's still terrible
      ivix - 7 hours ago
      >I don't think it provides the most consistent UI or helpful
      help, though.Understatement! Git is one of the most user-
      hostile tools I've ever seen. And I've used Sendmail.
        pqh - 4 hours ago
        Just read the manual.
      lhuser123 - 7 hours ago
      > I don't think it provides the most consistent UIThat
      reminded a video where Linus Torvals is been interviewed and
      he says that if he ever have to make good UI to get out of a
      desert island, he would die there.
      hyperhopper - 1 hours ago
      lmm - 7 hours ago
      Most of the abstraction is fine. The staging area model is a
      total mess though. The way that staging interacts with other
      commands (e.g. stash) is constantly surprising.
        jefurii - 6 hours ago
        Git stage is "These are the things I'm planning to do", and
        git commit is "OK now do these things".  Lots of carpenters
        draw plans before they start cutting but we don't think
        that's so hard do we?I had trouble with Git until I
        discovered "git add -p".I'll grant that Git could do with a
        revision of its commands and args.
          lmm - 4 hours ago
          > Git stage is "These are the things I'm planning to do",
          and git commit is "OK now do these things". Lots of
          carpenters draw plans before they start cutting but we
          don't think that's so hard do we?But when a carpenter
          stashes and unstashes their things, they don't suddenly
          find out they're magically planning to do a lot of things
          that they weren't previously planning to do.
    tonetheman - 6 hours ago
    Preach on brother!!!!!
  0xcde4c3db - 7 hours ago
  I'm a big fan of 'git checkout -p'. Even if you nuke a hunk you
  actually wanted, it's not actually gone until it falls off your
  scrollback buffer.
    ronnier - 5 hours ago
    I go all in
  jimktrains2 - 7 hours ago
  Learning about the reflog just changed everything -- it removes
  all fear of "loosing" anything but uncommitted work.In a similar
  vain to `git checkout`, `git reset --hard` is also an excellent
  way to loose uncommitted work.
  philjohn - 7 hours ago
  The underlying system is well designed, but a user interface that
  allows you to get into a point where you can hose a repo is
  anything but.
    blibble - 7 hours ago
    you can always get back to what you had before unless you try
    really, really hard to destroy datagit reflog is your friend
    runeks - 6 hours ago
    The user interface should allow you to do anything you want,
    but warn you properly. In my experience, this is what git does
    if you?re about to do something dangerous.How can you blame git
    for deleting stuff if you blindly pass --force to it?
  Yokohiii - 5 hours ago
  When in doubt either:* commit to an itermediate branch as
  storage* git stash && git stash apply (repeat last to recover
    nathancahill - 3 hours ago
    git stash pop is often nicer for temporary stuff.
  humblebee - 3 hours ago
  When I know what file I'm missing a commit from, I usually end up
  using `git log` instead.    git log -p --all --first-parent
  --remotes --reflog --author-date-order -- somefile  I accidently
  screwed up a rebase and dropped a test file. It managed to get
  merged as a blank file (always review after rebase!), I noticed a
  few days later when a PR was passing which I swore would of
  failed some tests I had written. Since then I couldn't exactly
  remember when I made the commit to the file, so trying to search
  through reflog became difficult. The above command makes it
  pretty easy as it will show you every change made to a file.
  nvahalik - 7 hours ago
  I recently had one of those holy-crap-what-did-I-just-do-I-lost-
  everything moments... But then realized that my scrollback had a
  list of files and my IDEs (PhpStorm and WebStorm) both kept
  _local_ revision histories and I was able to restore everything I
  had done.
    Cthulhu_ - 7 hours ago
    I've had a few cases where I accidentally removed a local
    change before committing it; using Time Machine you can still
    recover some files then. I wish more editors had built-in
    support for it, if you're trying to restore a local file,
    macOS's TextEdit has support for Time Machine.
    maaaats - 6 hours ago
    I've been saved by the local history in IntelliJ more times
    than I would like to admit, heh.
    nsxwolf - 5 hours ago
    This combined with Time Machine backups means I haven't lost
    source in years.
yxhuvud - 3 hours ago
  git checkout name-of-the-correct-branch   # grab the last commit
to master   git cherry-pick master   # delete it from master   git
checkout master   git reset HEAD~ --hard  The two lines in the
middle can be  git cherry-pick -   git checkout -  , and voila, it
suddenly is name insensitive.
compiler-guy - 4 hours ago
The fact web pages like this exist, and are popular, and make it to
the top of Hacker News is all you need to know about git's ease-of-
use and mental model.That Perforce and SVN don't get such things
should also tell you something.(Which isn't to hate on git--it's a
great tool.)
  yes_or_gnome - 20 minutes ago
  The SVN and P4 articles exists (just google for "svn mistakes"
  and "perforce p4 mistakes"), but either 1. nobody is sharing them
  to HN or 2. they do and nobody cares to vote them up.Unrelated
  topic (falling cats), same logical fallacy: (Starting around
  forrestthewoods - 3 hours ago
  Threads like this are a nice reminder of how nice it is to use
  Perforce. There's no such thing as getting yourself into a bad
  situation. Not even for artists or designers.Git has eleventy
  million blog posts trying to explain how simple it is to use.
  That's a clear sign that it is, in fact, not simple or easy.
    accatyyc - 2 hours ago
    Reminds me of all articles attempting to explain how simple
    monads are
oelmekki - 7 hours ago
Maybe it's not worth being in there because of how simple it is,
but I guess it would be useful for newcomers:    # Oh shit, I've
changed 200 files and want to revert to the state of this morning
$ git add . && git commit # often. Very often.     $ git reset
--hard commit_id
  lemoncucumber - 5 hours ago
  I think this is bad advice for git newbies two reasons:1. ?git
  add .? is dangerous and should be avoided IMO, in case you ever
  have files around that you don?t want to commit. I frequently do.
  It?s better to ?git commit -a?, and to just remember to run ?git
  status? frequently and ?git add? any new files.2. ?git reset
  ?-hard? is dangerous as well for newbies, since it?s destructive.
  Better to ?git revert? or to ?git checkout ; git checkout -b
  ?, such that you can always get back to where you
  icebraining - 6 hours ago
  Wait, aren't you committing and immediately orphaning that
  commit? I think you should create a new branch or tag before the
  reset, otherwise how are going to get it back?I guess you could
  rely on the reflog, but I don't think that's good practice.
    oelmekki - 6 hours ago
    lol, no, it's implicit there are many hours between the first
    command and the second one :)It's purely commiting often to
    easily have checkpoints to revert to, nothing fancy (yet,
    incredibly useful).
  j605 - 3 hours ago
  git reset --hard for what!? If you are a newcomer making mistakes
  it is fine for the mistake to be in the commits. Just fix the
  problem and commit again.
tzahola - 5 hours ago
You mean, gitting yourself out of bad situations? ( ?? ?? ??)
legohead - 5 hours ago
So I just ran across this one: git diff --stagedI added a file and
wanted to diff it, and this command helped!  However, I made some
changes in the file, and when I tried this command a second time,
the changes don't show up :\  Only the original file that was added
shows up in the diff.  Now what?  It's not the end of the world of
course, as I can just look at the file in my editor, but I usually
use diffs as a personal code-review before I commit.
  nerdface - 4 hours ago
  Yes, this is another one that confuses developers. When you 'git
  add' a file, it's added to the staging area as it was at that
  time. If you make subsequent modifications after you've staged
  it, those are unstaged changes. And you can diff between them. So
  despite git add'ing a new file, you still have to 'git add'
  afterwards if you make changes to it.
  deathanatos - 4 hours ago
  There's three "versions" of the code at play, if you will:* the
  most recent commit* the staged files* the working directory`git
  commit`, as you might already know, takes "the staged files" and
  turns it into a commit, making that the latest commit. `git add`
  adds a snapshot of a file in your working directory to the staged
  files. The important bit here is that the copy of the file in the
  staging area is separate from the file in your working directory.
  So, if after `git add`ing a file you make more changes, you will
  need to `git add` those subsequent changes if you wish to commit.
  `git status` will tell you this:  ? git status   On branch master
  Changes to be committed:     (use "git reset HEAD ..." to
  unstage)            modified:   foo.txt      Changes not staged
  for commit:     (use "git add ..." to update what will be
  committed)     (use "git checkout -- ..." to discard
  changes in working directory)            modified:   foo.txt
  "Changes to be committed" is the staged files. "Changes not
  staged" is stuff that has been modified, but not `git add`'d. You
  can see here that I've changed foo.txt after git adding it; if I
  want those changes, I need to git add it again.I can look at the
  diffs, too:  # diff between the last commit, and the staged files
  # (i.e., what will be committed)   git diff --staged   # diff
  between the staged files and the working directory   # (unstaged
  changes)   git diff   # diff of all changes since the last
  commit:   # (stage+working dir, essentially)   git diff HEAD
  That should be all the various combinations.I find that a lot of
  newcomers find the staging area weird, and usually ask some
  variant of "why would I not want to commit all of the files I've
  changed?" The staging area, used effectively, can really help you
  break out things into logical chunks of changes that can then be
  adequately described with a message in a commit. This can help
  others later: if your change is a bug fix, and someone wants to
  cherry-pick it to production, they might not want your new
  feature, or your lint fixes: they want a minimally risky fix. To
  that end, the stage/working dir separation acts as a sieve of
  sorts, letting the stuff that's "ready to go" get filtered out
  into a commit.I want to mention the extremely useful `git add
  -p`: this command will interactively prompt you, hunk by hunk,
  for whether or not you want to stage that hunk. It will even let
  you edit the hunks prior to staging. So, for example, if I run
  across a spelling error, or a minor bug, I can very quickly add
  it (and just it) to the stage w/ `git add -p`, and then commit
  it, even if there are other modifications, even in the same file.
    jordigh - 3 hours ago
    > There's three "versions" of the code at play, if you will:> *
    the most recent commit> * the staged files> * the working
    directoryThis is weird. The staging area is like a commit but
    not a commit. They're changes that git is aware of and has a
    record of but not quite a permanent record.Why not just make it
    a commit? You can always keep editing commits, or throw them
    out, or whatever. That's what I do with Mercurial. I write a
    commit and I keep adding stuff to it if I think it needs more
    stuff (or less stuff).Gregory Szorc has a more extensive
    analysis of the situation  in first subsection here:
randallsquared - 7 hours ago
Also useful for panicky moments, with handy workflow: visit this page
every few weeks.  :)
pascalxus - 5 hours ago
This is a great resource, but I wish the name was different.  The
oh-shit reference is a bit too much.
sfink - 2 hours ago
You could also use an alternative CLI for git. My preferred one is
hg-git.I'm sort of kidding, but not really. By using it, I can
operate on a git repo using the mercurial CLI, which I am more
comfortable with and have built tooling around.Once you have the
extension installed, it's a matter of prepending 'git+' to the
beginning of eg a github url to clone it, and then you can use
native mercurial commands.Obviously, this is an extra layer with
all of the problems that involves (eg you're going to be managing
git branches through an hg interface. Which works surprisingly well
most of the time.) So this makes NO SENSE WHATSOEVER unless (1) you
are comfortable with the hg interface, (2) you aren't that
comfortable with the git interface, and (3) you don't need to do
complex operations that would require thinking through the layers
of what is happening.Honestly, though, if I want to contribute to a
github repo, this gives me everything I need 95% of the time. So
far, the only time I ran into trouble was when the active branch
was renamed in the github repo. Things got very tangled up, and I
had to re-clone and import my patch stack. Judging by the number of
people talking about making "backups" of git repos in this comment
section, it doesn't sound like that's an unexpected operation in
git-land. With mercurial's immutable and append-only nature, I very
very rarely need to do this, so it felt kind of awful.(Admittedly,
my main hg repo that I work on is 6GB and I'm normally near the
limit of my disk space, so my habits don't really match your
typical megabyte-sized github repo in some noncompiled language.)
mugglelover - 2 hours ago
?Oh shit I give up? should perhaps instead be `git clean -fdx`
jimmaswell - 5 hours ago
5+ years later and I still sometimes have to do the classic "repull
the entire repo into a new folder and manually copy the wanted
changes over"
mFixman - 6 hours ago
Honestly, a lot of what's wrong in git is that people seem to
mostly memorize or copy-paste a finite amount of commands, and when
something goes wrong they are completely lost unless they can find
a way to copy-paste a solution.Instead of saving a 6 command list
for some use cases, why not just get used to the simple but kinda
unintuitive way of how revisions and branches work? If you know
that, you can solve any problem with `commit`, `checkout`, `reset`,
`reflog`, and occasionally `cherry-pick`.
  CJefferson - 2 hours ago
  Quick quiz, what does 'git checkout x/y' do? I am aware of users
  hitting at least 3 interpretations.
    Nimitz14 - 58 minutes ago
    I'd say it changes your code to match that of a branch in your
    local copy of the repo.
      CJefferson - 28 minutes ago
      It resets the file x/y, or checks out branch y of remote x,
      or checks out local branch x/y. I've had confused users
      manage to create al of these cases, and git is very unhelpful
      in explaining the difference between the three cases.
  ufo - 3 hours ago
  I think you already answered your own question. It is very hard
  to get comfortable with things if they are unintuitive :)
mugglelover - 2 hours ago
Oh shit I give up could instead be `git clean -fdx`
mamon - 7 hours ago
The very existence of such guides tells us a lot about how easy to
use Git is :)
  welly - 7 hours ago
  By and large, git is easy to use. Most people will do little
  beyond committing changes and very occasional branching and
  merging with the likelihood of not needing any of the tips in the
  site posted.For these users, git is perfectly useable and easy to
  rootlocus - 6 hours ago
  Well, I think it tells how much time some developers are willing
  to spend learning the tools they are using.
  Cthulhu_ - 6 hours ago
  Name me any software that doesn't need a guide like,
  how do you even exit vim? You need a guide for that. Or to get it
  closer to git / this guide, how do you undo / redo?
    oblio - 6 hours ago
    You're comparing git to vim in terms of ease of use...
      SAI_Peregrinus - 4 hours ago
      That's actually a rather good comparison. Both have learning
      cliffs of doom[1]but once you've spent a few months with them
      they're arguably more powerful than the other options.
      They're usually fast to use but very hard to learn. I
      wouldn't say either one is easy though.[1] https://dementiaga
        oblio - 21 minutes ago
        That's debatable. I don't think anyone has actually made
        any study which proves that git is superior to Mercurial or
        that vim is superior to Notepad++ or Sublime.
  migueh - 5 hours ago
  Truly right
aaronsnoswell - 1 hours ago
Haha. There should be an entry there for 'Oh shit - I just pushed
our private keys to the public github repo'.
  yes_or_gnome - 54 minutes ago
  Just as an FYI, those will likely live in Github forever. Run
  `git ls-remote` where ever you have had this problem. You'll see
  that there are refs for every PR in the form
  `refs/pull/NNNN/head` and `refs/pull/NNNN/merge`; where `NNNN` is
  the PR number, `head` is the latest commit and `merge` is the
  final commit.If any of those commits with confidential
  information is reachable from any of those commits, then they'll
  never be garbage collected from Github.
WhyNotHugo - 1 hours ago
Geez, using `git add .` is the worst thing you can do. Never use
this. Tutorials: stop suggesting this. It's just a recipe to
getting yourself into a mess (plus, you should never work so
blindly!).Add individual files, and, if possible, use `git add -p`,
which lets you review each chunk before adding it to the index.
Otherwise, diff and add individual files.
  ninkendo - 1 hours ago
  Hell, even if you want to stage every change, what you really
  want is `git add -A`, which stages deletes too (`git add .`
  ignores any files you've deleted or renamed, it only stages new
  files and changes to existing files.)
lkrubner - 7 hours ago
I've said this before, but the business leadership, and tech
leadership, need to think carefully about whether or not they need
all of the power of Git. This sums up my
concerns:-----------------------Here are some minor failure modes
I?ve seen with Git:1. a branch that stays open for many months,
perhaps even a year (for instance, at Maternity Neighborhood)2.
data is erased for good because someone makes a mistake while using
rebase3. a developer introduces a new bug while trying to resolve a
merge conflict4. widespread but fine-grained cherry picking leaves
the team unclear about what?s been merged and what has not been
merged5. a developer makes a change in the wrong branch because
they forgot what branch they were in6. a developer is unable to
recover a stash because they forgot where they were when they
created the stash, or they simply forget that they have work in a
stash7. developers confused by working in an unattached commit,
after a botched attempt to revert8. a developer feels the need to
delete the repo from their harddrive and clone it again, because
the whole repo got into a state that they seemed unable to
resolve9. the ?blame? command is nearly useless ? maybe its because
we never know in which branch a given change was made, finding who
made a mistake is very difficult10. developers get confused about
which branch will be deployed (I see this especially in shops that
have lots of repos for lots of small apps, and use different Git
workflow strategies for the different repos, often because
different programmers or different teams control the different
repos)11. developers push their changes to ?origin? but forget to
push to ?upstream? or vice versa.But all of that stuff is trivial
compared to the major flaw:Graphic designers, writers, HTML/CSS
frontenders, managers, data analysts and QA staff can?t use Git,
even though they all used
  rootlocus - 7 hours ago
  > 2. data is erased for good because someone makes a mistake
  while using rebaseNo. Just no. Please stop spreading FUD like
  it's candy. Git only deletes commits after a GC, which won't
  erase commits from reflog and will keep unreferenced commits for
  at least a month before deleting them. And rebasing generates new
  commits, leaving the old ones exactly how they were. If somebody
  lost a commit after a rebase, and nobody nearby could help them
  recover it, they should consider spending a few hours learning
  about git.I've been using git for 4 years both at work (with a
  team of 40+ people) and at home, without ever having any of the
  problems listed here (except 3 which has nothing to do with git).
  It takes a few hours, maybe a few days to understand how git
  works and how to use it. Instead of blaming the tools, you (and
  your team) should probably learn how to use them.
    lkrubner - 4 hours ago
    About this:"No. Just no. Please stop spreading FUD like it's
    candy. Git only deletes commits after a GC, which won't erase
    commits from reflog and will keep unreferenced commits for at
    least a month before deleting them."It is frustrating that you
    continue to take your advanced skills for granted. It is
    frustrating that you can not see what should be an obvious
    fact: that your skills are above average and therefore it is a
    mathematical fact that most people have less skill than you,
    and their lack of skill is a real world business situation that
    needs to be dealt with realistically. And more so, for the rest
    of your career your skills will continue to develop, so the gap
    between you and the average will continue to grow, and
    therefore the damage that you can do will continue to grow, if
    you fail to recognize that you are above average.I can assure
    that I've seen data lost forever because of "git rebase". It
    doesn't matter that someone with your skills could have saved
    the situation. You were not there, therefore your skills don't
    matter! It is very important that you see this, or you will
    never be able to give accurate advice to business leaders.If
    the leadership of a company decided to hire people with a skill
    level of x, then they should not also use a technology that
    requires a skill level of x + 1. You can reasonably tell them
    "For what you are trying to do, you should hire people with a
    skill level of x + 1." That is exactly what I did in the
    situation that I describe here:
    Tech-Startup-Easy-Steps/dp/09...But sometimes the business
    leadership will disagree with you. They may have terrible
    reasons, but if you can not get them to change their minds,
    then you need to deal with the consequences of their bad
    decisions. At which point it makes sense to advocate for a
    technology that only requires a skill level of x.[ EDIT TO ADD
    ]I'll point out that you are demonstrating a classic case of
    the Dunning?Kruger effect. In particular:"the miscalibration of
    the highly competent stems from an error about others."That is,
    you have above average IQ and skill, therefore you perceive
    things to be easy, which are in fact not easy for the average.h
    are an elite programmer. Try to avoid acting like the kind
    elite programmer that I criticized in "Business productivity
    has been undermined by the hubris and power-grabbing of elite
    computer programmers".
    lkrubner - 6 hours ago
    "Instead of blaming the tools, you (and your team) should
    probably learn how to use them."From the
    essay:--------------------And Git is intimidating, not just to
    non-technical staff, but also to inexperienced programmers. In
    How To Destroy A Tech Startup In Three Easy Steps I talk about
    Sital, and his unwillingness to commit things to Git. He was
    learning a great deal about many other technologies, and he
    didn?t have any spare energy to learn about Git. He went a
    month without making a commit, and then he only did so because
    I insisted. After I put a lot of pressure on him, he got to the
    point where he would make one commit a day, at night, when he
    was stopping for the day. He would commit to the master branch,
    because he was confused how to handle different branches. When
    there was a merge conflict, I would resolve it for him. We
    worked together for 6 months, and in that time he learned a
    great deal about a lot of important topics, but he never really
    learned how to use Git, because it was a low priority, for both
    him and our CEO.
      rootlocus - 5 hours ago
      > He was learning a great deal about many other technologies,
      and he didn?t have any spare energy to learn about Git.Git is
      something that you can use on almost any project, with any
      team, at any company. It's something you need to use if you
      want to contribute to open source. Aside from your
      programming language of choice, it's probably the second most
      useful tool you should be learning as a software
      developer.You're telling me a developer was too busy learning
      "other technologies", and in 6 months he couldn't be bothered
      (or was too afraid) to spend one or two hours going through a
      simple course about git? By that argument, he probably
      couldn't be bothered to learn how separate concerns into
      classes or how to use refactoring or write tests. What other
      things didn't he have time for? Unwillingness to learn is not
      an excuse.> he never really learned how to use Git, because
      it was a low priority, for both him and our CEO.I think it
      was more of a lower priority for your CEO than Sital.
      Learning git was something that benefited him more than it
      benefited the company.I still have issues with your attitude,
      because it can be applied to anything useful in software
      development, but management might take issue with. Writing
      tests? Who needs them? The CEO doesn't care so they're low
      priority. Refactoring? Waste of time. Management wants shiny
      features not code quality. Developers have tried really hard
      to convince management that some overhead is needed to keep
      the quality high and maintenance easy. Your attitude is the
      exact opposite.
        lkrubner - 4 hours ago
        * Your attitude is the exact opposite. *You setting your
        theory against my lived experience. If you want to
        understand the situation more fully, you can read How To
        Destroy A Tech Startup In Three Easy
        Steps/dp/09...I did my best to re-create the extent to
        which decisions were driven by panic and the pressure of
        time.Please note, every company in the world has a finite
        amount of time, and a finite amount of money. You can argue
        that a company should hire people with more experience, but
        people with more experience will be more expensive, so you
        will end up with less people. Or you can argue that a
        company should hire more people, of less experience, and
        then train them. Training takes time, so in this case you
        are trading time for money.All of these strategies work,
        but in different circumstances. In the circumstances that I
        faced in 2015, described in the book, I advocated for the
        strategy of less people, of a higher skill level. I was,
        however, outvoted, which is a reality of corporate life.It
        is relatively rare that a company follows an ideal
        strategy. What I see instead is constant course correction,
        often with a bit of a lag, so that the company ends up
        having the ideal strategy for dealing with the situation
        that it faced 6 months ago, which is not necessarily the
        ideal strategy for what it is facing now.Business tends to
        be chaotic. The Platonic Ideal of computer programming
        needs to be adjust to the real realities that businesses
        face.To be clear, Sital's attitude was a major problem, and
        myself and co-workers advocated that he be fired. But
        management kept him on, and I was given the responsibility
        of covering for the gaps in his knowledge. I was not happy
        about this, but this is a reality of business: we often
        have to accept that a decision has been made that we
        strongly disagree with, and then we need to somehow make
        the best of it.
          dennisgorelik - 3 hours ago
          > Sital's attitude was a major problemWould it be the
          best if Sital never committed his changes? That way he
          would not be able to hurt your project and you would be
          able to fire Sital sooner.
          lkrubner - 12 minutes ago
          My leadership philosophy is "fire fast". I shouldn't have
          to jump through a bunch of hoops to fire someone, at
          least not under the rules that hold sway in the USA.
          Obviously the approach needs to be adjusted to fit with
          the laws of whatever nation you might be in. But in the
          USA, the law is lenient towards leadership when
          leadership wants to fire someone. Therefore, I should
          have been able to simply fire Sital. Then we would have
          hired someone good.
          rootlocus - 4 hours ago
          Well, I see you're adding more and more constraints to
          suit your point of view. First you attacked git by
          pointing out some flaws that were only just about people
          not knowing how it worked. Then you gave a more specific
          example, where actually, it was in the company's best
          interest to hire a novice developer who didn't have time
          to learn git, because he was pressured into focusing on
          whatever the CEO wanted. Then you argued that really,
          companies can't hire good people, or train them, or use
          good practices and we should just use the path of least
          resistance. At the end of the argument, it wasn't really
          about git.The issue you have with git, is that untrained
          developers have a hard time using it. Which brings me
          back to my original comment. It really doesn't take long
          to train someone to use git. And you can choose whatever
          flow you want. That's the beauty of it. If the company
          hires lower skill people, you can just guide choose a
          branching mode suited for their needs. They don't even
          need to use branches. Or just teach them to use an UI.
          But please don't teach them SVN.
          lkrubner - 4 hours ago
          You don't give a reason for this:But please don't teach
          them SVNWhy would you say this?You also say:If the
          company hires lower skill people, you can just guide
          choose a branching mode suited for their needsIf the
          company has lower skill people, why not go with the
          technology that requires less skill? This seems like an
          obvious step.
          rootlocus - 3 hours ago
          Because SVN is painfully slow, bloated and almost nobody
          uses it anymore. You'd be doing them a disservice by
          teaching them a technology they most likely won't be able
          to take with them to their next job.
          lkrubner - 4 hours ago
          This is simply untrue:"The issue you have with git, is
          that untrained developers have a hard time using
          it."Please re-read my first post, up above, which started
          this thread. I wrote:"But all of that stuff is trivial
          compared to the major flaw:Graphic designers, writers,
          HTML/CSS frontenders, managers, data analysts and QA
          staff can?t use Git, even though they all used
          rootlocus - 3 hours ago
          Ok, I agree, attacked your weakest argument, which you
          specifically marked as being trivial flaws. So to address
          your actual issue:> Graphic designers, writers, HTML/CSS
          frontenders, managers, data analysts and QA staff can?t
          use Git, even though they all used Subversion.Why is it
          hard for them to use git? For simple use cases, git can
          be as easy as commit & push. No need for branches. There
          are even UIs which allow you to easily make commits and
          see the log [1]. If more people work together and
          conflicts arise, I honestly don't know how SVN is better
          at solving them.[1]
          lkrubner - 1 hours ago
          "Why is it hard for them to use git? "All I can do is
          quote what you wrote in a different comment:"If you're an
          artist, git is not for you."
    burstmode - 5 hours ago
    >If somebody lost a commit after a rebase, and nobody nearby
    could help them recover it, they should consider spending a few
    hours learning about git.GIT is the only source control system
    where you can completly loose commited data by actions (or
    commands) available the non-admin user. It's funny to see that
    this is considered a "feature" and not a design failure.
      rootlocus - 5 hours ago
      > completly loose commited dataExcept the whole point is that
      you can't completely lose commited data, even if you tried
      really hard. And the solution to the problem was `git reflog`
      which shows the history of the HEAD.
  vijucat - 6 hours ago
  Great list. You'll face a predictable backlash by git fanatics,
  but the fact remains that git's surface area / complexity is way
  beyond the needs or wants of non-technical users. This is another
  good rebuttal to the supposed shortcomings of svn which make git
  necessary:'re right about the joy that
  end users feel when they learn TortoiseSVN and are able to put
  what they see as "infinite undo" into practice so easily.There
  was a sarcastic list of git koans, too, somewhere, which I found
    rootlocus - 5 hours ago
    Almost everything on that list is wrong, but if I point
    something out (because I actually learned how it works), I'm
    just a predictable git fanatic? How is that different from
    burying your head in the sand?
      lkrubner - 5 hours ago
      because I actually learned how it worksThe argument is
      focused on those who can not learn how it works. See some of
      the other excerpts from the essay that are in this
      thread.Also, it's important to note that everything on that
      list is something that actually happened. Be careful about
      comparing your advanced skills to people with less skill than
        rootlocus - 5 hours ago
        > The argument is focused on those who can not learn how it
        works.If you're a software developer who uses branches and
        merges, you absolutely should learn how it works.If you're
        an artist, git is not for you. It can neither store large
        binary files efficiently, nor merge them. There are other
        VCS that supposedly can, but I haven't tried them.> Also,
        it's important to note that everything on that list is
        something that actually happened.I can assure you, no data
        was permanently lost. What did happen is somebody couldn't
        find it, because they didn't know where to look. And I
        argue they should have, because git is not really that hard
        to learn (as a developer).
          lkrubner - 4 hours ago
          If you're an artist, git is not for you.Exactly. That is
          the entire argument. From the essay:------I agree, Git is
          amazing and very powerful. What I?m suggesting is that we
          should recognize that it has a very high cost. It might
          empower complex workflows for sophisticated teams of
          experienced computer programmers, but it exiles the rest
          of the staff, and this has significant productivity
          costs....Git is very powerful? I?m willing to go along
          with that line of thought so long as we all understand
          that using a tool that is more powerful than needed can
          lead to problems.
          /business-productivity-h...[ EDIT ]Also, this bit from
          the essay might make the argument more clear:For many
          years, I had a refrain which I gave as advice to each
          client I worked with: ?Your software developers are
          expensive, so try to shift work away from them.? Ideally,
          software developers should only do work that relies on
          skills that no one else has. If a task can be done by a
          graphic designer, then it should be done by a graphic
          designer, because generally graphic designers are paid
          less than software developers (obviously not in all
          cases, but most of the time). I co-founded a startup in
          2002, and I stayed with it till 2008, and we ran a team
          of 8 people using this principle: push work to the less
          skilled people, if they can handle it. Save the tough
          stuff for the computer programmer. We had great success
          with this style of work.
  teilo - 7 hours ago
  Most of these have nothing to do with git, but are true of any
  distributed repository. At that point, your argument becomes:
  distributed repositories are bad for business.Then there's this:>
  Graphic designers, writers, HTML/CSS frontenders, managers, data
  analysts and QA staff can?t use Git, even though they all used
  Subversion.What rubbish. The features of subversion are a subset
  of git, and the git equivalents are easy to learn. For a svn
  user, there's literally only a single additional command they
  need to know: git push.
    lkrubner - 6 hours ago
    distributed repositories are bad for business.If you read the
    whole essay, you will see that "distributed repositories are
    bad for business" is exactly the argument being made.
    ryanbrunner - 6 hours ago
    To be fair, git is the first VCS I've ever used where there was
    any real learning curve at all for normal, everyday use. I
    don't recall anyone ever really teaching me subversion, outside
    of maybe 5 minutes walking through the GUI. With git I feel
    like it probably took a few months of regular use before I felt
    comfortable with it.That doesn't mean that I'd go back to
    subversion, but I don't think it's fair to say it's as easy to
      DougBTX - 3 hours ago
      I remember trying to do merges in SVN years ago, it was so
      hard my team agreed to just never make new branches. Git it
      so much easier to use, it seems hard to compare.
        ryanbrunner - 2 hours ago
        For branching / administration you're probably right.
        Typically though, subversion workflows would involve
        administrators doing most of the heavy lifting of branching
        / merging and everyone else working against those - for
        those users Subversion was absolutely easier.
    icebraining - 6 hours ago
    The features of subversion are a subset of gitWell, except for
    locking, which I hear is useful for people working with hard-
    to-merge files.
  ryanbrunner - 6 hours ago
  I'm not necessarily the biggest git fan in the world, but here's
  some refutations to some of these concerns:> 1. a branch that
  stays open for many months, perhaps even a year (for instance, at
  Maternity Neighborhood)This is more of a workflow question than a
  VCS question, and would be true of any VCS that allows branching
  (i.e. anything remotely close to a modern VCS)> 2. data is erased
  for good because someone makes a mistake while using rebaseData
  isn't permanently removed from rebasing, you can still get at it
  with the reflog. If you discovered the problem months later, I
  suppose that could happen. checkout and reset --hard can
  irrecobably destroy uncomitted data (as can clean, but that's
  more obvious and has appropriate guardrails)> 4. widespread but
  fine-grained cherry picking leaves the team unclear about what?s
  been merged and what has not been mergedOveruse of cherry-picking
  feels like a workflow smell to me, but even still, you shouldn't
  need to care. Merging the entire branch will work fine if some of
  the contents have been cherry-picked previously.> 5. a developer
  makes a change in the wrong branch because they forgot what
  branch they were inTrue of any VCS with branching.> 6. a
  developer is unable to recover a stash because they forgot where
  they were when they created the stash, or they simply forget that
  they have work in a stashI'll agree with you here, I think stash
  is a bit of a footgun and almost never makes sense to use if the
  stashed contents are going to live for longer than a minute or
  two. But this is easily addressable with workflow, don't use
  stash for anything other than an extremely temporary holding
  place.> 7. developers confused by working in an unattached
  commit, after a botched attempt to revertGit is generally not
  great about warning you about dangerous operations or things you
  shouldn't be doing. Running against a detached HEAD is not one of
  those things, you'd have to be willfully ignoring what it's
  telling you to not realize that this isn't a safe thing to do.>
  8. a developer feels the need to delete the repo from their
  harddrive and clone it again, because the whole repo got into a
  state that they seemed unable to resolveI will agree that git
  could make it easier to say "just get me back to origin, i give
  up"> 9. the ?blame? command is nearly useless ? maybe its because
  we never know in which branch a given change was made, finding
  who made a mistake is very difficultBlame isn't great, but it
  sucks in precisely the same way it sucks in any VCS. Just seeing
  who last committed a line often isn't enough information. It
  would be cool to see an alternative here, but I don't see many
  better alternatives around.It sounds like in general, this is
  more a concern with dealing with branches and branching, which is
  totally fair. If simple trunk-based development works for you,
  branches are an unnecessary addition. But there's no reason you
  have to use all these git features. You can happily have everyone
  just work against master and never need to think about branches
  (in that mode the various Git GUIs will probably be more than
  adequate as well).I do agree that git tutorials tend to focus on
  a more advanced branching / rebase focused workflow, and that
  simpler resources for less technically minded folks would be
    lkrubner - 5 hours ago
    * there's no reason you have to use all these git features *If
    you are not using all of the Git features, then why use Git?
    Why not use something simple, like Subversion? As I wrote in
    the linked essay:-------------------When I list these
    complaints for developers, most of them respond ?You are
    complaining about Git?s power. The stuff you list isn?t really
    a flaw, rather those are all examples of how amazing Git is. It
    is flexible enough that you can do almost anything with it.?I
    agree, Git is amazing and very powerful. What I?m suggesting is
    that we should recognize that it has a very high cost. It might
    empower complex workflows for sophisticated teams of
    experienced computer programmers, but it exiles the rest of the
    staff, and this has significant productivity costs. And Git is
    intimidating, not just to non-technical staff, but also to
    inexperienced programmers. In How To Destroy A Tech Startup In
    Three Easy Steps I talk about Sital, and his unwillingness to
    commit things to Git. He was learning a great deal about many
    other technologies, and he didn?t have any spare energy to
    learn about Git. He went a month without making a commit, and
    then he only did so because I insisted. After I put a lot of
    pressure on him, he got to the point where he would make one
    commit a day, at night, when he was stopping for the day. He
    would commit to the master branch, because he was confused how
    to handle different branches. When there was a merge conflict,
    I would resolve it for him. We worked together for 6 months,
    and in that time he learned a great deal about a lot of
    important topics, but he never really learned how to use Git,
    because it was a low priority, for both him and our CEO.Git is
    very powerful? I?m willing to go along with that line of
    thought so long as we all understand that using a tool that is
    more powerful than needed can lead to
      rootlocus - 5 hours ago
      Because git is magnitudes of times faster, and it's the most
      widespread VCS in the world at the moment.
        lkrubner - 3 hours ago
        Those are weak reasons, if Git is the wrong choice for the
afshinmeh - 7 hours ago
Last one in particular:
rootlocus - 6 hours ago
I think lists like these are part of the problem. You shouldn't
rely on tricks to use git, you should understand how it works.
  migueh - 5 hours ago
sigmonsays - 5 hours ago
Git is easy once you understand it. What are people doing that is
so difficult to understand?
  migueh - 5 hours ago
  Use without understand it
kbenson - 4 hours ago
I've always found this flowchart[1] wonderful and concise for
handling this problem (that is, how do I fix the problem I've made
for myself with git)..1:
0xmohit - 7 hours ago
A collection of commonly used git tips and
  0xmohit - 7 hours ago
  Learn git one commit at a time:
Waterluvian - 6 hours ago
I gave up on rebasing or any form of history rewrite after going
through the screw up phase, then watching every dev that came after
me do the same at least once.I realised that treating a git repo
like an immutable collection, where existing commits are NEVER
mutated makes it far easier to reason about history and nearly
impossible to do serious damage.Devs can do whatever they please
with their own local pulls (such as squashing 50 rambling commits
during dev), but once a commit is on remote, it never changes.
tnolet - 6 hours ago
Good thing HN doesn?t have memes, otherwise I would post one of
those bears confessing ?I?m a software engineer with 19 years of
experience and I still don?t really understand git?.Silliness
aside, I guess Git suffers from the trait that it is very hard for
many people to internalize and visualize how it works in their
heads. Totally different but related: the Azure CLI is for some
reason 10x easier to work with than the AWS CLI, while I?m 10x more
experienced with AWS. I guess CLI design is also design.
anonymousjunior - 1 hours ago
reminds me of
aetherspawn - 1 hours ago
For me the big thing was learning to 1/ not work on master unless
I?m alone and 2/ commit all my work incrementally    git pull
?-rebase  &    git log      git rebase -i HEAD~n  So basically I
want to make sure my work is pushed to remote as a separate commit
before attempting to run any commands except the ones above. But
you can do pretty much anything with the set above.
btbuildem - 7 hours ago
In short:| Oh shit, I do before I think
  Cthulhu_ - 6 hours ago
  Yeah that explains a lot of git mishaps - typos, a missed `--`,
  `master` vs `origin master` vs `origin/master`, `reset` vs
  `checkout`, that kinda thing. A lot of things that can go wrong
  with subtle mistakes, and a lot of things that can go wrong
  thanks to muscle memory.
DonnyV - 6 hours ago
This is why UI's were created. No productive person wants to fill
there heads with a ton of commands and switches when you could just
click a button.
  mikestew - 6 hours ago
  Which button? What happens when I click it? Am I going to have to
  remember this later?It?s all ?choose your abstraction?, so you?ll
  be filling your head with something whether it?s which button to
  push or what git checkout does. GUI or not, no button alt text is
  going to tell you what rebase means.
city41 - 4 hours ago
One thing I do if I'm a little uncertain about my upcoming git
actions is just move to a new branch: git checkout -b
tryScaryGitStuff. That way if I ruin the commits, the original
branch is still around as a back up.
hitekker - 7 hours ago
I like using IDEA, PyCharm's and Webstorm's "local history" feature
to compensate for gaps in my git knowledge.A constant, instant
backup of all files, independent of the repo, has been my saving
grace for small projects.
  vbuwivbiu - 7 hours ago
  + it shows you a diff with the ability to revert individual
  changes in code
  nvahalik - 7 hours ago
  I recently did something like that?I think I did a reset of the
  repo and lost all of my changes. Was able to piece it back
  together using local history. Took me another 20 minutes, but at
  least all of my data was there.
anotherevan - 1 hours ago
?Git gets easier once you get the basic idea that branches are
homeomorphic endofunctors mapping submanifolds of a Hilbert
space.?? Isaac Wolkerstorfer (@agnoster)
Vel0cityX - 3 hours ago
Pretty basic stuff (and very few of them), I expected more.
nikanj - 7 hours ago
We pushed large binaries into our git in the past. This was fine-
ish as long as Git was hosted inhouse, but now that it's SAASed
out, they are a huge pain in the rear.I've browsed through a few
git guides, but can't seem to find anything that would let me:1) Do
something like "du -s *|sort -n" for the entire Git history2) Let
me "rm -rf --from-history-too", that would cause the remote repo to
actually shrink in size.
  bulatb - 7 hours ago
  Have you looked at git-filter-branch?The BFG program in this
  guide [0] seems reasonably close to #2. I don't know if you would
  need to manually trigger garbage collection in the remote repo,
  or how you'd do that.
  vulkoingim - 7 hours ago
  Have you tried this:
  cleaner/I've used it in the past, and it's pretty straightforward
  and does the job well :)
  mistersquid - 7 hours ago
  Early in the history of a repository, I committed some files with
  sensitive information. The only way to fix this (and similar
  problems) is to reconstruct the repos starting from the commit
  just before you committed the unwanted file(s).I'm a bit of a git
  naif, there are doubtless better ways to do this. This was mine:
  0. Back up my repo.   1. Save the entire commit history as patch
  files.   2. Use BFG (amazing tool) to scrub all references to the
  unwanted files [0]   3. Create new repo from the commit just
  before unwanted files.   4. Apply the patches.   5. Use a custom
  Perl script to apply the dates in the patch files to the new
  history. [1]  Technically, your repo will be fully reconstructed
  at step 4. Also, be advised the patch files themselves may have
  to be massaged to remove references to the file(s) in question.
  If the filenames themselves are not unwanted, you can add them to
  .gitignore for good measure.Step 5 merely preserves the dates of
  the original commits. Keep in mind that for this last step, your
  script will have to work in reverse chronological order as the
  history will be altered from that point forward.  [0]   [1]
  git-commit/  EDIT: Swap steps 1 and 2. Add advisement that patch
  files may require manual alteration. Add hint regarding
  .gitignore. Title case "Perl".
  titanomachy - 7 hours ago
  mitchty - 6 hours ago
  You'll be rewriting history via filter-branch, e.g. everyone
  would need to do the same for the clone and be sure not to push
  up the old history:
  StringyBob - 5 hours ago
  For part 1 - I used this
  out...Which for part 2 then leads to the BFG repo cleaner (which
  I haven't used)
  pmjordan - 7 hours ago
  I think you should be able to do something like this with  git
  filter-branch  This won't be a terribly fun exercise, and could
  be very painful if your history contains a lot of merges. (should
  be easier with the cactus/rebase development model)And of course
  everyone will have to hard-reset to the new branch.I should
  mention I'm far from an expert on this. I've only ever used git
  filter branch on a handful of commits, and only based on examples
  provided by kind internet people. I certainly haven't done
  anything nearly as far-reaching as you're about to embark on.
    Cthulhu_ - 7 hours ago
    Yeah, filter-branch is the way to go for this. Also to for
    example extract a folder into a new repository. I've used it in
    a few cases.
  pierre-renaux - 7 hours ago
  Git bfg should do the job, it works well for that and to remove
  files with secrets... or really anything you want to pretend
  never existed in your repo :)
m6PeelVLsQ8QawN - 7 hours ago
It happens to everyone :)I'd like to contribute my list of git
  lmm - 7 hours ago
  > I used git in the terminal and the diffs/patches/merges/pull
  requests don't turn out rightYour answer there is just doing git
  pull --rebase by hand. I don't like that style at all, but if you
  must do it surely use the command that's designed for doing it.>
  I pushed stupid things onto the remote serverWorth saying you can
  branch before fixing - that might be a little less intimidating
  than "access by commit ID"> I already made my changes in multiple
  commits, but the repo owner wants me to rebase it to a single
  commitDisagree with "you should do it", though that's probably a
  political question.
    m6PeelVLsQ8QawN - 5 hours ago
    Thanks for the review! I actually wrote that years ago (in
    frustration). Will give it a revision when I have time.I think
    I would rebase my PR comment history away only if "the repo
    owner wants me to rebase it to a single commit". In that case,
    I'm just doing whatever the repo wants the repo to be
Yokohiii - 5 hours ago
The site should clearly differ between local changes and pushed
changes. Latter usually requires different strategies to recover,
depending on repo policies.Git golden rule: Never push -f if you
don't know what you are doing.
greysteil - 7 hours ago
Nice. For anyone who hasn't see it, Flight Rules for Git is even
more comprehensive:
  james-skemp - 7 hours ago
  I like this. I was trying to do something similar with my Git
  cheatsheet - - but it
  doesn't have the kind of organization I'd like due to the
  limitations of using a Gist.
  taoistextremist - 7 hours ago
  I'm planning on making a hard push for git on the team I just
  joined (that isn't using any VCS). This and OP are going in my
    Cthulhu_ - 7 hours ago
    > I'm planning on making a hard push for git on the team I just
    joinedYou mean a force push. `git push --force` is one of my
    favorite commands. I've aliased `git yolo` to `git push --force
      icebraining - 6 hours ago
      --force-with-lease is usually the better option; it makes
      sure nobody pushed anything since the last time you fetched
      from the remote.If they have, you can fetch, see if you still
      want to overwrite that branch, and if so run it again.
      taoistextremist - 7 hours ago
      Maybe I ought to also insist I build git from source and
      scrub any reference to --force from it.
        graywh - 7 hours ago
        Use Gitlab and you can at least prevent --force push with
          Shank - 5 hours ago
          GitHub does this too.
      nasredin - 2 hours ago
      >git yoloI hope you do not work on missiles or on passenger
    pc86 - 7 hours ago
    I'm genuinely curious how they manage source without any VCS.
    Is it just a bunch of zip files for old versions?No judgment,
    nobody is born knowing this stuff, just that I'm surprised to
    hear this is still out in the wild.
      ryandrake - 3 hours ago
      I remember joining a company where the official build was cut
      from whatever was on the engineer's PC at the time, since
      that PC was the only one set up that could build the
      software. No documentation, no formal bug tracking, no source
      control, very infrequent backups that were probably never
      tested. It was basically a "0 on the Joel Test" shop. This
      software was for embedded aerospace applications too (however
      not safety-critical where DO-178B would apply, thank god).
      nobleach - 7 hours ago
      When I started working for the government (2010) it was
      .backup, .bak, .new, .newNEW, new-JIM, .20100910... all on
      one guy's workstation. Luckily Gitorious landed within
      months. (better than nothing)
      woodrowbarlow - 7 hours ago
      i know that some shops do nightly tape backups of the
      harddrive on the fileshare and consider that sufficient for
      version control. the theory is "developers don't have to
      learn a new tool and we will never lose more than one day's
      worth of work".these shops don't understand the benefits
      version control offers when it comes to code review and
      maintenance patches on old versions of the software, or
      vendor-specific streams for your software.
      vultour - 6 hours ago
      My friend works for a small company that doesn't use a VCS.
      They just make a new folder and copy the project into it
      every once in a while.
      daemin - 6 hours ago
      Everybody that is not a programmer (or otherwise
      IT/technical) doesn't understand version control at all. So
      as other commentators have said, their idea of version
      control is to save the file with a different name, a
      different extension, etc.I have seen it as files on a shared
      drive. I have seen it as files on a sharepoint drive. I have
      seen it as files inside of an SVN repository.
        DamonHD - 5 hours ago
        No, there's a lot of decent project managers, lawyers, etc,
        who understand something called revision control, which has
        much the same job in the real world for managing complex
        pieces of work, specs, etc...
      taoistextremist - 7 hours ago
      We SSH onto a server to do work and it seems we just make
      folders wherever for our individual projects. They do
      (nightly, I think) backups which is sort of a rudimentary
      version control. And while I'm told it exists, it  seems the
      "dev" version of their website isn't used, so they just kind
      of add in their changes live; definitely a risky environment.
      They've had a small team for a while and most of their
      applications could run relatively in isolation from others,
      so they could get away with it, but they're looking to grow
      so I'm trying to push this stuff.
        pc86 - 6 hours ago
        Yeah the "right way" to do VCS is definitely a lot of
        overhead for a team like that, but by the time you need to
        scale up (and by "up" I mean 3-6 people total who are
        committing code multiple times daily?) the business is
        likely so busy it's a HUGE uphill battle to implement
        something like that, especially since most of the people
        who let an environment like that happen will likely not be
        super familiar with Git/hg/TFS/whatever.
          rdiddly - 2 hours ago
          I dunno if I'd agree that it's a lot of overhead, for
          what you get back.  Hell I'm a one-man team right now and
          I'm using source control.  Some of my little experiments
          go horribly awry.  Some of my deletions are a bit too
          aggressive/arrogant.  Sometimes you need to diff shit.
          Version control frees me to be bold.
stygiansonic - 7 hours ago
If this is a guide for beginners, there should be (more?) warnings
not to do history rewriting operations on commits that have already
  outsidetheparty - 7 hours ago
  Seems they agree:> This site is not intended to be an exhaustive
  reference, nor is it a beginner's tutorial.
  icc97 - 7 hours ago
  If you read to the bottom:> Disclaimer: I am not, nor do I even
  remotely claim to be, an expert at git. This site is not intended
  to be an exhaustive reference, nor is it a beginner's tutorial.
  And yes, there are other ways to do these same things with more
  theoretical purity or whatever, but I've come to these steps
  through trial and error and lots of swearing and table flipping,
  and I had this crazy idea to share them with a healthy dose of
  levity and profanity. Take it or leave it as you will!
  schneidmaster - 7 hours ago
  From the disclaimer at the bottom:> This site is not intended to
  be an exhaustive reference, nor is it a beginner's tutorial.
    dkarl - 7 hours ago
    It may not be intended to be a beginner's tutorial, but it is.
    Someone who needs to be told about `git commit --amend` and
    `git diff --staged` also needs to be warned about rewriting
    history that has been shared with others.
  mahkoh - 7 hours ago
  Why is recovering from an upstream rebase considered more
  problematic than recovering from merge conflicts?
    user5994461 - 7 hours ago
    Who said anything about recovering. First we'll have to
    determine if upstream is supposed to be used in a rebase
    workflow or a merge workflow.
grawprog - 7 hours ago
My last git mistake was pretty terrifying. I decided to try and go
back to an old commit on a project on my local machine after about
a days work. Somehow I ended up making the commit I wanted to
revert to a new branch, then somehow tagged that branch with the
name of the commit making git get angry and decide that branch
wasn't valid. Then continuing in my ignorance I reset to that
branch and tried to checkout only to watch my source and resource
files vanish one by one. Deciding the commandline had caused enough
trouble I returned to a qgit window I had open, all the source
files were still there and I could at least save them one by one.
Better refresh the qgit window. Oh shit now qgit's mad at me too.
Well there goes thousands of lines of code and about 3 months worth
of work. Eventually,after reading gits cryptic error messages and a
few google searches I figured out how to remove a tag from a branch
and properly checkout an old commit. I was really happy when all
those source files reappeared.
  paultannenbaum - 7 hours ago
  Glad you figured it out! Having that much work on a single branch
  is a process smell in itself, ideally you would have found a way
  to get that code into the repo before it became that large (break
  down the work into smaller chunks, hide behind feature flags if
  needed, etc.). Beyond what you just described, reviewing that
  much work is nearly impossible to do correctly.At the very least,
  if you are going to have a long lived branch, make granular
  commits and push to a remote repo frequently. That will give you
  a distributed backup strategy.
  dsego - 6 hours ago
  Before doing anything with git that you're unsure of and could
  have dire consequences, just clone the directory beforehand. Then
  run the git commands to your heart's content.
  rootlocus - 7 hours ago
  Do yourself a favor and learn git properly. It pays of hugely in
  the long run. The book that clicked for me was Git Internals
  mynewtb - 6 hours ago
  Git is not a backup! Had you had one, you could have had your
  mind at ease.
    grawprog - 6 hours ago
    Ya I realize this now. I usually keep backups. I don't know why
    I haven't been on this project. I'm using git properly now with
    proper backups for the project. Though everything's still on
    the local machine, it's better than the setup I had. I chose to
    take it as a warning to sort that shit out.
    rootlocus - 6 hours ago
    Pushing to a remote is a backup. Gitlab offers private
    repositories for free.
      dsego - 6 hours ago
      Until you force push ;)
        ben-schaaf - 5 hours ago
        Its just as easy to delete most other backups.
        rootlocus - 5 hours ago
        And then you still have the commits, but no branch pointing
        to them. Don't worry, they're still there.
jacobsenscott - 2 hours ago
Most oh shit git moments are a result of "advanced" git users
trying to force people who just want to get shit done to "keep the
history clean" with rebases. If you stick with git push, pull, and
merge you really can't lose work. And any "advanced" git user knows
the right git log incantation to filter out merge commits and such
to make the history look clean.
ursus_bonum - 1 hours ago
I use git in this particular way, and if you do anything different
you are WRONG AND BAD or you have IMPURE MOTIVES!
donald_knuth - 7 hours ago
Nothing about detached heads?
gerbilly - 5 hours ago
On barrier to learning git is that people are understandably
reluctant to try things out because they are working in real
repositories.This site makes a game out of learning git:'s a great way to learn without
putting your real repository at risk.
  degenerate - 3 hours ago
  Thanks, I am new to git and already made some dumb mistakes with
  my real repo and had to start over. Now I'm terrified to try
  anything past pulling and pushing to master. Hopefully this helps
  me understand branching so I don't feel like I will break it all
methodin - 3 hours ago
A better tool would be a remote repo clone where you have to
resolve messed up situations and only pass if you push a fixed
solution :)
isuckatcoding - 5 hours ago
A missed opportunity to say gitting instead of getting.
erikb - 7 hours ago
I always fight for people really learning git, because that's when
it finally starts to get good. And I always tell people that git is
not the tool that everybody should use. Most people just need a
simple data storage with diff management, like Dropbox or SVN.But
even after nearly 10 years, the pressure from the aint-nobody-got-
time-for-that crowd is still there. I really, really hope that the
git devs don't feel pushed to simplify and therefore depower git.
Thinking turning VIM into the Windows text editor.
  wyuenho - 7 hours ago
  They can certainly provide much better porcelain out of the box.
  Mercurial is at least as powerful as git, but I always joked that
  the learning curve between the two is something like, you read
  the docs for 5 mins and you'll know what the next 50 commands to
  type into hg. Whereas git, you spend 50 minutes reading the Pro
  Git book, just so you know what the next 5 commands should be.
    erikb - 4 hours ago
    Sorry, but you don't know git if you think Mercurial is even
    coming close.That is not trolling btw. It's really possible not
    to know what you can do with it if you haven't learned it in
    depth.The "Git Book" is what you should read. And you read it
    once, you read it indepth, and then you're done. After that
    it's also only 5 minutes of googling, but you can do a lot
    more. At that point you can even program a simplified git if
    you want.
      wyuenho - 3 hours ago
      TBH, I've been an hg and git user for about 10 years now, I
      have only come across simple things that you'd expect to work
      in git but doesn't. For the longest time, you have to resort
      to contortions like this[1] so as to not lose commits after
      reverting a merge and then merge again.[1]:
      m/git/git/blob/master/Documentation/howto/r...What can't you
      do in Mercurial that you can in git these days?BTW, I think
      we are talking about the same book.
        erikb - 3 hours ago
        I could name a few things, like interactive rebases, but
        the main thing is not something that can really be
        explained. Have you ever significantly become strong in
        some kind of contest, may it be sports, gaming, music or
        similar? There is this situation where one day you struggle
        with something and don't see an end, and the next day it
        finally clicks, and you can do things naturally that one
        day earlier where not even imaginable.If you've experienced
        that once consciously, then you can regonize it and you
        know when you experience it you've hit someting really good
        in your life that moves you forward.Sadly it seems you must
        take that hurdle in anything until a certain age or you
        will always believe this is impossible and therefore never
        invest the energy to reach it.The thing is that this is not
        possible to achieve with any random software. For instance
        no matter how much you learn MS Word, you probably won't
        experience that. But when learning Vim or Emacs there's a
        chance you get there. Same is with git. And once you've
        achieved it once consciously, you will always want to be in
        that state in everything important you do.That's why the
        really good stuff only has a few followers, most simply
        don't get the appeal because they never would invest the
        energy to get "there" even if they knew exactly how much it
        would take. But for those who have achieved it there is no
        going back. You cannot go back from controlling (almost)
        any bit of your repository to Mercurial.But that's also why
        I think for most users something like Mercurial should be
        The VCS. Most people don't know the reward they are
        missing, so they don't feel the pain of missing it, and
        therefore have no logical reason to go through the pain of
        really learning git.
      agentgt - 3 hours ago
      > Sorry, but you don't know git if you think Mercurial is
      even coming close.And you don't know mercurial if you think
      that.Both are great and powerful and both have pros/cons.>
      The "Git Book" is what you should read. And you read it once,
      you read it indepth, and then you're done. After that it's
      also only 5 minutes of googling, but you can do a lot
      more.The problem with git on this is it is actually often
      sort of hard to find "the right" way to do things. This  is
      in large part because of the popularity of git. There is so
      much content and a good deal disparate (e.g. Stack
      Overflow).Mercurial on the other hand has far less content
      and it is maybe a little more consolidated and thus IMO
      slightly easier to find.> At that point you can even program
      a simplified git if you want..... are you sure you are not
    ksec - 6 hours ago
    I am glad hg has both Facebook and Google using it. Otherwise
    Git would have suck the air out of DVCS.
  Cthulhu_ - 7 hours ago
  I don't think git will lose features, and even if they do, git's
  core and data model is really, really good - if you look closely,
  most commands are relatively simple operations on the relatively
  simple data model and tree structure. I'd say they'll continue
  the current direction, mostly adding missing features and
  changing the defaults to be more sane (like default push
  makecheck - 3 hours ago
  Creating a sane and consistent UI for ?git? is not the same as
  limiting its power.They could have had every feature they do
  today without creating weird differences in options and
  terminology between sub-commands, and they could have set better
  defaults.There needs to be an official ?git 3? rethinking of
  options and defaults to solidify the foundation for the years to
  come and promote widespread adoption.  Anything that simply tries
  to improve ?git? as a layer on top will fail due to obscurity.
skarap - 5 hours ago
One can read any amount of similar articles, but if they don't
understand the data model behind all this, git will remain a
complex and fragile beast for them. The feature-set is huge to be
able to just remember all possible commands for all possible
scenarios. If you don't know what index is or what a branch is,
this all will look like a bunch of nonsense. On the other hand -
your ruby code won't seem too logical either if you don't know the
language.So if git is the tool you use to get your job done - don't
hesitate to spend a day or 2 on reading how it works and how you're
supposed to use it.
lwansbrough - 7 hours ago
Adopted a git GUI years ago and haven't looked back. I get looks
sometimes, but I can't help but gloat when I can stage and unstage
individual lines in less than a second.I think anyone who uses the
CLI is either trying too hard or hasn't realized the beauty of a
git GUI.Takeaways:- My commit time is usually much faster than
coworkers, with higher accuracy (less frequent accidental commits,
etc.)- I don't remember the last time I made an irreversible change
to the repo, or had an "oh shit" moment. And that's despite using
some interesting git features.- Staging individual files, folders,
lines of code, or hunks is easy. Makes maintaining multiple trains
of though / addressing bugs while working on other code a non-
issue.- It's easy to keep files uncommitted for long periods of
time intentionally, without slowing down my workflow.- It's much
easier to get an overview of the changes I'm making.
  zxy_xyz - 4 hours ago
  I use the CLI because I don't currently work on any group
  crescentfresh - 2 hours ago
  There's a git GUI??Seriously though, I'm somewhat new to git and
  any problem I come across (which are many as a new learner) are
  solved with command line options. I'm not even familiar with the
  best GUI options out there and have been trying to learn what
  seemed to be the "standard" way of git'ing.
  dlwdlw - 4 hours ago
  I wouldn't say "anyone" is trying to hard but I have seen a lot
  of people who immediately disregard guis as soon as they
  internalize that the cli is more difficult. Reasons include
  wanting to be "badass" or "smart". Yet many also do not care
  about how got differs and basically ask "how do I save" and
  proceed to revolve their entire workflow on a few copy pasted or
  memorized commands.other they hear how "rebase" is only for
  "smart" people...On the opposite side gui users can often be
  unaware of the actual model and instead be working with imperfect
  internal models with be GUI being a crutch.In both cases there is
  lack of desire to learn but I'm often more sympathetic to the
  latter where people want just enough information to do their work
  well as oppossed to the former who often make things harder than
  they have to be in all areas and have lost touch with true
  expertise in favor of appearance of expertise.
  machiaweliczny - 3 hours ago
  On mac I can recommend Gitup. It's fast and easy. Also vs code
  has quite nice git integration. I just use it for making commits
  though. Everything else is faster from CLI.
  aschampion - 6 hours ago
  > I think anyone who uses the CLI is either trying too hard or
  hasn't realized the beauty of a git GUI.Or, you know, understands
  and thinks in the semantics of the underlying tool and is already
  working in other text-based tools.
    neves - 6 hours ago
    Conflict resolution in a GUI with 3 way merge really beats out
    a command line.
    Tobba_ - 5 hours ago
    Doesn't really make the interface any less crap; though I've
    yet to see a GUI that didn't shell out to the command-line
    interface (which almost always makes them very unreliable).
      pivo - 4 hours ago
      I believe GitUp directly links to git library and doesn't use
      a command line shell.
        macrael - 1 hours ago
        Yes, GitUp actually ships its own git library.
    loup-vaillant - 6 hours ago
    A well made GUI conveys those semantics more clearly than the
    default command line interface. Automation is easier from the
    CLI, but I wouldn't be surprised if a GUI turned out to be best
    for manual interactions.(Note: I use the CLI almost
    cookiecaper - 6 hours ago
    Yeah, I would guess that the parent commenter has a heavily
    graphical workflow based out of a big honking IDE like
    IntelliJ. For people doing development in a console anyway, it
    would take more time to start a git GUI and wait for it to
    launch than to be done committing and pushing from the CLI.
      The5thElephant - 5 hours ago
      The counter argument is that if you make an error using the
      CLI, you end up spending more time fixing it than if you just
      had the GUI open and watching your repo already, and simply
      switch to it when you need to commit/push.
    The5thElephant - 5 hours ago
    Or, you know, that is irrelevant when the person using a GUI
    makes fewer errors than those who aren't (which has broadly
    been my experience as well).Even someone who perfectly
    understands git can make a typo or have a brain-fart of a day.
    A GUI significantly reduces the chances of something like that
    for all users.Sometimes dev obsession with tool purity does
    more damage than good.
      forg0t_username - 1 hours ago
      You're always one git reflog away of undoing the brainfart.
      Once you know the CLI well enough, you manipulate the git
      data model easily. When you're using a code review tool like
      gerrit, it's impossible to do something you can't undo.
  chiefalchemist - 48 minutes ago
  Which Git GUI are you using?The GUI is said to be a major leap
  forward in human conputer usage, in the context the CLI just
  strikes me as either (elitist?) jargon, or brogrammer bravado. In
  either case, not really a step forward but certain macho. I still
  don't get it.
  emeraldd - 7 hours ago
  What GUI do you recommend?  My experience has been that GUIs are
  the easiest and fastest way to make a mess that can't be
  corrected without dropping to CLI or re-cloning.  (I'm looking at
  you SourceTree). I've long recommended that everyone who uses git
  know how to use the CLI even if they don't use it regularly.
    _pmf_ - 6 hours ago
    I recommend SmartGit; it's not cheap, but it's really, really
      keithnz - 1 hours ago
      SmartGit is really nice.It's also free for hobby / open
      sourcebut worth buying for commerical work, but it is pricey,
      and I think getting the lifelong updates is the way to go.
    Achshar - 6 hours ago
    I use sourcetree and it's pretty great, especially the
    aforementioned block-level staging.
    flatline - 5 hours ago
    I personally switch between the command line, git gui and gitk.
    I haven?t yet found a suitable GUI replacement for those two.
    welly - 7 hours ago
    If you're on a mac, I can't recommend Tower enough. It's a paid
    app but well worth the money. Otherwise Git Kraken is a foss
    offering that is also excellent.
      dewey - 6 hours ago
      I want to second that. Also the integration with diff tools
      like Kaleidoscope is a nice touch. (Even though Kaleidoscope
      feels like abandonware at this point)
      machiaweliczny - 3 hours ago
      Gitup is free and probably better.
      Froyoh - 4 hours ago
      How is atlassian's Sourcetree?
        prewett - 4 hours ago
        I like it a lot, it make git as simple as mercurial.  I
        don't think it is hiding complexity, but the visual
        arrangement makes sense.  The staging area becomes actually
        useful, and I love that you can stage (or revert) pieces of
        a file, which is handy when you forgot to commit one thing
        before moving on to the next.I've only had to merge a
        branch once, and here I was completely confused on what was
        going end.  This may be SourceTree's fault or git's fault.
        Maybe my lack of understanding.I hate git, I don't
        understand git, I don't want to have to understand git, and
        I think the command line interface makes every UI error in
        the book.  But SourceTree has made me like git.
        tigershark - 2 hours ago
        Incredibly slow. I was never annoyed so much when using a
      Ajedi32 - 7 hours ago
      Git Kraken isn't FOSS. The site says "Free for non-commercial
      use", and AFAIK the source isn't available anywhere.I think
      maybe the term you're looking for is "freeware"?
      mistersquid - 6 hours ago
      I second your recommendation of Tower. About a year ago, I
      made a comment right here on HN singing Tower's praise names.
      [0]It's impossible to sing those names loudly enough.  [0]
      shagie - 6 hours ago
      Apparently, there is now also a windows version. https://www
    nwatson - 6 hours ago
    SourceTree by Atlassian ... free.
    bolololo1 - 6 hours ago
    I like GitKraken
    ggregoire - 6 hours ago
    VSCode or Github Desktop (even if the project is on Gitlab).
    filereaper - 5 hours ago
    I'd like to also point out tig. "Tig is an ncurses-based text-
    mode interface for git"It doesn't have all the bells and
    whistles of a GUI, but if you need to look at all the branches,
    and commits to a repository. tig is an excellent tool. tig
    doesn't issue any commands though, its only a browser, you'll
    still need to know the CLI. (essentially a ncurses version of
    gitk)I'm normally in a ssh session on a remote box where my
    compile & run cycles happen. tig is curses based, so no X11
    needed, filled in a really nice itch of mine.[1]
    aoeuhtns - 6 hours ago
    Magit in emacs. Probably one of the killer applications for
      karmajunkie - 6 hours ago
      +1, along with Tig (console gui).
        bradyholt - 3 hours ago
        I love tig!
        menacingly - 5 hours ago
        Thanks for telling me about tig, now I'm justified for
        having browsed HN today.It treats my "assume everything
        works like vim" habit well
          alunaryak - 5 hours ago
          tig is great -- it makes it very easy to stage individual
          lines of code (using 1) or to reset unstaged changes on a
          file (using ! in the status view).
      monsieurbanana - 6 hours ago
      I'd hesitate to call Magit a git GUI though.If we take Ranger
      for example, who calls itself the "CLI file manager", then
      Magit is rather a "git CLI".
        gumby - 6 hours ago
        >I'd hesitate to call Magit a git GUI though.Why?  It is
        designed for git and graphically displays revisions
        allowing you to pick and chose chunks of file and to revert
        individual changes.
      celeritascelery - 6 hours ago
      Agreed. Best git interface I have ever used.
    mejari - 5 hours ago
    For any Windows users out there, I use GitExtensions, which has
    served me very well over the years.
    Vel0cityX - 3 hours ago
    I use SmartGit. Way faster and more stable than SourceTree and
    GitKraken, in my experience.
    gumby - 6 hours ago
    > What GUI do you recommend?I really like Magit, which is a git
    GUI you can use without leaving Emacs.  It handles 90% of my
    git needs and is very tightly integrated into my IDE (Emacs).
    I still use some shell commands (like git mv) occasionally but
    those are simply m-! away.
      aldanor - 5 hours ago
      Second that; I'm using Spacemacs just for Magit and nothing
      else, although it's mainly vim or clion for development.
      Haven't seen a single git client that would be close to
      Magit; too sad it needs Emacs, could have potentially been an
      awesome standalone...
    kenoyer130 - 6 hours ago
    The Git GUI that ships with git is very good. It also shows how
    Git thinks (workspace/staging/commit) that most other gui's
    struggle with (they try to make it look more like a SVN
    workflow). For diffs and blame I use TortioseGit. I also
    extensively use the CLI for most branch actions.
    neves - 6 hours ago
    I tested a bunch of Git GUIs. My requisites:- Open source (and
    free) - MultiplataformThe one with the best usability was Git
    Extensions: is
    somewhat old ugly, and open a little too much of dialogs, but
    the workflow really works. It guides you to make the right
    thing.A great plus is that it already comes with Kdiff3, a
    great open source 3 way diff open source program.
      xeromal - 4 hours ago
      Agreed,  Git Extensions taught me Git visually rather than
      through a tutorial.
    LiquidFlux - 6 hours ago
    Not the OP, but I had come from SourceTree to GitKraken and
    it's a joy to use.
      yoodenvranx - 6 hours ago
      Same for me! I used SourceTree in the past but at the moment
      I am using the free version of GitKraken for private projects
      and I am very happy.
    nastysquar3d - 6 hours ago
    I use TortiseGit in my personal and work dev environments. It
    works works well. That being said, I have had to drop to CLI to
    fix things that were somewhat more hairy.
      neves - 6 hours ago
      Tortoise was great on Subversion, but I don't like it for
      Git. The UI in thought to work with a centralized version
      control is isn't well adapted to Git.
    slobotron - 6 hours ago
    Not the OP, but git cola works great for me.https://git-
  chis - 47 minutes ago
  I?m a big fan of Gitkraken. Great for doing common actions in one
  click, and graphically viewing history. It?s crazy how negatively
  people judge me for using it though. It?s like telling someone I
  prefer Microsoft Word as my IDE.
  Cthulhu_ - 7 hours ago
  I don't trust GUI clients; it's easy to not be able to discern
  the current status, easy to just commit all changes, some of the
  clients don't respect the pre-push hook, and I've seen other
  colleagues who have no clue what they're actually doing end up
  mixing pull and pull --rebase, somehow managing to make duplicate
  commits with slightly different contents and not having a clue
  what's going on.Don't use clients if you don't even understand
  the basic git workflows. And those usually don't support the
  advanced oh shit situations this article is about.
    lwansbrough - 6 hours ago
    > it's easy to not be able to discern the current
    statusProbably a failure of whatever UI you're using. I manage
    just fine.The common statement from CLI types is that "it's
    just whatever you're better at using" which is true
    conceptually, but practically, again, CLI users make more
    mistakes either from fat fingers or lack of understanding of
    git.Understanding git conceptually from a UI point of view is
    easy. You don't even have to have a full understanding of git
    to be effective at using it, if the UI is good. I'm shit with
    the git CLI, but I understand what git is doing.Yes it's easy
    to do dumb shit in a GUI, the same is true for  CLI. In fact,
    it's less likely that there'd be a button for doing something
    dumb than it is that a git novice would find some command on
    StackOverflow and attempt to use it without fully understanding
    the ramifications of it.
  foobaw - 4 hours ago
  Android Studio has a git UI built-in so it's really useful.
  rhodysurf - 7 hours ago
  For the most part using git is like five commands and it is
  definitely fast to use them from the command line if you have
  some sort of git understanding
  collinmanderson - 42 minutes ago
  Which GUI do you use?
  emodendroket - 5 hours ago
  Which do you use?  I'm generally pro-GUI (I love Postman, for
  instance, and don't use curl much) but my experience with git
  GUIs has been that they were kind of half-baked and will not do
  what I expected, leaving me with a difficult-to-understand mess
  to clean up.
  ashelmire - 5 hours ago
  Git is, imo, way too simple to require a gui. How long is it
  taking you and your coworkers to make commits? git commit -am
  "message" (or add the files you want with git add, then commit);
  git push; git pr -m "message". The longest part of that is coming
  up with a good commit message. A gui isn't going to stop people
  from making mistakes because the mistakes aren't from complexity
  of the command line, they are from committing things you
  shouldn't, which will happen regardless of whether or not you use
  a gui.
    quicklyfrozen - 5 hours ago
    For me, using a GUI makes it much less likely I'll commit the
    wrong changes as I can quickly review each staged file across
    the entire tree before committing, and also see if there are
    unstaged changes (including new files which was often the bane
    of an SVN workflow) which need to be included.I typically use
    git gui to commit changes, the cli for other operations, and
    occasionally source tree to visualize branches and compare with
    remote repos.
  swalsh - 6 hours ago
  I use the git CLI.  I do it for one reason.  I know exactly what
  i'm doing on it.  I have nothing to prove to anyone, I'm not
  trying to impress anyone with my "hacker" skillz.When I've tried
  GUI's, I'm not 100% sure what's going on under the covers.
  Sometimes they try to obfuscate things. While I'm probably not
  the worlds most advanced user, I know enough to know what I want
  to do, and how to do it.  The CLI let's me do it.  The GUI get's
  in my way.
    Tarean - 4 hours ago
    I like fugitive - it feels like cli git without having to leave
    the editor. GAdd adds the currently  file/selected lines,
    GBlame pulls up git blame information  the ability to reblame,
    GStatus show the status with the ability to jump
    to/stage/unstage files and so on.   Tried Magit for a while but
    it didn't  play nice with evil.Still hoping for a git repl that
    just does graph queries/transformations though.
    MonkeyIsNull - 6 hours ago
    > I'm not 100% sure what's going on under the covers.This. A
    thousand times over. I like to see exactly what git is doing
    and when; I don't want any magic stuff under the covers done
    for me.
      ninkendo - 6 hours ago
      GitHub's GUI is the worst. It has a "sync" button.As soon as
      I saw that button I knew I'd have trouble using it.. what
      will "sync" do?  Push my branches?  Pull tracking branches?
      Will merge commits get implicitly created?  Or will it just
      fetch?  From what servers?  I didn't want to risk having my
      local master get pushed into production just because GH wants
      to make things easy for me, so I just quit it and went back
      to the CLI.
        emodendroket - 5 hours ago
        It just pushes the current branch afaik.
          dotancohen - 2 hours ago
          So they should just call it 'push'. The word 'sync' is
          not in the Git terminology.
          michaelmior - 5 hours ago
          So it never pulls updates on the remote? That seems like
          pretty unexpected behaviour.
          emodendroket - 5 hours ago
          It pulls and then pushes, I guess I should say, but I was
          considering "pulls and..." part of the push operation.
        mchahn - 4 hours ago
        GitHub's Atom editor recently added git operations.  I use
        Atom but haven't had the time to try the git wrapping.  Has
        anyone else used it?
      giancarlostoro - 4 hours ago
      Even GUI based SQL tools show you a log of commands used...
      Git GUI clients don't even show you beforehand or after what
      the heck just happened... Sad.
        tigershark - 3 hours ago
        It's definitely not true. I'm not sure what kind of gui did
        you use but both sourcetree and gitextensions show you the
        command log.
      pacoverdi - 6 hours ago
      CLI and GUI are both user interfaces and magic is in the eye
      of the beholder: if you know your tools, you can predict what
      will happen under the hood when you click on a button as much
      as when you submit a command (it's not magic
      anymore).Personally, I use the CLI and often have no idea
      what I'm doing ;)
    thelittleone - 39 minutes ago
    How about if someone made a GUI with a console at the bottom
    that showed the commands being executed along with results?
      mikedelfino - 6 minutes ago
      I like typing and I don't think it slows me down too much, so
      I pass. But it's a good idea.
    STRiDEX - 6 hours ago
    I use sourcetree, but I would like a console feature that shows
    me what commands its running. Similar to sequel pro's "console"
    feature shows the raw sql being run.
      ccarse - 5 hours ago
      There's an option in sourcetree, "always show output". This
      will keep the window that runs the commands open so you can
      always see what it did and git's output. I always keep this
      dilap - 5 hours ago
      the commands themselves are not actually the lowest level,
      though! (and in fact, are kind of crazily mixed togther; most
      of the trouble people have w/ git is bad UX for the cli,
        Drdrdrq - 55 minutes ago
        True. Inconsistent and unintuitive options, oddly named
        commands (and this is coming from someone who enjoys using
        Unix clones).
    nerdponx - 3 hours ago
    You might want to try Sourcetree if you haven't already. I felt
    the same way about Git GUIs for a long time, but Sourcetree
    actually does a good job of getting out of my way, and has a
    very nice commit history tree viewer to boot.
      andrepd - 3 hours ago
      Not available for Linux, which is a damn shame.
      Someone - 1 hours ago
      I dislike SourceTree precisely because it uses git
      terminology. Git?s terminology is bad enough, but it
      completely breaks down for me in a GUI, because I expect that
      GUI?s conventions there. For example, on the Mac (as in
      English, I think), a command named ?Remove? removes an item
      from a containing item. ?Delete? also destroys the item.
      SourceTree, however, uses ?Remove? for ?git rm? because Unix
      thinks ?remove? destroys items.To make matters worse, what in
      a Mac GUI would be called ?Revert? or ?Discard Changes? is
      called ?Discard?, something that, to me, feels more
      destructive than it is.End effect? We have ?Discard? being
      less destructive than ?Remove?, while, to me, it feels the
      other way around.(I may remember this wrong, but if I do, I
      think that?s a sign of the problem of not following platform
      conventions in your software)
      sirmarksalot - 3 hours ago
      I've found Sourcetree to be way too slow. My team is
      currently using the GitFlow model, for various reasons, and
      that involves switching between branches fairly regularly. It
      also means that any commit to master involves a lot of steps.
      From the command line, this isn't a big deal because each of
      those steps takes a half second or so, but Sourcetree
      multiplies that by an order of magnitude, and the Sourcetree
      users are nearing a point of mutiny.
        tigershark - 3 hours ago
        Source tree is the slowest software that I ever used. Git
        extensions is much much faster and I never had any
        performance problem with it.
      rsp1984 - 3 hours ago
      Actually I find Sourcetree one of the worst git GUIs out
      there. There are just so many bugs and kinks and glitches in
      it that I avoid it if possible.I do like the Gitx-dev fork by
      Rowanj [1]. Clean and simple. Unfortunately just for Mac OS
        nerdponx - 1 hours ago
        I haven't encountered any of these bugs. But I do use it
        only rarely, the CLI is where I live most of the time. Good
        to know about alternatives.
    WhyNotHugo - 1 hours ago
    Same here. Regrettably, if you UNDERSTAND git, a GUI won't work
    for you. If you're interested in understanding it, it won't
    work for you either.A GUI works fine if you want to get things
    done. If you like to know what goes on under the hood, it's
    just confuse you.
      electricEmu - 9 minutes ago
      I understand git quite well and use a GUI. I was interested
      in understanding it while using the git.It's pretty sweet
      that GitExtensions displays the exact command executed.
      Actually, it made learning vastly easier for the people I
      taught after myself.Some people do better with GUIs; others
      the CLI.
    aldanor - 5 hours ago
    There are GUIs that are very close to CLI that don't try to
    reinvent a wheel and instead just map directly to what git
    does.The best one, I think, being Magit for Emacs (if you can
    call that a 'GUI' given you can run it in the terminal).If you
    get used to commit things by-line instead of by-file (which is
    generally highly recommended with git), and also clean up your
    history/squash things a lot, using git cli gets VERY tedious
    very fast; I'd rather do it in several keypresses because why
      dilap - 5 hours ago
      Sort of off-topic, but magit isn't really  GUI :-) -- though
      it is very nice, if you're an emacs user. It's Achilles' heel
      is speed, though -- too damn slow. (Last time I tried it,
      anyway, which was a while ago.)
        aldanor - 5 hours ago
        Well. That depends :) I don't develop in Emacs and use it
        solely for hosting Magit, in a separate window. So it's
        kind of a GUI I guess; more so than a CLI anyway.> It's
        Achilles' heel is speed, though -- too damn slow. (Last
        time I tried it, anyway, which was a while ago.)Don't
        remember a single of case of it feeling too slow in the
        last few years, whether on linux/mac... (maybe it just got
        better over time though)
          dilap - 5 hours ago
          interesting. i'm on mac; i'll have to give it another
          try. also we might just have different ideas of "too
          slow"; for common operations, anything more than instant
          is basically too slow. :-)
          tarsius - 5 hours ago
          On macOS it helps to use Emacs 26.1 (unreleased but very
          solid) or to use a build with a backport of the vfork
          patch. For more information see

          also plan to make Magit faster across all platforms.
          dilap - 5 hours ago
          very cool to hear that performance is a focus area!
        JetSetWilly - 5 hours ago
        It seems to be incredibly slow on windows, but fine on
        linux.It seems like the sort of ui that needs to be near-
        instant in order to be usable, the premise being you can
        tap the various shortcuts to assemble a command very
        rapidly. But on windows this is an exercise in frustration
        because each command takes at least a second or two at best
        to execute and often much longer.
        tarsius - 5 hours ago
        I think Magit could be classified as a TUI [1].But that
        still doesn't help explain its benefits to someone who
        hasn't tried it. For the crowdfunding campaign that I ran
        earlier this year I wrote a few articles. For those
        unfamiliar with Magit I would recommend [2] and the more
        visual [3].[1]
        based_user_interface [2]
        /the-magical-git-interface/#st... [3]
        thomastjeffery - 2 hours ago
        It's a Graphical User Interface.I think that the
        distinction that makes a Commnad Line Interface is the
        REPL.I consider anything with a non-linear UI that you can
        see a GUI.
    dilap - 5 hours ago
    It's not anything inherent to a visual UI though, it's just
    that most of the UIs that exist are trying to put their own
    model on top of git, rather than embracing git's model.The one
    exception to this I've found is GitUp (mac only, sadly), and
    it's excellent. It's whole model is, "what operations can I
    perform on this graph," which is exactly the model git has.
    It's great.
      giancarlostoro - 4 hours ago
      SourceTree keeps the same language regular git uses. But I
      highly agree. JetBrains IDEs add their own lingo out of
      support for multiple version control plugins I'm sure but its
      confusing and easy to screw up. SourceTree is the one GUI
      client I want on Linux...
        ythn - 1 hours ago
        VSCode is the only Git GUI that you need and it's available
        on Linux
          Drdrdrq - 1 hours ago
          Do you use it? I have it enabled, but when I tried to
          revert a few lines (which should be the simplest
          operation ever - NetBeans did it perfectly; may it rest
          in peace...) I got some horrific message that made me
          doubt what the operation will do. So I haven't gathered
          enough courage to try committing anything... With CLI at
          least I know what I did wrong.
      dasil003 - 5 hours ago
      I think you've put your finger on the schism of why so many
      git users prefer a GUI.  The built-in porcelain is stupidly
      inconsistent and confusing.  And yet, git's underlying model
      is so simple and powerful that I think it's worth suffering
      the bad CLI just to be more fluent and able to utilize git's
      power fully.  The model itself is very easy to grok, it just
      takes some time to memorize the various random incantations
      and occasionally look something up, but I don't consider that
      a big deal for a core tool I use every day.
        chiefalchemist - 45 minutes ago
        It might not feelblike that big of a deal, but certainly
        there has got to be on any given day far more important
        things you can use those brain cycles for, yes? Low
        friction or not it's still friction. Friction that can be
        removed. Yet so many refuse to do so. There's something
        wrong with this this-is-how-we've-always-do-it picture.
        mikedelfino - 10 minutes ago
        One could also setup aliases for some of the incantations.
        I personally have `git uncommit` aliased to the proper
        command line that I never remember.
  dozzie - 4 hours ago
  > I think anyone who uses the CLI is either trying too hard or
  hasn't realized the beauty of a git GUI.Or just couldn't be
  bothered with leaving terminal. I refuse to reach for mouse for
  any repository operation when everything else I do from console.
  kendallpark - 2 hours ago
  I use a git GUI for staging commits, but the CLI + text editor
  for everything else (and no aliases). The CLI is universal--I can
  go to another dev's computer and get them out of rebase hell
  without learning their particular git GUI interface. Knowing the
  CLI by heart is also useful if you ever have to use git server
  side through SSH. I have found that the CLI fits into my workflow
  better than the GUI for everything except staging.
  Balero - 5 hours ago
  Additionally you can always use the command line if you need to.
  I use a GUI for 99% of what I do, then use the CLI for what I
  need it for.
  qaq - 1 hours ago
  Which git GUI are you using?
  lillesvin - 7 hours ago
  My biggest issue with a GUI is that most that I've seen introduce
  new terms for various stuff, e.g. "sync" in VS Code, or "revert
  commit" (in Source Tree maybe?) ? there's no Git command called
  "sync" or "revert", so I'm not immediately sure what they do.In a
  CLI I know exactly what's happening.That's just my opinion
  though. If people feel comfortable working in a GUI all the more
  power to them.
    Alupis - 6 hours ago
    >  no Git command called ... "revert"Maybe not in the way
    Source Tree uses it, but there certainly is[1]! I've had to use
    it a few times.> git-revert - Revert some existing commits[1]
      lillesvin - 4 hours ago
      My bad, then it was "reverse" in Source Tree (or whatever it
    autarch - 6 hours ago
    Git does have a revert command.
      lillesvin - 4 hours ago
      Yeah, my bad. Must've been "reverse" then. I just remember
      the revert/reverse dichotomy.
    bootcampjs - 6 hours ago
    I work with a lot of people who have no idea how git actually
    works and it is infuriating. They all use the git desktop
    program, and almost every time I get called over to help, it?s
    because they didn?t sync or refresh or whatever the hell it
    does.If you don?t have a good mental model for git, you?re
    gonna have a bad time.
      lhabjane - 5 hours ago
      Second this. I was one of those people that needed help when
      I was learning git. Went full CLI after that and never looked
    joonoro - 6 hours ago
    I like Magit because it doesn't try to hide git while still
    giving all the advantages GP mentioned
  mmmpop - 7 hours ago
  > I think anyone who uses the CLI is either trying too hardWhy do
  you think it's okay to share this opinion?
    Angostura - 6 hours ago
    What makes you think it is not?
      Gracana - 6 hours ago
      Because it's rude and antagonistic and it compels a lot of
      people to post to defend themselves. It's classic trolling.
      mmmpop - 3 hours ago
      It's not constructive, who cares what you think about CLI
      users? The fact I'm being downvoted says a lot about the
      state of this forum.
        falsedan - 2 hours ago
        Your comment was also trolling: I would have avoided the
        leading question and just commented on the probable
        negative interpretation the some CLI users might make of
        the comment.
    ksk - 2 hours ago
    The problem of course is the question - What gives anyone a
    right to do anything? What gives you the right to police the
    comments? What gives me the right to question your questioning?
    Meta-discussions always get sidetracked..
    lwansbrough - 6 hours ago
    Because this is a forum and nothing I say matters.
  sigi45 - 6 hours ago
  I work very well on a cli. I can do partial adds faster than you
  and don't had any 'oh shit' moments for a few years.I do not care
  if someone is using a gui.My takeaway: - If i can use git on an
  cli, i can use git on any server with an cli. I do need this for
  when i use git on my ansible maschine or on my home media server
  or when doing something with build infrastructure (jenkins -> git
  -> cli)
  rectangletangle - 1 hours ago
  I've tried out a few different GIT GUIs, and never really took to
  any of them. Settled for using the CLI + many BASH aliases.
  Anything I do frequently gets a concise alias to minimize typing.
  I have relatively short fingers, and I'm admittedly a pretty poor
  typist, so I really emphasize the concise part. Pretty much all
  the aliases are write only code. I do this for pretty much every
  other complex CLI application too, e.g., Docker, Heroku, AWS. A
  little abstraction really speeds up using the CLI. Aliases are my
  favorite feature of BASH, I think they've saved me literally
  months of typing at this point in my life.Here's a few handy
  ones:  alias currentbranch='git rev-parse --abbrev-ref HEAD'
  alias gpush='git push origin $(currentbranch)'   alias gsync='git
  pull origin $(currentbranch)'    alias ga='git add -A'   alias
  gc='git checkout'   alias gcm='git commit -m'   alias gca='git
  commit --amend'    # and my personal favorite (list recent
  branches)   alias gb='git for-each-ref --sort=-committerdate
  refs/heads/ --format="%(HEAD)
  %(color:yellow)%(refname:short)%(color:reset)" | head -n 20'
    tylerhou - 1 hours ago
    My version of gsync is `git pull --rebase origin
    ${currentbranch}`, since I hate having random merge commits.
  minitech - 5 hours ago
  > I think anyone who uses the CLI is either trying too hard or
  hasn't realized the beauty of a git GUI.Nah, it?s just a lot
  easier than you make it out to be. GUIs are fine too, but if you
  read the documentation and don?t just memorize a fixed set of
  commands there?s nothing dangerous, slow, or inconvenient in
  going about a standard workflow using the CLI.And yes, lots of
  people don?t have time for this. Totally okay. Don?t generalize
  to ?anyone who uses the CLI is trying too hard?.
  drdrey - 27 minutes ago
  It doesn't have to be an exclusive or. I use the CLI for most
  things, but a GUI when it makes sense (like you mentioned,
  staging specific hunks). I find that for the most part, my CLI
  workflow is so straightforward I rarely get in an "oh shit"
  moment: git pull, git co -b featurebranch, a series of git ci
  -av, and a git push to open a pull request.
  marssaxman - 3 hours ago
  Past experience with GUI frontends and other sorts of simplifying
  interfaces for version control tools has left me extremely
  reluctant to use anything more than git's out-of-the-box command
  line, despite its execrably wretched, unlearnable inconsistency.
  When things don't make sense with git, I can at least compare
  notes with coworkers, or search the web and find many discussions
  where other people have been similarly confused, and received
  useful advice. If I'm using some custom frontend interface, on
  the other hand, there are inevitably going to be situations it
  doesn't handle where I have to fall back to the command line,
  which I won't remember anything about because I will not have
  been using it, nobody else on my team is likely to be familiar
  with the tools I'm using, and discussions on the web are likely
  to be scarce. Better to just absorb the ongoing pain of git's
  terrible interface for day-to-day tasks so that I'm not
  completely hosed when things inevitably go wrong.
  chuckdries - 3 hours ago
  Seconded for a GUI. I've been using gitkraken for almost a year
  now, never looked back.(full disclosure: as of last week I
  actually work for the company behind gitkraken but I started
  using it far before I realized they were local)
  Pxtl - 6 hours ago
  I use both - to me the big advantage of getting used to GIT CLI
  is that you learn the tools to handle uncommon operations and
  automate tasks, which the GUI doesn't give you.  When you need to
  start piping stuff through grep, for example.
    cytzol - 5 hours ago
    GUI user here. Genuine question: when would you need to pipe
    stuff through grep? I get it would be a rare situation, but I
    can't think of one.
      Pxtl - 5 hours ago
      We have a naming convention that feature branches are named
      "feature-[descriptionOfFeature]" here and I wanted to bulk-
      delete all the merged feature branches that developers had
      left dangling, without killing the release branches and the
      like.  Grepping helped there.Like I said, super-rare
  rcxdude - 6 hours ago
  I've felt a good GUI would make using git far more intuitive, but
  I've yet to find a good one. They all seem to fail on one front
  or another (too hard to use, don't expose enough functionality,
  attempt to enforce one workflow, aren't available on platforms I
  want, are slow/resource hogs).Usually I use the included gitk to
  view the repo, and the CLI to manipulate it.
  lambda - 3 hours ago
  I'd consider myself an expert on Git, and I use a GUI of sorts
  for the vast majority of my Git work: Magit in Emacs.It has many
  of the advantages that you describe; makes it easier to get an
  overview of what's going on, makes it easier to stage individual
  files, folder, lines of code, hunks, etc.There are a couple of
  cases in which I need to fall back to the Git command line, but
  it's not very often, and I do find it substantially improves my
  B_612 - 5 hours ago
  The Git UI that comes with intelij can do all the essentials git
  statements and has a console that logs everything it is doing.And
  you can also learn useful things by reading the console
  sometimes. There is no magic.
  madeofpalk - 6 hours ago
  I've found my sweet spot is using both a GUI (Github app, to be
  specific) and a CLI.GUI for partial commits and reviewing my
  change, and then command line for basically everything else
  (merge, checkout, branch, etc).
  nlawalker - 4 hours ago
  I've become a big fan of Git Extensions. I like that it doesn't
  try to layer its own agenda over the Git workflow, shows all the
  console input/output it uses, and warns me when I'm about to do
  something stupid, but overall I like it for the same 3 reasons
  that I like most GUIs:- It's a live dashboard. A GUI gives me
  live, persistent information organized well on the screen. I
  appreciate the power of the CLI for accomplishing tasks, but I've
  never understood how people prefer it when it comes to simply
  viewing and understanding the state of something. I don't see why
  I'd want to run a bunch of commands to see stuff scroll by in my
  format-constrained terminal when I can have a live, all-up view
  of multiple aspects of a repo all at once, with relevant,
  context-sensitive commands on whatever I click on.- It's
  discoverable. Most of what I've learned about git has been
  through clicking around in Git Extensions.- The structure and
  organization of the UI helps me to understand how git operates.
  When I open the "Pull" dialog, for example, the way the controls
  in the UI are grouped and the kinds of controls that are used
  help me logically understand what "Pull" can do.
  TomK32 - 2 hours ago
  I always do `git add --patch`, it's very precise and I can edit
  lines before staging them. I really don't see why someone would
  work without it (or a GUI).
  CruiseDevice - 6 hours ago
  I don't know how much difference does it make using gui or cli.
  When i was interviwed for my first job i was asked questions on
  git. And they asked if i use gui or cli.I think they wanted to
  know if i really know how to use git through cli. I never used
  gui for git, maybe i will use in the future. I think Ohsitgit is
  a good resource which i was trying to find on internet for so
  repsak - 4 hours ago
  I use for interactive staging and
  git CLI for everything else. Best of both worlds and I don't have
  to leave the terminal.
    aglionby - 3 hours ago
    +1, not having to use a mouse is great. I also use zsh's
    inbuilt git aliases [0] which I can't recommend enough -- I've
    found using git CLI without them a pain now that I'm used to
    them. These together have me productive and happy.[0]
  pkamb - 2 hours ago
  In addition to better staging and committing, I love my git GUI
  for allowing me to easily see and work with every past
  commit.Right click on any commit and I can create a new branch
  there, copy the SHA, do a mixed reset to that location, rebase on
  it, etc. SO much easier to visualize the actual tree of commits
  you're working with.I'm sure some people do do all that from the
  command line. But every CLI coworker of mine has really only
  known the basics of branching and committing. The GUI unlocks the
  repo and all of its branches and commits as something you can
  play with and explore.
  dasil003 - 6 hours ago
  You're entitled to your own opinion of course, but you
  underestimate the efficiency of the command line, especially when
  you already have one open for other development tasks.I use one
  or more GUIs for visualizing branches, and old branch cleanup,
  and yes, committing single lines from hunks that can't be
  split.However for everything else CLI is fairly close to optimal,
  including interactive adding/rebasing, and don't want to use
  whatever shitty editor your tool has in it, I want to use vim
  with syntax highlighting so I can properly format my commit
  messages.  Even something as simple as viewing a full commit is
  faster in the CLI because you can just pipe it to less or send it
  to an editor versus whatever tradeoffs a GUI has to make to stay
  performant, make use of screen space, etc.One last tool is
  Fugitive.  This blows away anything else I've ever seen for
  interactively traversing history at the line level.
    reificator - 6 hours ago
    > committing single lines from hunks that can't be split.Could
    you elaborate here?  Personally I've always been able to commit
    just the pieces I need via `git add -p`.  Never had problems
    staging a single line before.Since this is text I should say:
    I'm not doubting you, I just like to know the limitations of
    the tools I'm using.
      theptip - 5 hours ago
      `git add -p` adds by the hunk, which is a unit of
      quantization bigger than a line.E.g. if you have two
      consecutive lines changed, it's not possible to split them,
      they are one "hunk".(Waiting for someone to chime in with how
      to split a hunk and change my life).
        YoyoyoPCP - 5 hours ago
        You use the 'e' option which allows you to edit the hunk.
        Remove the minus sign or the entire line with a '+'
        lfrb - 5 hours ago
        You can use 's' to split a hunk but it would indeed not
        work if you want to split two consecutive lines.You can
        also use 'e' option to edit the hunk to e.g. remove one of
        the added line.Nothing as easy as clicking a line in a GUI
        deragent - 5 hours ago
        Within 'git add -p' when you get to the hunk that you want
        to edit (split down to single lines), press 'e'. This will
        open an editor (vim in my case) which lets you edit the
        diff manually.In there you can remove added lines (prefixed
        by '+') by removing them, and re-adding removed lines
        (prefixed by '-') by replacing the '-' with a space ' '.
          tigershark - 3 hours ago
          And how is this faster/better than selecting a line with
          the mouse and pressing s without opening any other
          RandomException - 2 hours ago
          Do it in Vim (or emacs for those weirdos out there) and
          you're done before you would've even reached the mouse :)
      dasil003 - 5 hours ago
      Say you have 3 sequential lines, but you only want to stage
      the middle one.  You can?t split it into smaller hunks by
      hitting ?s? during ?git add -p?.  I?m sure there?s a way I?m
      just not familiar with but I just use Sourcetree for this on
      the rare occasion it occurs.
        klmr - 5 hours ago
        You can split hunks manually by editing (hit ?e? instead of
        ?s? during staging). I end up doing this fairly regularly.
    PuffinBlue - 6 hours ago
    > One last tool is Fugitive. This blows away anything else I've
    ever seen for interactively traversing history at the line
    level.Sorry if I'm being think, but how do you do that? Are you
    talking about Gblame?
      dasil003 - 5 hours ago
      Yes, Gblame then in the blame pane ?o? to open the commit,
      then in the commit pane navigate to a file name and ?o? to
      open the old file, then rinse and repeat.  You can trace line
      history across files this way.
    DigitalJack - 2 hours ago
      > Fugitive  That's interesting.  I switched back from emacs
    to vim (neovim), and fugitive was recommended.  it just looked
    like :commands for the normal git cli...  maybe I missed
    something.So even though I edit in vim, I jump back to emacs
    for magit for bigger commits or multiple smaller commits (where
    I need to see diffs to be sure I capture my changes).I have
    desired something as useful in vim, but I didn't think there
    was anything.  I'll take another look at fugitive.
      DigitalJack - 2 hours ago
      Yeah, fugitive seems pointless to me.  Might as well just use
      the git cli...which I do, but when I want something quicker
      to navigate/visualize, magit is my go to.
sirmarksalot - 1 hours ago
The absolute worst situation I've gotten into was just the other
day, when my team managed to check in two files with the same name,
but different capitalization. The server (Bitbucket) is Linux-
based, but all the workstations are Mac or PC, so the names
collided on everyone's desktops. This prevented anyone from pulling
or checking out a different branch, so even after master was fixed,
everyone's environment stayed broken until someone figured out the
right magic incantation (git rm --cached).
  yes_or_gnome - 1 hours ago
  Not really an issue with git, but with OSX. In doing some
  research of git, I wanted to look at the first git repos. Those
  are torvalds/git.git and torvalds/linux.git. If you clone
  linux.git on OSX and run `git status`, you'll see this:    $ git
  status --short     ## master...origin/master     M
  include/uapi/linux/netfilter/xt_connmark.h     M
  include/uapi/linux/netfilter/xt_dscp.h     M
  include/uapi/linux/netfilter/xt_mark.h     M
  include/uapi/linux/netfilter/xt_rateest.h     M
  include/uapi/linux/netfilter/xt_tcpmss.h     M
  include/uapi/linux/netfilter_ipv4/ipt_ecn.h     M
  include/uapi/linux/netfilter_ipv4/ipt_ttl.h     M
  include/uapi/linux/netfilter_ipv6/ip6t_hl.h     M
  net/netfilter/xt_dscp.c     M net/netfilter/xt_hl.c     M
  net/netfilter/xt_rateest.c     M net/netfilter/xt_tcpmss.c
baristaGeek - 5 hours ago
Thank you so much! These are pretty useful tricks. Just a question:
What's the difference between reflog and using git log to later
checkout to a given commit?
  rootlocus - 4 hours ago
  You almost never checkout to a commit. You checkout to a branch.
  A branch is a reference to a commit, and the HEAD is a reference
  to a branch. The HEAD is where you are right now. When you make
  the HEAD point to a specific commit, you're in a 'detached head'
  state.`git log` tells you all the commits that are part of the
  branch. More generally, they are the commits who are children of
  the current commit (the commit your branch points to).`git
  reflog` tells you where your HEAD has been. When you change for
  branch to branch, the HEAD moves around. That history is recorded
  in the reflog. If you botch a rebase, your HEAD will sit on top
  of the newly created (and botched) commits. You can still access
  your previous commit by looking where the HEAD was before moving
  to the new commits made by the rebase.
zellyn - 7 hours ago
Is it just me or did
forget to checkout master before calling reset?
  throwanem - 7 hours ago
  Creating a branch doesn't check it out by default. To do both at
  once, it's either "checkout -b" or "branch -c", I forget which
  because it's "b c" in Magit.
    zellyn - 7 hours ago
    Ah, I figured I was missing something.
  XaspR8d - 7 hours ago
  It's still on master because `git branch` just creates and
  doesn't do checkout.(Which is why I've almost exclusively
  switched to `git checkout -b ` for creating. How often
  do I want to create but not switch to the branch?)
    gboudrias - 7 hours ago
    Apparently the default behavior is for people who just like to
    know it's there ;)
    mkesper - 6 hours ago
    Git branch is helpful if you just want to make a snapshot
    before doing something potentially harmful. If you hose up,
    just checkout that branch again.
magoon - 2 hours ago
Pro tip: -pInteractive staging, eg git add -p or git checkout
-pYou?ll be asked, for each change, if you want to stage it. This
helps tremendously in preventing commits with stray marks, console
logs, etc.  Try it!
dkns - 7 hours ago
> Oh shit, I accidentally committed to the wrong branch!I find
cherry-picking to be easier in this case. Just checkout the branch
and cherry pick commits from 'wrong' branch.https://git-
  yes_or_gnome - 44 minutes ago
  I don't see how that's easier. There's `git checkout -b my-new-
  branch` which is even easier than the originally proposed
  solution. Followed by `git checkout master && git reset --hard
  @{u}` or, if you don't want to switch between branches, `git
  branch -f master master@{u}`.
  mtrpcic - 7 hours ago
  But then those commits are still in the wrong branch. If I
  accidentally commit something to master instead of a development
  branch, I can't deploy master until my development branch is
  merged in, as the one commit isn't ready for live.
    Cthulhu_ - 7 hours ago
    That's where tools like github and gitlab come in (or a pre-
    receive hook on the server), which can deny all commits to
    master. If that's something you want to prevent of course - and
    tbf, as soon as there's more than one or two people working on
    a project, I'd lock master down.
    mseebach - 7 hours ago
    If you haven't pushed, it's as easy as resetting the branch to
    the last good commit. If you have pushed, well, it's the same,
    then push -f, and then making sure that all your teammates pull
    the fixed branch. If that's a situation you regularly find
    yourself in, protecting master from direct pushes and only
    doing PRs is a good solution (GitHub, BitBucket and GitLab all
    have tooling for this).
      dkns - 6 hours ago
      Maybe it's just me but I feel like if you work with multiple
      developers you should never, ever force push master. I'm wary
      of force pushing branches in general, unless that's a branch
      that only I work on.
        mseebach - 6 hours ago
        It's not ideal, at all -- and if someone else has pushed in
        the meantime, they risk losing the commit. But if you're in
        a situation where doing this would be a significant
        problem, you should probably not be pushing directly to
        master in the first place, instead relying on a PR
          sigjuice - 3 hours ago
          Why not simply push a second commit that reverts the
          broken commit?  This will avoid rewriting history and
          messing up the rest of your team.
  nemetroid - 57 minutes ago
  I agree that the proposed solution is not the best. If you can
  fix your problem without dirtying the working tree (i.e. by
  simply moving changesets around), that's almost always a nicer
  way to do it.
cjsuk - 7 hours ago
I admit to using this at least once a week.
k_bx - 2 hours ago
> Fuck this noise, I give up.PLEASE add a note to check if you have
anything interesting in stashes/branches before doing the rm -rf,
I've lost some work so many times because of the "fuck this noise"