7 ms·

GitTips

166 points by gkst 10y ago

devy 10y ago
I wonder why this page doesn't have one of the most frequently asked and rated question: "How to undo last commits in Git". It's rated 11k times so far. [1] http://stackoverflow.com/questions/927358/how-to-undo-last-commits-in-git http://stackoverflow.com/questions/927358/how-to-undo-last-c...
- dozzie 10y ago
  The reply should be "if you didn't find it in documentation by now, you probably aren't qualified enough to use it".
  - pjc50 10y ago
    Few people are really qualified to use it. Most are required to use it and not given the required weeks of training.
    - dozzie 10y ago
      That's a shame it takes them weeks to read three quite comprehensible man pages to think up two different ways of changing commit history. How did we actually get to the point where it takes weeks of training to use git, when I remember learning how to use it in a day or two, ten years ago (when it was much less usable and documented), and for a (far from trivial) use case of being a helper tool for off-line work with Subversion?
      - squeaky-clean 10y ago
        And even if it does take someone a month to learn Git, is that not worth it? You'll be using it pretty much every day for a decade, if not longer.
        convolvatron 10y ago
        the desire would be to have a system which let you get started relatively quickly, and learn it more in depth as you have need to. git really doesn't work this way because unless you manage your branching and merging in a sympathetic way (to both git and your peers), you can get very thoroughly punished.
      - angry-hacker 10y ago
        Probably because you have 10 years of experience? Git is a mess, but popular tool and many peopled are forced to use it instead of some sane system.
        dozzie 10y ago
        > Probably because you have 10 years of experience? I was learning git a decade ago, and all it took was at most two days of reading. And yes, this includes the idea on how to rewrite commit history (actually another one, very low-level; I don't expect anybody to ever think of this way for the task). I didn't have StackOverflow or plethora of tutorials on web that are present today. > Git is a mess I keep hearing that, but once upon a time (seven? years ago) I tried learning Mercurial, this paragon of usability, and I couldn't figure out one of the simpler things: how to setup a repository to merge changes from two other repositories without specifying full paths. Given that, either I'm very smart, because I picked up git so quickly, but so-praised Mercurial "is a mess", or I'm very stupid, because I couldn't figure so simple Mercurial function, but then what does it say about people who can't read the fsckin' git docs?
  - blakeyrat 10y ago
    Do you think if I had a choice, I would have chosen Git? Ugh. No, I'm forced to use it as a condition of employment. You're right: I'm not qualified to use it, I disqualify myself with the rule "only use software that at least pretends to be usable", but that doesn't mean I have a choice in the matter.
    - dozzie 10y ago
      > Do you think if I had a choice, I would have chosen Git? Ugh. > No, I'm forced to use it as a condition of employment. And you deem it a valid reason to avoid learning the tool you use? O_o
      - blakeyrat 10y ago
        I don't want to be able to think the same way people who think Git is a great tool think. If that makes sense. If I get brainwashed into thinking Git is well-designed or good in any way, I'm afraid I'll completely lose my ability to design quality user interfaces.
        dozzie 10y ago
        Git with its interface may be rough, but this is merely a superficial trait. The same category as saying that Erlang is fugly because its syntax derives from Prolog. Who cares? It's mechanics and semantics, respectively, that matter. I can whack git repository with a hammer and achieve good, reliable results this way (and I already needed it several times in weird scenarios; I wouldn't get far with Hg under the same circumstances). Pretty much the same case as with Linux OS: all the internals are easily accessible, and user interface is just good enough for me to use.
        blakeyrat 10y ago
        > Who cares? I care. I want to build software normal human beings can actually use. Git is not that. Learning more about Git is me going in the wrong direction entirely. I don't want to go in the wrong direction, I want to go in the right direction.
K0nserv 10y ago
My number one git tip for day to day use rather than specific scenarios is setting up aliases for everything. Along with the ones provided by the git oh-my-zh plugin I have these[0]. Some examples + gco - git checkout + ga - git add + gc - git commit + gp - git push + gl - git pull + gpc - Pushes current branch to origin + gpcfl - Force pushes the current branch to origin using --force-with-lease + glc - Pulls curent branch from origin This is my favourite though function goops { git add -A "$@" && git commit --amend --no-edit && gpcfl } Used like this `goops file`, it adds the file, amends the last commits and force pushes the branch. Super useful because I tend to realise I forgot something just after I push. Don't do this on shared branches though, force pushing should only happen to branches were you are the only one working on the branch or in coordination with anyone else working on the branch. 0: https://github.com/k0nserv/dotfiles/blob/master/files/zshrc.symlink#L14-L20 https://github.com/k0nserv/dotfiles/blob/master/files/zshrc....
- vog 10y ago
  > ... `goops file`, it adds the file, amends the last commits and force pushes the branch Note that you should only ever do this if you are absolutely sure that you are the only person pushing to that branch. You should consider using "--force-with-lease" instead of "--force". Otherwise you'll sooner or later overwrite a coworker's push without a trace. Maybe they'll notice know Git good enough to fix this, but it would still be very, very annoying. EDIT: Changed "repository" to "branch", mention "--force-with-lease".
  - K0nserv 10y ago
    Definitely, don't force push unless you know what you are doing and the implications of force pushing. On the other hand don't blindly listen to people who tell you that force pushing is bad and should always be avoided
  - meestaahjoshee 10y ago
    You can use --force-with-lease
    - 10y ago
deleted 10y ago
[deleted]
atemerev 10y ago
Hacks upon hacks upon hacks. On the inside, Git is a thing of beauty, marvel of engineering. On the outside, it is a mess of inconsistent command line options, terrible documentation, and snobbish community that thinks everything of this is fine and small surface details are irrelevant as long as the core works exactly as advertised. They probably also work in Emacs with default keymap.
- arunc 10y ago
  That's what I felt too. I started using mercurial and I never looked back at git. Mercurial CLI is a pleasure to work with.
  - randomsearch 10y ago
    Without starting a VCS war: +1 for Mercurial. If, like me, you do not have a good memory for arbitrary syntax, then mercurial is a lot easier. Takes a bit of cognitive load away from using your VCS. It is thus also much easier to learn than git, so the cost of giving it a whirl is much lower. It also has that nice feeling of being designed with the end user interface in mind, which is satisfying if you care about such things. I enjoy using tools that give me clarity about what I'm doing, and mercurial achieves this by carefully separating the different actions VCS must support. (I regularly use both systems and have done so for years. I am not a power user. I use mercurial whenever I have a choice).
- sangnoir 10y ago
  > On the inside, Git is a thing of beauty, marvel of engineering. On the outside, it is a mess of inconsistent command line options, terrible documentation, and snobbish community that thinks everything of this is fine and small surface details are irrelevant as long as the core works exactly as advertised The core working exactly as advertised is vitally important! Rotten core + shiny, 'user-friendly' exterior would be a polished turd. I do agree - the outside of git didn't have to be ugly and I'm yet to meet any git 'apologist' who disagrees or thinks it's fine. In mitigation though, the git command can be wrapped by friendlier CLI tools or GUIs. Git has succeeded largely in part of the massive tooling around it - things like GitHub would have been less likely to exist had Git's internal data structures been opaque or poorly designed. It might be instructive to hear it from the horses mouth: Linux, on git "git actually has a simple design, with stable and reasonably well-documented data structures. In fact, I'm a huge proponent of designing your code around the data, rather than the other way around, and I think it's one of the reasons git has been fairly successful […] I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important."
zeveb 10y ago
My most important git tip is: use Magit (https://github.com/magit/magit https://github.com/magit/magit). It really is a huge step forward from using the git CLI — but, unlike many UIs to CLI tools, it actually helps one learn the CLI, but presenting flags and git subcommands. Thus, it both supersedes the git CLI and teaches it, just in case one is ever on a computer without Magit.
- K0nserv 10y ago
  Interesting, I tend to recommend people who want to use a UI tool to first learn how to use git from the CLI because many times UI tools are leaky abstraction and sometimes they are flat out wrong and rename concepts. This sounds like it'd be perfect if it wasn't for the emacs aspect of it.
  - zeveb 10y ago
    > This sounds like it'd be perfect if it wasn't for the emacs aspect of it. If you prefer vi you can always use spacemacs … If you prefer Atom or SublimeText, well then: come over to the light side of the Force grin
    - K0nserv 10y ago
      It's more that the people who usually want to use a UI tool are already very UI oriented, so they'll not use emacs or vim. Probably PyCharm, Visual Studio or some other heavy IDE.
    - atemerev 10y ago
      Spacemacs is slow, clunky and always messed up (I tried it 6 months ago and it conflicted with Ergoemacs pretty badly). Also, _both_ vim and Emacs are horrible UI. Vi was designed for slow terminals and a particular keyboard with no arrows; ghjk for navigation is terrible, always pressing the wrong key. Emacs was designed (C-w) evolved from macros for Space Cadet keyboard with lots of modifier keys. How these two archeological curiosities are still praised for being good modern text editors, escapes my mind. (I use both vim and Emacs as I enjoy working in terminal, and I hate them both. Sadly, there is no good text editor like Sublime or Atom for console).
deleted 10y ago
[deleted]
Stratoscope 10y ago
My favorite Git tip is to use SmartGit. http://www.syntevo.com/smartgit/ http://www.syntevo.com/smartgit/ It gives you so much more visibility into the state of your repo, and many operations that take several Git commands are just a single step in SmartGit. And it does show you the underlying commands it uses. I like the way SmartGit unifies things like the reflog. If you "lose" some commits because of an amended commit or a rebase gone bad, you don't have to hunt through the reflog looking at hashes and commit messages, just click the Recyclable Commits checkbox and everything in the reflog shows up as normal commits in your log. You can immediately look through these commits and see the changes without having to check them out. I've also heard good things about SourceTree, but I can definitely vouch for SmartGit.
gbacon 10y ago
A nice tip from Scott Chacon by way of Conrad Parker[0] is to create `git lol` and `git lola` aliases to display a color-coded view of history layout in the console. Summary: add the following to your `~/.gitconfig`. [alias] lol = log --graph --decorate --pretty=oneline --abbrev-commit lola = log --graph --decorate --pretty=oneline --abbrev-commit --all [color] branch = auto diff = auto interactive = auto status = auto [0]: http://blog.kfish.org/2010/04/git-lola.html http://blog.kfish.org/2010/04/git-lola.html
- hayd 10y ago
  You can use the mnemonic "dog" or "adog". Note: the `--abbrev-commit` is redundant due to the `--pretty=oneline`.
  - sangnoir 10y ago
    > Note: the `--abbrev-commit` is redundant due to the `--pretty=oneline` I've tried it and this is not true on my git version (1.9.1) - without the "--abbrev-commit", git displays the full hash
nkantar 10y ago
My personal favorite (though I thankfully haven't had a chance to use it yet): alias gitfire='git checkout -b fire-`date +"%Y%m%d-%H%M%S"` && git add -A && git commit -am "The roof is on fire" && git push origin HEAD'

166 points by gkst 10y ago

devy 10y ago

I wonder why this page doesn't have one of the most frequently asked and rated question: "How to undo last commits in Git". It's rated 11k times so far. [1] http://stackoverflow.com/questions/927358/how-to-undo-last-commits-in-git http://stackoverflow.com/questions/927358/how-to-undo-last-c...

dozzie 10y ago
The reply should be "if you didn't find it in documentation by now, you probably aren't qualified enough to use it".
- pjc50 10y ago
  Few people are really qualified to use it. Most are required to use it and not given the required weeks of training.
  - dozzie 10y ago
    That's a shame it takes them weeks to read three quite comprehensible man pages to think up two different ways of changing commit history. How did we actually get to the point where it takes weeks of training to use git, when I remember learning how to use it in a day or two, ten years ago (when it was much less usable and documented), and for a (far from trivial) use case of being a helper tool for off-line work with Subversion?
    - squeaky-clean 10y ago
      And even if it does take someone a month to learn Git, is that not worth it? You'll be using it pretty much every day for a decade, if not longer.
      - convolvatron 10y ago
        the desire would be to have a system which let you get started relatively quickly, and learn it more in depth as you have need to. git really doesn't work this way because unless you manage your branching and merging in a sympathetic way (to both git and your peers), you can get very thoroughly punished.
    - angry-hacker 10y ago
      Probably because you have 10 years of experience? Git is a mess, but popular tool and many peopled are forced to use it instead of some sane system.
      - dozzie 10y ago
        > Probably because you have 10 years of experience? I was learning git a decade ago, and all it took was at most two days of reading. And yes, this includes the idea on how to rewrite commit history (actually another one, very low-level; I don't expect anybody to ever think of this way for the task). I didn't have StackOverflow or plethora of tutorials on web that are present today. > Git is a mess I keep hearing that, but once upon a time (seven? years ago) I tried learning Mercurial, this paragon of usability, and I couldn't figure out one of the simpler things: how to setup a repository to merge changes from two other repositories without specifying full paths. Given that, either I'm very smart, because I picked up git so quickly, but so-praised Mercurial "is a mess", or I'm very stupid, because I couldn't figure so simple Mercurial function, but then what does it say about people who can't read the fsckin' git docs?
- blakeyrat 10y ago
  Do you think if I had a choice, I would have chosen Git? Ugh. No, I'm forced to use it as a condition of employment. You're right: I'm not qualified to use it, I disqualify myself with the rule "only use software that at least pretends to be usable", but that doesn't mean I have a choice in the matter.
  - dozzie 10y ago
    > Do you think if I had a choice, I would have chosen Git? Ugh. > No, I'm forced to use it as a condition of employment. And you deem it a valid reason to avoid learning the tool you use? O_o
    - blakeyrat 10y ago
      I don't want to be able to think the same way people who think Git is a great tool think. If that makes sense. If I get brainwashed into thinking Git is well-designed or good in any way, I'm afraid I'll completely lose my ability to design quality user interfaces.
      - dozzie 10y ago
        Git with its interface may be rough, but this is merely a superficial trait. The same category as saying that Erlang is fugly because its syntax derives from Prolog. Who cares? It's mechanics and semantics, respectively, that matter. I can whack git repository with a hammer and achieve good, reliable results this way (and I already needed it several times in weird scenarios; I wouldn't get far with Hg under the same circumstances). Pretty much the same case as with Linux OS: all the internals are easily accessible, and user interface is just good enough for me to use.
        blakeyrat 10y ago
        > Who cares? I care. I want to build software normal human beings can actually use. Git is not that. Learning more about Git is me going in the wrong direction entirely. I don't want to go in the wrong direction, I want to go in the right direction.

K0nserv 10y ago

My number one git tip for day to day use rather than specific scenarios is setting up aliases for everything. Along with the ones provided by the git oh-my-zh plugin I have these[0]. Some examples + gco - git checkout + ga - git add + gc - git commit + gp - git push + gl - git pull + gpc - Pushes current branch to origin + gpcfl - Force pushes the current branch to origin using --force-with-lease + glc - Pulls curent branch from origin This is my favourite though function goops { git add -A "$@" && git commit --amend --no-edit && gpcfl } Used like this `goops file`, it adds the file, amends the last commits and force pushes the branch. Super useful because I tend to realise I forgot something just after I push. Don't do this on shared branches though, force pushing should only happen to branches were you are the only one working on the branch or in coordination with anyone else working on the branch. 0: https://github.com/k0nserv/dotfiles/blob/master/files/zshrc.symlink#L14-L20 https://github.com/k0nserv/dotfiles/blob/master/files/zshrc....

vog 10y ago
> ... `goops file`, it adds the file, amends the last commits and force pushes the branch Note that you should only ever do this if you are absolutely sure that you are the only person pushing to that branch. You should consider using "--force-with-lease" instead of "--force". Otherwise you'll sooner or later overwrite a coworker's push without a trace. Maybe they'll notice know Git good enough to fix this, but it would still be very, very annoying. EDIT: Changed "repository" to "branch", mention "--force-with-lease".
- K0nserv 10y ago
  Definitely, don't force push unless you know what you are doing and the implications of force pushing. On the other hand don't blindly listen to people who tell you that force pushing is bad and should always be avoided
- meestaahjoshee 10y ago
  You can use --force-with-lease
  - 10y ago

deleted 10y ago

[deleted]

atemerev 10y ago

Hacks upon hacks upon hacks. On the inside, Git is a thing of beauty, marvel of engineering. On the outside, it is a mess of inconsistent command line options, terrible documentation, and snobbish community that thinks everything of this is fine and small surface details are irrelevant as long as the core works exactly as advertised. They probably also work in Emacs with default keymap.

arunc 10y ago
That's what I felt too. I started using mercurial and I never looked back at git. Mercurial CLI is a pleasure to work with.
- randomsearch 10y ago
  Without starting a VCS war: +1 for Mercurial. If, like me, you do not have a good memory for arbitrary syntax, then mercurial is a lot easier. Takes a bit of cognitive load away from using your VCS. It is thus also much easier to learn than git, so the cost of giving it a whirl is much lower. It also has that nice feeling of being designed with the end user interface in mind, which is satisfying if you care about such things. I enjoy using tools that give me clarity about what I'm doing, and mercurial achieves this by carefully separating the different actions VCS must support. (I regularly use both systems and have done so for years. I am not a power user. I use mercurial whenever I have a choice).
sangnoir 10y ago
> On the inside, Git is a thing of beauty, marvel of engineering. On the outside, it is a mess of inconsistent command line options, terrible documentation, and snobbish community that thinks everything of this is fine and small surface details are irrelevant as long as the core works exactly as advertised The core working exactly as advertised is vitally important! Rotten core + shiny, 'user-friendly' exterior would be a polished turd. I do agree - the outside of git didn't have to be ugly and I'm yet to meet any git 'apologist' who disagrees or thinks it's fine. In mitigation though, the git command can be wrapped by friendlier CLI tools or GUIs. Git has succeeded largely in part of the massive tooling around it - things like GitHub would have been less likely to exist had Git's internal data structures been opaque or poorly designed. It might be instructive to hear it from the horses mouth: Linux, on git "git actually has a simple design, with stable and reasonably well-documented data structures. In fact, I'm a huge proponent of designing your code around the data, rather than the other way around, and I think it's one of the reasons git has been fairly successful […] I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important."

zeveb 10y ago

My most important git tip is: use Magit (https://github.com/magit/magit https://github.com/magit/magit). It really is a huge step forward from using the git CLI — but, unlike many UIs to CLI tools, it actually helps one learn the CLI, but presenting flags and git subcommands. Thus, it both supersedes the git CLI and teaches it, just in case one is ever on a computer without Magit.

K0nserv 10y ago
Interesting, I tend to recommend people who want to use a UI tool to first learn how to use git from the CLI because many times UI tools are leaky abstraction and sometimes they are flat out wrong and rename concepts. This sounds like it'd be perfect if it wasn't for the emacs aspect of it.
- zeveb 10y ago
  > This sounds like it'd be perfect if it wasn't for the emacs aspect of it. If you prefer vi you can always use spacemacs … If you prefer Atom or SublimeText, well then: come over to the light side of the Force grin
  - K0nserv 10y ago
    It's more that the people who usually want to use a UI tool are already very UI oriented, so they'll not use emacs or vim. Probably PyCharm, Visual Studio or some other heavy IDE.
  - atemerev 10y ago
    Spacemacs is slow, clunky and always messed up (I tried it 6 months ago and it conflicted with Ergoemacs pretty badly). Also, _both_ vim and Emacs are horrible UI. Vi was designed for slow terminals and a particular keyboard with no arrows; ghjk for navigation is terrible, always pressing the wrong key. Emacs was designed (C-w) evolved from macros for Space Cadet keyboard with lots of modifier keys. How these two archeological curiosities are still praised for being good modern text editors, escapes my mind. (I use both vim and Emacs as I enjoy working in terminal, and I hate them both. Sadly, there is no good text editor like Sublime or Atom for console).

deleted 10y ago

[deleted]

Stratoscope 10y ago

My favorite Git tip is to use SmartGit. http://www.syntevo.com/smartgit/ http://www.syntevo.com/smartgit/ It gives you so much more visibility into the state of your repo, and many operations that take several Git commands are just a single step in SmartGit. And it does show you the underlying commands it uses. I like the way SmartGit unifies things like the reflog. If you "lose" some commits because of an amended commit or a rebase gone bad, you don't have to hunt through the reflog looking at hashes and commit messages, just click the Recyclable Commits checkbox and everything in the reflog shows up as normal commits in your log. You can immediately look through these commits and see the changes without having to check them out. I've also heard good things about SourceTree, but I can definitely vouch for SmartGit.

gbacon 10y ago

A nice tip from Scott Chacon by way of Conrad Parker[0] is to create `git lol` and `git lola` aliases to display a color-coded view of history layout in the console. Summary: add the following to your `~/.gitconfig`. [alias] lol = log --graph --decorate --pretty=oneline --abbrev-commit lola = log --graph --decorate --pretty=oneline --abbrev-commit --all [color] branch = auto diff = auto interactive = auto status = auto [0]: http://blog.kfish.org/2010/04/git-lola.html http://blog.kfish.org/2010/04/git-lola.html

hayd 10y ago
You can use the mnemonic "dog" or "adog". Note: the `--abbrev-commit` is redundant due to the `--pretty=oneline`.
- sangnoir 10y ago
  > Note: the `--abbrev-commit` is redundant due to the `--pretty=oneline` I've tried it and this is not true on my git version (1.9.1) - without the "--abbrev-commit", git displays the full hash

nkantar 10y ago

My personal favorite (though I thankfully haven't had a chance to use it yet): alias gitfire='git checkout -b fire-`date +"%Y%m%d-%H%M%S"` && git add -A && git commit -am "The roof is on fire" && git push origin HEAD'