How well do you know GIT?
Learning git is one of the most important things that programmers have to know. You need to know how what it is, how to ...
For further actions, you may consider blocking this person and/or reporting abuse
For point #2 good commit messages I started writing why I made the change rather than what the change is at the recommendation of a coworker. I've found it naturally provides a more meaningful commit history and kinda tells a story.
"Updated model to include license number" becomes "License number is tied to registration".
You already know I added a property by looking at the code change so comments like the former are redundant.
I would have no idea what you did based on your "License number is tied to registration".
You can do something like: "Update model to include license number" and then write your "why" in the description part of commit message. Just my 5 cents :)
You make a good point - that wasn't the best example. Maybe something like "Added license number to model because it's tied to registration" would be better. I've found that generally putting reasoning behind the change helps a lot for the code review process and for going through old commits. I see lots of commit messages that are like "Added x" or "Removed y". It drives me nuts because I have to investigate further if I'm looking back through old commits when investigating something for example. Messages that give the reasoning behind the change saves time for things like that because you can hone in on the thing you're actually looking for or if you're doing a review it gives a clearer picture if you're not as familiar with the issue as the one who worked on it.
Let me give #2 for good commit messages a million upvotes. It's worthy of its own post. In fact, I recommend everybody read a good "how to write good commit messages" post, such as this one:
chris.beams.io/posts/git-commit/
I will note, ironically, that your "good" example ends in a period. It's generally considered good form to not end your commit subject line with punctuation. But you should use proper punctuation in the body of the commit message. Yeah, we're a weird bunch. As such, I'm usually pretty forgiving about whether the first letter is capitalized, too, and just recommend that everyone follow the style of the project, which is good programming advice in general.
I don't think creating aliases is a good practice. Creating yours makes your Git commands obscur to others (or worst, to you). Do not forget, your shell interface can autocomplete things.
Nice recap tho'! ;)
On the rare occasions that I've had someone looking at my screen and curious about how I just did something with git, I've been able to explain that I have an alias for it. I can then pull up my aliases to explain the alias they just saw.
Aliases are powerful tools that can give you the power to do more with fewer keystrokes. If there's an alias that I can't remember, I have an alias that lists my aliases (this is still generally faster than looking at the documentation). When I switch branches, it automatically fetches.
They also save valuable space in my head so I don't have to memorize the formatting options for
git log --pretty. The flag name there may even be wrong, I don't know and I'll only care the next time I need to format the output ofgit log.TL;DR
Aliases are there to increase my productivity and be as memorable as possible, not to be clear.
I understand your point of view, but it's not mine as explained in my previous post.
I prefer to have a
gitconfigwithout alias and to use a « more graphical » Git interface. I use the Git CLI and magit (which is full of default keybindings and integrated into my code editor of choice). This allows me to avoid black magic Git aliases.If you want to have a pretty
git log, the best way is to config your log output like this:You can found my
gitconfighere, certified alias-free ;pI'll give it a look, I'm sure I'll see some settings that I like. I'm probably not going to give up using aliases since I've yet to find a more graphical interface that I like better than the CLI. But if I can find some defaults that allow me to remove an alias or two, it's one less alias to have to worry about.
No, and in shared repositories I own, I disable the ability to force push. I call it the "No Jedi Rule".
The reason not to allow force push in the general case is that it allows someone to rewrite history. That should be discouraged. It is occasionally necessary to do, such as when something is added to a repo that could cause a security concern, but it should be fixed with the assistance of the repository owner or a designated administrator. Changing history will often invalidate downstream repositories, and allowing force push in general would allow these downstream repos to push the "bad" history back to the shared repo.
For #2 I like to refer to this post:
How to write a good commit message
Chrissie ・ Jul 30 ・ 2 min read
As for #4, its important to know about .gitignore, not just for web development.
Nice post!
git add -p, best advice, few of us really use it.However, the Git CLI is not the best interface to seriously use it :p
For point two I prefer a non-capitalised subject and scope if possible. An example of my commit would be:
refactor(login view): add mobile responsiveness