3 ms·

The only winning move is not to play. Stick to a few git commands (3-4) and there won't be a whole Alice in Wonderland journey down the rabbit hole.

initialcommit 2y ago
haha this is a bit of a sad take in my opinion, because of the value that I feel that comes with understanding how a tool like Git works behind the scenes, but seems to be several folks here who feel the same way you do
- bloomingkales 2y ago
  It's not a sad take. There are many roles in tech and I'd encourage those trying to make things to focus on that. You can get extremely far with 4 git commands. Even in a production team environment, you may only need to ever add in the merge workflow.
  - initialcommit 2y ago
    The reason it's sad to me is because there is so much more to explore, to be stimulated by, to be able to apply in a way that makes you think out of the box. Maybe a lot of people don't care about that, and I guess everybody has their threshold, where as long as they know the minimum required to do their job they can stay in that comfort zone typing the same commands over and over.
    - deleted 2y ago
      [deleted]
    - deleted 2y ago
      [deleted]
    - nottoohard 2y ago
      [flagged]
  - credit_guy 2y ago
    I agree with you. My typical workflow is: update master branch in Visual Studio, create a new branch off of the master, work on it, when ready use GitGUI to commit and push, then do a merge request in GitLab (we use GitLab). When approved, I push the branch to master. From time to time I need to update my branch, either because I make some code changes, or because my branch a few commits behind the master. Would I like to know more about the underlying ideas of Git. Yes. But the time it would take me to do that is time I can spend on other things, like the stuff I am actually paid to do. If I become a git guru, I might get a pat on the back, but more likely no one would care. If I deliver more stuff, people who use my stuff actually appreciate it.
    - deleted 2y ago
      [deleted]
- delecti 2y ago
  I feel the same way. All of git's weirdness seems totally reasonable once you understand it on its own terms. It doesn't even take a ton of understanding to get that that point either.
never_inline 2y ago
I use the following commands frequently * pull * push * checkout / switch * commit (ofcourse) * merge But I will end up needing * log / log --stat * stash * diff * show / show --stat * blame * revert * cherry-pick * reset * git grep (can be replaced with rg / grep -rn) I can't imagine not having these commands now. If you use something frequently you should know it in-depth. It applies to tools (git, VSCode), frameworks (Spring, Django, whatever), infra (kubernetes, docker). otherwise you're missing out.
- mlhpdx 2y ago
  > If you use something frequently you should know it in-depth. I prefer to remain oblivious to many things. Two views of the Mississippi and all that. Git works reliably and achieves my humble expectations. Thanks git. But in reality I use about the same set of commands. The exception being ‘cherry-pick’ which I avoid solely on disliking the name.
  - fragmede 2y ago
    what would you call it instead? or does the word cherry have some weird association in your mind?
    - mlhpdx 2y ago
      No, it’s just weird and out of context. Just plain “pick” maybe.
      - fragmede 2y ago
        maybe git alias --global pick cherry-pick
    - relaxing 2y ago
      cherry picking has a negative connotation in its most common usage.
      - 2y ago
Shacklz 2y ago
> Stick to a few git commands This was my approach for my first few years of git. I always tried to approach git via its commands, and I horribly failed - until I finally took a little bit of effort to understand how git actually works under the hood, which really made it click for me. For anyone who has ever spent a modicum of time (e.g. while getting a CS degree) trying to understand datastructures, it's probably really straight-forward to "get git". The datastructure underneath is really quite simple. A branch is a pointer to a commit, a commit is a pointer to a tree, a tree is a list of pointers to other trees and files. That's already pretty much all there is to it. Once the datastructure of git is understood, the commands start to "make sense" on their own - at least most of them. They still have tons of obscure options that one doesn't realistically need in a daily work flow, but the general idea what the commands do (and how to recover from screwups) was, at least for me, pretty simple after understanding the datastructure.
- deleted 2y ago
  [deleted]
nottoohard 2y ago
The only winning move is to learn your tools and develop a mental model of what they're doing. You know, like everything else a programmer needs to know.

initialcommit 2y ago

haha this is a bit of a sad take in my opinion, because of the value that I feel that comes with understanding how a tool like Git works behind the scenes, but seems to be several folks here who feel the same way you do

bloomingkales 2y ago
It's not a sad take. There are many roles in tech and I'd encourage those trying to make things to focus on that. You can get extremely far with 4 git commands. Even in a production team environment, you may only need to ever add in the merge workflow.
- initialcommit 2y ago
  The reason it's sad to me is because there is so much more to explore, to be stimulated by, to be able to apply in a way that makes you think out of the box. Maybe a lot of people don't care about that, and I guess everybody has their threshold, where as long as they know the minimum required to do their job they can stay in that comfort zone typing the same commands over and over.
  - deleted 2y ago
    [deleted]
  - deleted 2y ago
    [deleted]
  - nottoohard 2y ago
    [flagged]
- credit_guy 2y ago
  I agree with you. My typical workflow is: update master branch in Visual Studio, create a new branch off of the master, work on it, when ready use GitGUI to commit and push, then do a merge request in GitLab (we use GitLab). When approved, I push the branch to master. From time to time I need to update my branch, either because I make some code changes, or because my branch a few commits behind the master. Would I like to know more about the underlying ideas of Git. Yes. But the time it would take me to do that is time I can spend on other things, like the stuff I am actually paid to do. If I become a git guru, I might get a pat on the back, but more likely no one would care. If I deliver more stuff, people who use my stuff actually appreciate it.
  - deleted 2y ago
    [deleted]
delecti 2y ago
I feel the same way. All of git's weirdness seems totally reasonable once you understand it on its own terms. It doesn't even take a ton of understanding to get that that point either.

never_inline 2y ago

I use the following commands frequently * pull * push * checkout / switch * commit (ofcourse) * merge But I will end up needing * log / log --stat * stash * diff * show / show --stat * blame * revert * cherry-pick * reset * git grep (can be replaced with rg / grep -rn) I can't imagine not having these commands now. If you use something frequently you should know it in-depth. It applies to tools (git, VSCode), frameworks (Spring, Django, whatever), infra (kubernetes, docker). otherwise you're missing out.

mlhpdx 2y ago
> If you use something frequently you should know it in-depth. I prefer to remain oblivious to many things. Two views of the Mississippi and all that. Git works reliably and achieves my humble expectations. Thanks git. But in reality I use about the same set of commands. The exception being ‘cherry-pick’ which I avoid solely on disliking the name.
- fragmede 2y ago
  what would you call it instead? or does the word cherry have some weird association in your mind?
  - mlhpdx 2y ago
    No, it’s just weird and out of context. Just plain “pick” maybe.
    - fragmede 2y ago
      maybe git alias --global pick cherry-pick
  - relaxing 2y ago
    cherry picking has a negative connotation in its most common usage.
    - 2y ago

Shacklz 2y ago

> Stick to a few git commands This was my approach for my first few years of git. I always tried to approach git via its commands, and I horribly failed - until I finally took a little bit of effort to understand how git actually works under the hood, which really made it click for me. For anyone who has ever spent a modicum of time (e.g. while getting a CS degree) trying to understand datastructures, it's probably really straight-forward to "get git". The datastructure underneath is really quite simple. A branch is a pointer to a commit, a commit is a pointer to a tree, a tree is a list of pointers to other trees and files. That's already pretty much all there is to it. Once the datastructure of git is understood, the commands start to "make sense" on their own - at least most of them. They still have tons of obscure options that one doesn't realistically need in a daily work flow, but the general idea what the commands do (and how to recover from screwups) was, at least for me, pretty simple after understanding the datastructure.

deleted 2y ago
[deleted]

nottoohard 2y ago

The only winning move is to learn your tools and develop a mental model of what they're doing. You know, like everything else a programmer needs to know.