3 ms·

`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

`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)

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)