🔥 Two Git commands that have made me a better developer:
– `git commit` without the `-m` option
– `git add -p`
The former forces me to write a good multi-line commit message, and the latter allows to stage changes partially in an interactive mode.
Now that you've learned to commit the right way, you must be thinking what to write in the commit message?
That's easy! Follow the Conventional Commits standard. Make sure to sell it to your team as well.
@bugaevc That's golden! I also use `git fetch --all && git rebase upstream/master` to update my fork before a PR. ❤️
@nikoheikkila pro tip: you can use `git pull --rebase`, and you can even configure `pull` to use `--rebase` mode by default
@nikoheikkila I use it too and I prefer `git add -i`.... However, I am extra cautious while using `git add -p / -i`. One can easily omit changes which work locally, but breaks when a partial commit is pushed. Local tests won't spot the difference either.
@nikoheikkila Thinking a bit more, if we do it like this:
git add -i
git stash # uncommited changes
# run tests, for eg. pytest
git stash pop
then things would be consistent.
@ashwinvis Agree, though I tend to be lazy and fix any failing build with `git commit --amend --no-edit` in case a partial commit borked.
@nikoheikkila `git add -p` might be my most used git command. I almost think it should be the default "add" when you're staying changes because it makes you completely aware of what you're doing.
@jwkicklighter Indeed, all the (good) Git GUIs also present you a view where you can highlight changes to stage.
@nikoheikkila I am going to tell you something that, should you choose to pursue, will change the way you git and your perception thereof.
@nikoheikkila You will operate gut with *at least* 10x efficiency and speed. Even more, magit will make you *want to* interact with git instead of dreading merge conflicts and garbage collection. Give it a shot. You will not be disappointed.
@nikoheikkila Absolutely! Building on that, a key reason I stopped considering adopting VS Code is because it's commit message input encouraged tiny commit messages. And seeing commit messages from people using that tool, it shows. They are not communicating intention and reasons.
@takeonrules Good point! I've set VS Code as my Git editor (using 'code -r') to write commit messages so I'm cheating a little bit.
@nikoheikkila When I was poking around with VS Code, I added `cmd+k cmd+c` to write commit messages; It allowed me to stay in VS Code to do commits, and I don't know if this works now.
(I've since switched to Emacs and am loving it; I spent a week practicing the basics and have built out my .emacs file to reflect what works for me.)
@nikoheikkila I'm (very) new to Git. Does committing without -m automatically go into multi-line message mode?
@konc Yes. You might also want to use `git commit -v` so it displays the changes made in the commit message window.
@nikoheikkila Nice, thanks! I'm still a bit confused about the -p thing, but I guess I'll have to just try it out on my own.
You can also do:
- git stash -p
It is really useful if you find yourself wanting to selectively stash parts of a file.
@nikoheikkila may I also suggest -e -m for commits?
Let's you specify a short message, but then drops into your editor.
We have a lot of precommit hooks, so I find this works best for me, since usually I forgot what I was committing when the hooks finish.
@ketmorco Cool, I thought `-m` would always skip the editor. Will be using this, and yeah, the use case with hooks is very valid.
This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!