7 ms·

This is nice, but I'd like a 201-level handholding on git. I've been using it for 5 years and I'm still just a clone/commit/merge/(bang head)/push user yet I kn

This is nice, but I'd like a 201-level handholding on git. I've been using it for 5 years and I'm still just a clone/commit/merge/(bang head)/push user yet I know there is tons more it can do that would probably make me more effective. (I'd also like to switch my team of SVN. Someday....)

akulbe 8y ago
This is so so fitting, and describe me to a "T" as well. I'd add oh-crap-I-screwed-up-so-let's-clone-the-repo-and-start-over to the list.
- smichel17 8y ago
  What can you screw up that requires re-cloning the repo rather than just a reset --hard?
  - akulbe 8y ago
    Not knowing about the "reset --hard" feature? :)
  - hinkley 8y ago
    For one, accidentally deleting the .git directory.
- buovjaga 8y ago
  Alternative to nuking from orbit is taking a look at "Flight rules for git": https://github.com/k88hudson/git-flight-rules https://github.com/k88hudson/git-flight-rules
  - rachelmcarmena 8y ago
    Awesome! I'll add it to my post! Thanks!
sjburt 8y ago
I think once you understand the graph, then looking at what the graph looks like and what you want it to look like usually leads you to being able to figure out what operation you want. And then git fetch/push/pull are mostly about copying parts of that graph from one place to another. After that, it's mostly a question of what workflow you want and that becomes much more than a git question because git works for a variety of workflows, and many of the features of git are really only relevant for certain flows.
- joachimma 8y ago
  100% agree. Once you know what you want the tree to look like it's usually just a matter of making a branch/tag (in case you mess up, and need to start over) and not being afraid of reset, even with the --hard flag.
sokoloff 8y ago
If you're an emacs user (and maybe even if you're not), try the magit package. That taught me in a few weeks of usage more git 102 and 201 type functionality than a year of using only the basics did.
- Fellshard 8y ago
  As a new emacs / spacemacs user, I bounced off magit hard. Too many weird things going on, hard to tell what I can do. A couple months later, and a bit more experience with how emacs structures things, and I've returned to Magit and _love_ it. It just feels natural to hop around in for standard tasks. Certainly a good replacement for other porcelain UIs I'd normally use.
  - aldanor 8y ago
    I use Spacemacs ONLY to have access to Magit. And I've successfully converted many non-emacs non-vim folks to use it, all of them love it.
wickchuck 8y ago
SublimeMerge is also a wonderful tool. Been using that since it came out and has helped tremendously with difficult merges. It's lightning quick as well. Similar to magit - Sublime Text also has SublimeGit, not as fast as SublimeMerge. Visual Studio Code built in git functionality is also nice.
- jen729w 8y ago
  A mention for Tower. I only do the basics but it totally took away my Git fear. https://www.git-tower.com/mac https://www.git-tower.com/mac
  - yyx 8y ago
    gitKraken is nice too https://www.gitkraken.com/ https://www.gitkraken.com/
svat 8y ago
My recommendations: * Git From the Bottom Up: https://jwiegley.github.io/git-from-the-bottom-up/ https://jwiegley.github.io/git-from-the-bottom-up/ (PDF: http://ftp.newartisans.com/pub/git.from.bottom.up.pdf http://ftp.newartisans.com/pub/git.from.bottom.up.pdf) (See also: "Linus Torvalds' greatest invention": http://perl.plover.com/yak/git/ http://perl.plover.com/yak/git/) Once your mental model matches the program, you'll be able to understand everything, hack your own solutions if necessary, etc. * Learn Git Branching: https://learngitbranching.js.org https://learngitbranching.js.org -- in fact I think this should be the UI for Git; wish someone would make that happen (i.e., so that you can point it to any Git repo and get that sort of visualization for it).
- rachelmcarmena 8y ago
  Thanks! Awesome resources! I'll add it to my post as soon as I finish reading all the answers. I'm learning a lot from you!
- malingo 8y ago
  I'd also recommend http://matthew-brett.github.io/pydagogue/rebase_without_tears.html http://matthew-brett.github.io/pydagogue/rebase_without_tear...
- deleted 8y ago
  [deleted]
LukeShu 8y ago
I agree with sjburt when he says "I think once you understand the graph, then looking at what the graph looks like and what you want it to look like usually leads you to being able to figure out what operation you want." When I was first getting in to Git ~10 years ago, I remember that I found the PeepCode "Git Internals" book[1] very helpful for getting that understanding of the graph. Once you have the better understanding of the graph, it's hard to find resources on how to improve from there; most resources focus on beginner stuff, or function more as a technical reference without really talking about use-cases. I've found following Mark Dominus' blog[2] for his posts about Git to be the single best thing to "level up" my Git usage once already being at a high-level. [1]: At the time, I had to pay money for the eBook, now they have the whole thing on GitHub: https://github.com/pluralsight/git-internals-pdf https://github.com/pluralsight/git-internals-pdf [2]: https://blog.plover.com/ https://blog.plover.com/
IshKebab 8y ago
Use a GUI. Git repos are graphs and trying to understand a graph from the command line is like trying to paint over the phone. I recommend GitX (FOSS, Mac only, a little buggy but has the most logical UI and let's you easily amend commits), SourceTree (free, quite slow, Windows/Mac), Tower (paid, cross platform) or SublimeMerge (paid, easily the fastest, cross platform).
P_I_Staker 8y ago
Honestly, you just need to try some things. Your reflog is your friend. You'll get the hang of reset/rebase/ect with a little experience. I also think it's worth it to learn a bit more about diff and log. I have no idea why anyone would want to go back to SVN. If you don't want to use all the features, I understand; by all means, continue to only ever branch -> commit -> push -> create pull request. There's no need to subject the whole team to version control that doesn't work. That's what sold me on git; it's the only version control system that never failed at it's job of letting me track my changes. It doesn't break it's promise to always be there for me. SVN, centralized systems, and even mercurial to some extent, prevent users from tracking their changes. This leads to questionable workflows (lots of copying directories to "save things"), or even worse, developers just don't track their changes at times. It sounds weird that I have to say this, but I feel that version control systems should be available to track changes 100% of the time. It seems like many of the people who dislike git, don't see the value in this, which I find absolutely baffling. Git means never being scared to create a commit.
- krupan 8y ago
  "and even mercurial to some extent, prevent users from tracking their changes" False. Stop spreading misinformation about Mercurial. "Git means never being scared to create a commit." This is indeed one of the biggest benefits of DVCS tools, including git and mercurial.
  - P_I_Staker 8y ago
    Thanks for the feedback. Quite frankly, I never found a comparable workflow in Mercurial (but that doesn't mean one doesn't exist). Commits still felt like a permanent thing that made me pause and think about whether something was "worthy" of a commit, thus I was unable to track my changes. This problem just doesn't exist in Git, though some care is needed when publishing (as w/any system). I'm unaware of anything within base Mercurial that lets me do what I can do with git. Maybe the answer is to use the extensions, however that's a bit unsettling when some of them are being depreciated (eg. hg queues). Often times I found myself cloning and maintaining multiple directories for something that was better off as one thing. This led to reluctance to track changes, which is clearly evil. I guess I must have been doing something wrong, but I've heard similar feedback from others regarding Mercurial. I loved using hg and would have no problem using it (it was my first); I just prefer git now.
vharuck 8y ago
I took it upon myself to introduce Git to my colleagues: statisticians who've never used version control. I tried to preempt hard questions by going into a repo, wrecking it like a mad bull, and trying to undo the damage with Git. Turns out, it was a great way to learn for myself. Exercises: - Commit a "secret" and involve it in other branches, commits, merges, etc. Then remove the secret so that nobody can ever learn it from the repo. - Clone a repo from another local repo and then rewrite history with rebase and revert. Then commit different work in each repo. What's the least painful way to get them "compatible" without losing any work?

akulbe 8y ago

This is so so fitting, and describe me to a "T" as well. I'd add oh-crap-I-screwed-up-so-let's-clone-the-repo-and-start-over to the list.

smichel17 8y ago
What can you screw up that requires re-cloning the repo rather than just a reset --hard?
- akulbe 8y ago
  Not knowing about the "reset --hard" feature? :)
- hinkley 8y ago
  For one, accidentally deleting the .git directory.
buovjaga 8y ago
Alternative to nuking from orbit is taking a look at "Flight rules for git": https://github.com/k88hudson/git-flight-rules https://github.com/k88hudson/git-flight-rules
- rachelmcarmena 8y ago
  Awesome! I'll add it to my post! Thanks!

sjburt 8y ago

I think once you understand the graph, then looking at what the graph looks like and what you want it to look like usually leads you to being able to figure out what operation you want. And then git fetch/push/pull are mostly about copying parts of that graph from one place to another. After that, it's mostly a question of what workflow you want and that becomes much more than a git question because git works for a variety of workflows, and many of the features of git are really only relevant for certain flows.

joachimma 8y ago
100% agree. Once you know what you want the tree to look like it's usually just a matter of making a branch/tag (in case you mess up, and need to start over) and not being afraid of reset, even with the --hard flag.

sokoloff 8y ago

If you're an emacs user (and maybe even if you're not), try the magit package. That taught me in a few weeks of usage more git 102 and 201 type functionality than a year of using only the basics did.

Fellshard 8y ago
As a new emacs / spacemacs user, I bounced off magit hard. Too many weird things going on, hard to tell what I can do. A couple months later, and a bit more experience with how emacs structures things, and I've returned to Magit and _love_ it. It just feels natural to hop around in for standard tasks. Certainly a good replacement for other porcelain UIs I'd normally use.
- aldanor 8y ago
  I use Spacemacs ONLY to have access to Magit. And I've successfully converted many non-emacs non-vim folks to use it, all of them love it.

wickchuck 8y ago

SublimeMerge is also a wonderful tool. Been using that since it came out and has helped tremendously with difficult merges. It's lightning quick as well. Similar to magit - Sublime Text also has SublimeGit, not as fast as SublimeMerge. Visual Studio Code built in git functionality is also nice.

jen729w 8y ago
A mention for Tower. I only do the basics but it totally took away my Git fear. https://www.git-tower.com/mac https://www.git-tower.com/mac
- yyx 8y ago
  gitKraken is nice too https://www.gitkraken.com/ https://www.gitkraken.com/

svat 8y ago

My recommendations: * Git From the Bottom Up: https://jwiegley.github.io/git-from-the-bottom-up/ https://jwiegley.github.io/git-from-the-bottom-up/ (PDF: http://ftp.newartisans.com/pub/git.from.bottom.up.pdf http://ftp.newartisans.com/pub/git.from.bottom.up.pdf) (See also: "Linus Torvalds' greatest invention": http://perl.plover.com/yak/git/ http://perl.plover.com/yak/git/) Once your mental model matches the program, you'll be able to understand everything, hack your own solutions if necessary, etc. * Learn Git Branching: https://learngitbranching.js.org https://learngitbranching.js.org -- in fact I think this should be the UI for Git; wish someone would make that happen (i.e., so that you can point it to any Git repo and get that sort of visualization for it).

rachelmcarmena 8y ago
Thanks! Awesome resources! I'll add it to my post as soon as I finish reading all the answers. I'm learning a lot from you!
malingo 8y ago
I'd also recommend http://matthew-brett.github.io/pydagogue/rebase_without_tears.html http://matthew-brett.github.io/pydagogue/rebase_without_tear...
deleted 8y ago
[deleted]

LukeShu 8y ago

I agree with sjburt when he says "I think once you understand the graph, then looking at what the graph looks like and what you want it to look like usually leads you to being able to figure out what operation you want." When I was first getting in to Git ~10 years ago, I remember that I found the PeepCode "Git Internals" book[1] very helpful for getting that understanding of the graph. Once you have the better understanding of the graph, it's hard to find resources on how to improve from there; most resources focus on beginner stuff, or function more as a technical reference without really talking about use-cases. I've found following Mark Dominus' blog[2] for his posts about Git to be the single best thing to "level up" my Git usage once already being at a high-level. [1]: At the time, I had to pay money for the eBook, now they have the whole thing on GitHub: https://github.com/pluralsight/git-internals-pdf https://github.com/pluralsight/git-internals-pdf [2]: https://blog.plover.com/ https://blog.plover.com/

IshKebab 8y ago

Use a GUI. Git repos are graphs and trying to understand a graph from the command line is like trying to paint over the phone. I recommend GitX (FOSS, Mac only, a little buggy but has the most logical UI and let's you easily amend commits), SourceTree (free, quite slow, Windows/Mac), Tower (paid, cross platform) or SublimeMerge (paid, easily the fastest, cross platform).

P_I_Staker 8y ago

Honestly, you just need to try some things. Your reflog is your friend. You'll get the hang of reset/rebase/ect with a little experience. I also think it's worth it to learn a bit more about diff and log. I have no idea why anyone would want to go back to SVN. If you don't want to use all the features, I understand; by all means, continue to only ever branch -> commit -> push -> create pull request. There's no need to subject the whole team to version control that doesn't work. That's what sold me on git; it's the only version control system that never failed at it's job of letting me track my changes. It doesn't break it's promise to always be there for me. SVN, centralized systems, and even mercurial to some extent, prevent users from tracking their changes. This leads to questionable workflows (lots of copying directories to "save things"), or even worse, developers just don't track their changes at times. It sounds weird that I have to say this, but I feel that version control systems should be available to track changes 100% of the time. It seems like many of the people who dislike git, don't see the value in this, which I find absolutely baffling. Git means never being scared to create a commit.

krupan 8y ago
"and even mercurial to some extent, prevent users from tracking their changes" False. Stop spreading misinformation about Mercurial. "Git means never being scared to create a commit." This is indeed one of the biggest benefits of DVCS tools, including git and mercurial.
- P_I_Staker 8y ago
  Thanks for the feedback. Quite frankly, I never found a comparable workflow in Mercurial (but that doesn't mean one doesn't exist). Commits still felt like a permanent thing that made me pause and think about whether something was "worthy" of a commit, thus I was unable to track my changes. This problem just doesn't exist in Git, though some care is needed when publishing (as w/any system). I'm unaware of anything within base Mercurial that lets me do what I can do with git. Maybe the answer is to use the extensions, however that's a bit unsettling when some of them are being depreciated (eg. hg queues). Often times I found myself cloning and maintaining multiple directories for something that was better off as one thing. This led to reluctance to track changes, which is clearly evil. I guess I must have been doing something wrong, but I've heard similar feedback from others regarding Mercurial. I loved using hg and would have no problem using it (it was my first); I just prefer git now.

vharuck 8y ago

I took it upon myself to introduce Git to my colleagues: statisticians who've never used version control. I tried to preempt hard questions by going into a repo, wrecking it like a mad bull, and trying to undo the damage with Git. Turns out, it was a great way to learn for myself. Exercises: - Commit a "secret" and involve it in other branches, commits, merges, etc. Then remove the secret so that nobody can ever learn it from the repo. - Clone a repo from another local repo and then rewrite history with rebase and revert. Then commit different work in each repo. What's the least painful way to get them "compatible" without losing any work?