11–20 of 45 posts
> git add -A . > Add everything I’m working on (new and edited files). Bad idea. Extraneous cruft that isn't caught by .gitignore will leak into the repo. Always run git diff and git status first to see what you are about to add.
if something leaks and I need to add to gitignore I'll amend.
there's definitely cases for staging more complicated edits but not in my daily work.
> git add -A . > Add everything I’m working on (new and edited files). Bad idea. Extraneous cruft that isn't caught by .gitignore will leak into the repo. Always run git diff and git status first to see what you are about to add.
I hear you. But nothing goes directly into main. The working branch is not sacrosanct you know what I mean? I'd rather clean up anything that leaks in before merging and a good .gitignore can protect against most noise.
> git add -A . > Add everything I’m working on (new and edited files). Bad idea. Extraneous cruft that isn't caught by .gitignore will leak into the repo. Always run git diff and git status first to see what you are about to add.
This has been my experience as well.
Great article, thanks! I've been using essentially this same subset of commands for many years, and it's worked extremely well for me: does everything I need/my team needs, and avoids complication. I'm glad to have this as a reference I can point people to when they ask for git advice.
I've always heard people talk about how it doesn't scale, but I use rebase like 99% of the time, and have worked on projects with hundreds of ICs. This is the first time I've seen someone explain it in a way where I get it. NO I'M NOT FORCE PUSHING TO MAIN YOU SILLY NILLY! Turns out I'm "squash rebasing." I guess I didn't know I need to specify that.
I do it slightly differently tough. I use git commit --amend to build up a single commit as I go.
git checkout -b blah-feature
# do some work
git commit -m "Main description of my feature"
# do more work
# no -m, and then I just add bullet points for each subsequent change in vim (example below)
git commit --amend
# pulls from remote without merging
git fetch origin main
# adds my single commit to the end of the current main
git rebase main
# push up feature branch for code review
git push
# get yelled at about --set-upstream, and copy/paste that command :-)
Add some new feature
- do some sub task
- do another sub task
- ...The irony, IMO, is that Linus prefers C to C++ exactly because C++ gives developers too much rope.
I finally understand why some people are so against rebase. They're doing it wrong. I've always heard people talk about how it doesn't scale, but I use rebase like 99% of the time, and have worked on projects with hundreds of ICs. This is the first time I've seen someone explain it in a way where I get it. NO I'M NOT FORCE PUSHING TO MAIN YOU SILLY NILLY! Turns out I'm "squash rebasing." I guess I didn't know I need…
I finally understand why some people are so against rebase. They're doing it wrong. I've always heard people talk about how it doesn't scale, but I use rebase like 99% of the time, and have worked on projects with hundreds of ICs. This is the first time I've seen someone explain it in a way where I get it. NO I'M NOT FORCE PUSHING TO MAIN YOU SILLY NILLY! Turns out I'm "squash rebasing." I guess I didn't know I need…
Yah, I don't think anyone minds those kind of rebases. It's when they're done on shared branches like master that they're incredibly messy and dangerous.
"But my feature branch gets squashed anyway"
1. I believe that in itself is a mistake, especially as feature branches get large and, though you say you're all for small feature branches, your commit history says you do something different.
2. You don't clean up that giant merge commit message with all those "WIP" "fixed stupid mistake" comments in there.
Use rebase to keep your workspace clean and main/master comprehensible to your colleagues.