6 ms·

As a helpful aside, in my experience, there are only about a dozen or so Git commands you need to do ninety percent of your work. You don't need to become a git

As a helpful aside, in my experience, there are only about a dozen or so Git commands you need to do ninety percent of your work. You don't need to become a git zen master right away. 1. git init: to start a new repository 2. git status: checks your current state 3. git add -A: To begin tracking files 4. git commit -am: Commit all changes in the working directory with a message added on 5. git switch -c [branch name]: Create a branch and switch to it. (git checkout -b will do the same thing) 6. git switch [branch name]: switch between named branches 7. git merge[branch]: merge named branch into current branch 8. git branch [branch name] -D : delete branch if not tracked 9. git log --pretty=oneline: show a graph of commit history. 11. git push 12. git clone [repo]: Copy of a project/file onto your local computer. The comments also contain some additional advice. Here is a good introductory video: https://www.youtube.com/watch?v=2sjqTHE0zok https://www.youtube.com/watch?v=2sjqTHE0zok

TobTobXX 5y ago
> 8. git branch [branchname] -D : delete branch if not tracked Dangerous advice there. Use the lower-case '-d' option. It'll tell you that you maybe don't want to delete the branch when it has unmerged commits. If you really want to delete the branch then, the output of `git branch -d` tells you this option.
y04nn 5y ago
I would add `git rebase -i`, beacause I usually develop on a local branch and rebase it to the updated one. With git things can get messy when you want do something outside of the basic stuff. What I hate the most is resolving 3 way merges.
dfabulich 5y ago
Odd that you put switch on this list but not restore. Undoing changes is pretty important.
samatman 5y ago
I'm mildly amused that your set of commands can't actually commit anything other than a brand-new file! I will admit that I'm a lazy git user, and do most of my commits with `git commit -a`, rather than `-am` since I do try and give a short paragraph explaining the reasoning behind whatever the title message claims is the purpose of the commit. I do run `git diff` first to see what I've changed, and if the diff has unrelated changes in different files I'll usually break it up into separate commits. Decent introductory list, though. It won't surprise you that I think diff should be learned immediately; whether or not you need rebase depends on the conventions of the codebase, and if someone can learn it later they should, it can get tricky.
- deleted 5y ago
  [deleted]
- Lordarminius 5y ago
  True, an error. Corrected.
- quickthrower2 5y ago
  I’m interested in how many people double check their changes before committing as I’ve done this since the days of sourcesafe, and a decent number of bugs I’ve seen are people just not checking what they committed (some stray change got in that they never intended)
  - neolefty 5y ago
    Yes! I find that if I don't comment my PRs, my coworkers avoid them. But then in commenting them, I find quite a few ... not always errors, but cleanups at least.
cryptonector 5y ago
You're missing out. You need rebase and cherry-pick. Merging sucks.
- quickthrower2 5y ago
  Merging rocks! Never had an issue with merging and it’s less work. I’d only rebase if there is a “story” I want to tell in the commit history, that would be otherwise lost. This is rare, probably if someone else did some major refactor or move around
  - cryptonector 5y ago
    Merging makes life harder for others, and easier for you. Rebasing does the opposite, but has other benefits.
    - quickthrower2 5y ago
      It only makes a difference if everything is fast forwarded onto master. If branches are squash merged in (as is common), keeping those merged in branches up to date via merges or rebasing doesn't make much difference to others. If you are chucking all your commits onto master - power to you. That's probably a good pattern (I prefer as much historical data as possible to a 'neat' commit history), but I never see it done because usually master is linked to CI and the idea is is every commit to master should be a valid build.
      - cryptonector 5y ago
        Master or any branch you're aiming to integrate into. Squashing everything is bad because it makes code review and backports harder. Maybe you don't care about backports, but if you care about code reviews...
        quickthrower2 5y ago
        We code review unsquashed branches. Honestly I just diff the whole thing from where they branched to the tip anyway I rarely find the individual commits useful as there is usually a process of their discovery in that with backtracks etc. that’s a waste of time to review. For example I could review a new class that they heavily refactored in the next commit. I’ve not had an issue with code reviews or backporting. I suspect this is because either out units of work are smaller than usual (no long feature branches) But maybe you are onto something here and I’m missing out on a better way but I’ve not experienced enough pain in squashing on merge to master to contemplate switching to a rebase workflow (which means convincing team members too)

TobTobXX 5y ago

> 8. git branch [branchname] -D : delete branch if not tracked Dangerous advice there. Use the lower-case '-d' option. It'll tell you that you maybe don't want to delete the branch when it has unmerged commits. If you really want to delete the branch then, the output of `git branch -d` tells you this option.

y04nn 5y ago

I would add `git rebase -i`, beacause I usually develop on a local branch and rebase it to the updated one. With git things can get messy when you want do something outside of the basic stuff. What I hate the most is resolving 3 way merges.

dfabulich 5y ago

Odd that you put switch on this list but not restore. Undoing changes is pretty important.

samatman 5y ago

I'm mildly amused that your set of commands can't actually commit anything other than a brand-new file! I will admit that I'm a lazy git user, and do most of my commits with `git commit -a`, rather than `-am` since I do try and give a short paragraph explaining the reasoning behind whatever the title message claims is the purpose of the commit. I do run `git diff` first to see what I've changed, and if the diff has unrelated changes in different files I'll usually break it up into separate commits. Decent introductory list, though. It won't surprise you that I think diff should be learned immediately; whether or not you need rebase depends on the conventions of the codebase, and if someone can learn it later they should, it can get tricky.

deleted 5y ago
[deleted]
Lordarminius 5y ago
True, an error. Corrected.
quickthrower2 5y ago
I’m interested in how many people double check their changes before committing as I’ve done this since the days of sourcesafe, and a decent number of bugs I’ve seen are people just not checking what they committed (some stray change got in that they never intended)
- neolefty 5y ago
  Yes! I find that if I don't comment my PRs, my coworkers avoid them. But then in commenting them, I find quite a few ... not always errors, but cleanups at least.

cryptonector 5y ago

You're missing out. You need rebase and cherry-pick. Merging sucks.

quickthrower2 5y ago
Merging rocks! Never had an issue with merging and it’s less work. I’d only rebase if there is a “story” I want to tell in the commit history, that would be otherwise lost. This is rare, probably if someone else did some major refactor or move around
- cryptonector 5y ago
  Merging makes life harder for others, and easier for you. Rebasing does the opposite, but has other benefits.
  - quickthrower2 5y ago
    It only makes a difference if everything is fast forwarded onto master. If branches are squash merged in (as is common), keeping those merged in branches up to date via merges or rebasing doesn't make much difference to others. If you are chucking all your commits onto master - power to you. That's probably a good pattern (I prefer as much historical data as possible to a 'neat' commit history), but I never see it done because usually master is linked to CI and the idea is is every commit to master should be a valid build.
    - cryptonector 5y ago
      Master or any branch you're aiming to integrate into. Squashing everything is bad because it makes code review and backports harder. Maybe you don't care about backports, but if you care about code reviews...
      - quickthrower2 5y ago
        We code review unsquashed branches. Honestly I just diff the whole thing from where they branched to the tip anyway I rarely find the individual commits useful as there is usually a process of their discovery in that with backtracks etc. that’s a waste of time to review. For example I could review a new class that they heavily refactored in the next commit. I’ve not had an issue with code reviews or backporting. I suspect this is because either out units of work are smaller than usual (no long feature branches) But maybe you are onto something here and I’m missing out on a better way but I’ve not experienced enough pain in squashing on merge to master to contemplate switching to a rebase workflow (which means convincing team members too)