I have been in active software development for the better part of the last year and a half. For the majority of that period, I've come to appreciat...
For further actions, you may consider blocking this person and/or reporting abuse
Thanks for sharing. I rarely use
git rm- I usually usermand commit. And I rename the path to something else if I need to keep it.I added to my notes regarding cached and -r flags though.
I don't need to use
git branchfor a new branch. Your usage ofgit checkout -bis much more common and practical.And pro tip. I rarely use
addif a file already exists...If i make file changes, then i do this for the directory (or use a dir name).
You can also check the comments in your commit message editor window if you need to see which paths are going to be committed. Or use
git statusbefore you commit.Here I commit changes to package.json and package-lock.json without using
addbut preventing changes in other files getting commited.this is a new way of looking at things. Really helpful. Thanks Mike.
That's a very nice list! The bit about descriptive commit messages and pull requests is especially important. It's not very nice navigating a codebase where half the commits are "updated stuff" and "implemented thingamajig".
Here's a couple of more commands if you want to show off a bit to other developers in your team (or maybe make your and your teams lives a bit easier 😄):
Comes in pretty handy if you're tired of having to write git checkout [branch] every time you want to change branches. Can just do git co [branch]. You can of course create aliases for other stuff like commit, etc.
Another cool command is rebase. Many people use it mainly for rebasing master onto a feature branch but you can also use it for cleaning up commits on your feature branch. Here's a pretty cool article showing how to do it.
Thanks! I didn't know this. I tried it out and works like a charm!
Just a query here. So we take out a branch from the 'main' as 'code fix'. Once done with the changes we would commit & push the branch to the repo. Checkout the 'main' branch and then merge the 'code fix' to the main
Am i saying this right or missing out on something?
Yeah, you're saying it right. But the appropriate way is to push it to the repo and wait for it to be merged. The only reason you'd merge locally is when you're working alone. But it's advisable that you push to the remote, once it's been merged then you can pull from the master.
Nice read.....you made it so easy to understand 😀
Useful list here for Git newbies and experienced users alike.
Very well explained Teddy. Nice one.
Nice one! You may be interested in this one as well as explaining some of the cool features behind git log/blame: dev.to/bmuskalla/git-archeology-1nl3
nice article...