5 ms·

+1 These commands will get you 99% of the way: - git status - git branch - git pull - git add - git commit - git diff - git merge - git push - git che

+1 These commands will get you 99% of the way: - git status - git branch - git pull - git add - git commit - git diff - git merge - git push - git checkout For everything else there's StackOverflow, but the info in there comes with the risk of being stale. -------------- Edit commit abaeb3b4: Add missing commands and improve formatting Edit commit 842babda: Add git checkout

h0l0cube 6y ago
`git status` is required to determine which untracked files you need to add. And then, of course, `git add` would be need to be added to the list too. To add untracked files you could use interactive mode `git add -i` and forgo reading `status`. But you can also `git commit -p` if you only modified files and forgo the `add` step. And to give yourself a sense of the commit graph, these aliases come in handy [alias] lol = log --graph --decorate --pretty=oneline --abbrev-commit lola = log --graph --date=short --pretty=format:'%C(auto)%h %C(dim)%ad%C(auto)%d %s' --all The only 'advanced' thing I commonly do is `git rebase -i` to squash a bunch of WIP commits. And a shell script I have to turn merged branch into a tag, and remove the branch. The other day I had to remove a sensitive file that accidentally got checked into the repo for a couple of commits behind HEAD, and was glad that git had the power to do this in one line and without fuss. (Edit: but yes, I had to look it up on SE)
- secondcoming 6y ago
  Indeed, I forgot 'git status', and 'git add' I've honestly ever felt the need, or had the requirement, to look at the graph.
  - h0l0cube 6y ago
    I've found it indispensable when tracking and integrating other peoples' branches. I wouldn't use it so much if I was working solo.
    - sethammons 6y ago
      I've never worked solo. My teams tend to be around 6-8. Across a dozen teams, myself and nobody on the team save a couple even looked at the graph. One who loved a clean history showed it off, people thought it was pretty, and went back to work as normal. `git commit -am 'slightly helpful message' && git push origin $branch` does about 90%+ of what I've needed. When we merge the branch, squash merge works fine. History graphs, I've never felt the need for them.
      - secondcoming 6y ago
        We're the exact same except for the squashed merge (which I have no real objection to doing)
      - h0l0cube 6y ago
        Each to their own. I use it in situations where i want to know what other people are basing their branch from. Which, for projects I've worked on, can have real consequences. For instance, it may prompt me to rebase upon their work sooner, or even give them a heads up that theirs some useful change I'm submitting to the trunk.
        sethammons 6y ago
        ah, that is likely part of it. We always branch from master and merge back to master. Builds prevent failing code from merging. It is rare that we branch from a branch, and that 2nd branch would never be merged before the first.
        h0l0cube 6y ago
        During rapid mobile and frontend development, occasionally I'll be working on someone where there's co-depending feature branches, but for the most part the team usually follow something like git-flow. But I take your point that viewing the graph isn't essential, and those aliases might look scary on a one-page crash course. (I really think `git lol` and `git lola` should be first class citizens of a git installation though)
jariel 6y ago
So this, to me, is not a 'benefit of git' it articulates in some ways how bad it is (although very powerful). Most people can get going with those 99% commands quite quickly, the problem with git is any move from the known path creates some pretty amazingly complicated scenarios. And those '1% of the time' commands blow up into time-consuming rabbit holes of complexity. Often, Stack Exchange has several answers for the same question, highlighting just how much inherent complexity there is in the product. Managing software versions across repo can be a very, very complicated problem. Git provides you with a pile of tools to do 'almost anything'. A 'well designed product' would make the toolsets and concepts focus heavily on the 'main operations' and then have clear, clean rational idioms, practices and tools for the odd cases, and 'dangerous cases' wouldn't be allowed without some kind of special command. They have the 'Golden Rule of Git' which is to not rebase on a public branch - this is an excellent example of poor product design. There should be no 'golden rule' that developers have to understand - it shouldn't be possible (without special admin commands). If branches are named/tagged and managed properly, the system would be smart enough to let you know you can't do that, and why. Administrators exist for a reason, 'sudo' exists for a reason etc. People who love powerful things, and have an inclination towards complexity seem to love git, people who have a product orientation see it differently.
- jamienicol 6y ago
  You can't push a rebased branch without`--force`, and the server can be configured to disallow it entirely. This is exactly how it should be: I want to be able to rebase my by public branches but not the public branch.
  - jariel 6y ago
    " I want to be able to rebase my by public branches but not the public branch." Already that's a little bit complicated though. Even though yes, this use case probably does exist, it might be a tricky thing to unwind for some people - what would they do when they have already changed the history of 'their' public branch (?) is something they'd have to carefully think about.
- aulin 6y ago
pelasaco 6y ago
I use git daily. I never use merge. I use git rebase, and its interactive version all day.
- samhh 6y ago
  You'll potentially need to use merge if you're collaborating with others on feature branches.
- secondcoming 6y ago
  Ya, I'm the opposite, I never use rebase. Horses for courses...
  - aeyes 6y ago
    You should, or do you just merge updated remote branches into your stale local branches? A lot of new developers seem to do that here until we explain to them how it messes up the history.
    - Supermancho 6y ago
      > do you just merge updated remote branches into your stale local branches? Every single developer I work with (or have in the last 8 years) does this. "Messes up the history" ? The merge commit describes that there are uptaken changes from the "main" branch. It doesn't seem to be a problem in practice.
      - KptMarchewa 6y ago
        It's also not a problem for me, because I squash the commits on merge to master or other remote branch.
    - recursive 6y ago
      I've been doing that for years, and it's never messed up the history.
    - secondcoming 6y ago
nicoburns 6y ago
I think `git checkout` definitely needs to be there. Also `git reset` in case you make a mistake while `git add`ing
- samhh 6y ago
  I think the most common usage of that - switching branches - could be replaced with `git switch` now. That leaves `git checkout` in the set of more advanced operations for more niche use cases. Same goes I think for `git restore` over `git reset`.
- secondcoming 6y ago
  Added checkout. I'm not sure about classifying 'git reset' as an 'everyday' command.
  - kubanczyk 6y ago
    Correct. The use case falls under `git status` really, it will give you boilerplate commands like `git add`, `git reset`, `git checkout -- file`, or even `git rebase --abort` depending on a situation.
fphilipe 6y ago
I use git-show a lot to look at individual commits. Would add that to the list.
outsomnia 6y ago
fetch is also a primitive

h0l0cube 6y ago

`git status` is required to determine which untracked files you need to add. And then, of course, `git add` would be need to be added to the list too. To add untracked files you could use interactive mode `git add -i` and forgo reading `status`. But you can also `git commit -p` if you only modified files and forgo the `add` step. And to give yourself a sense of the commit graph, these aliases come in handy [alias] lol = log --graph --decorate --pretty=oneline --abbrev-commit lola = log --graph --date=short --pretty=format:'%C(auto)%h %C(dim)%ad%C(auto)%d %s' --all The only 'advanced' thing I commonly do is `git rebase -i` to squash a bunch of WIP commits. And a shell script I have to turn merged branch into a tag, and remove the branch. The other day I had to remove a sensitive file that accidentally got checked into the repo for a couple of commits behind HEAD, and was glad that git had the power to do this in one line and without fuss. (Edit: but yes, I had to look it up on SE)

secondcoming 6y ago
Indeed, I forgot 'git status', and 'git add' I've honestly ever felt the need, or had the requirement, to look at the graph.
- h0l0cube 6y ago
  I've found it indispensable when tracking and integrating other peoples' branches. I wouldn't use it so much if I was working solo.
  - sethammons 6y ago
    I've never worked solo. My teams tend to be around 6-8. Across a dozen teams, myself and nobody on the team save a couple even looked at the graph. One who loved a clean history showed it off, people thought it was pretty, and went back to work as normal. `git commit -am 'slightly helpful message' && git push origin $branch` does about 90%+ of what I've needed. When we merge the branch, squash merge works fine. History graphs, I've never felt the need for them.
    - secondcoming 6y ago
      We're the exact same except for the squashed merge (which I have no real objection to doing)
    - h0l0cube 6y ago
      Each to their own. I use it in situations where i want to know what other people are basing their branch from. Which, for projects I've worked on, can have real consequences. For instance, it may prompt me to rebase upon their work sooner, or even give them a heads up that theirs some useful change I'm submitting to the trunk.
      - sethammons 6y ago
        ah, that is likely part of it. We always branch from master and merge back to master. Builds prevent failing code from merging. It is rare that we branch from a branch, and that 2nd branch would never be merged before the first.
        h0l0cube 6y ago
        During rapid mobile and frontend development, occasionally I'll be working on someone where there's co-depending feature branches, but for the most part the team usually follow something like git-flow. But I take your point that viewing the graph isn't essential, and those aliases might look scary on a one-page crash course. (I really think `git lol` and `git lola` should be first class citizens of a git installation though)

jariel 6y ago

So this, to me, is not a 'benefit of git' it articulates in some ways how bad it is (although very powerful). Most people can get going with those 99% commands quite quickly, the problem with git is any move from the known path creates some pretty amazingly complicated scenarios. And those '1% of the time' commands blow up into time-consuming rabbit holes of complexity. Often, Stack Exchange has several answers for the same question, highlighting just how much inherent complexity there is in the product. Managing software versions across repo can be a very, very complicated problem. Git provides you with a pile of tools to do 'almost anything'. A 'well designed product' would make the toolsets and concepts focus heavily on the 'main operations' and then have clear, clean rational idioms, practices and tools for the odd cases, and 'dangerous cases' wouldn't be allowed without some kind of special command. They have the 'Golden Rule of Git' which is to not rebase on a public branch - this is an excellent example of poor product design. There should be no 'golden rule' that developers have to understand - it shouldn't be possible (without special admin commands). If branches are named/tagged and managed properly, the system would be smart enough to let you know you can't do that, and why. Administrators exist for a reason, 'sudo' exists for a reason etc. People who love powerful things, and have an inclination towards complexity seem to love git, people who have a product orientation see it differently.

jamienicol 6y ago
You can't push a rebased branch without`--force`, and the server can be configured to disallow it entirely. This is exactly how it should be: I want to be able to rebase my by public branches but not the public branch.
- jariel 6y ago
  " I want to be able to rebase my by public branches but not the public branch." Already that's a little bit complicated though. Even though yes, this use case probably does exist, it might be a tricky thing to unwind for some people - what would they do when they have already changed the history of 'their' public branch (?) is something they'd have to carefully think about.
aulin 6y ago

pelasaco 6y ago

I use git daily. I never use merge. I use git rebase, and its interactive version all day.

samhh 6y ago
You'll potentially need to use merge if you're collaborating with others on feature branches.
secondcoming 6y ago
Ya, I'm the opposite, I never use rebase. Horses for courses...
- aeyes 6y ago
  You should, or do you just merge updated remote branches into your stale local branches? A lot of new developers seem to do that here until we explain to them how it messes up the history.
  - Supermancho 6y ago
    > do you just merge updated remote branches into your stale local branches? Every single developer I work with (or have in the last 8 years) does this. "Messes up the history" ? The merge commit describes that there are uptaken changes from the "main" branch. It doesn't seem to be a problem in practice.
    - KptMarchewa 6y ago
      It's also not a problem for me, because I squash the commits on merge to master or other remote branch.
  - recursive 6y ago
    I've been doing that for years, and it's never messed up the history.
  - secondcoming 6y ago

nicoburns 6y ago

I think `git checkout` definitely needs to be there. Also `git reset` in case you make a mistake while `git add`ing

samhh 6y ago
I think the most common usage of that - switching branches - could be replaced with `git switch` now. That leaves `git checkout` in the set of more advanced operations for more niche use cases. Same goes I think for `git restore` over `git reset`.
secondcoming 6y ago
Added checkout. I'm not sure about classifying 'git reset' as an 'everyday' command.
- kubanczyk 6y ago
  Correct. The use case falls under `git status` really, it will give you boilerplate commands like `git add`, `git reset`, `git checkout -- file`, or even `git rebase --abort` depending on a situation.

fphilipe 6y ago

I use git-show a lot to look at individual commits. Would add that to the list.

outsomnia 6y ago

fetch is also a primitive