One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
Document version control sucks. Git is intended for programs, natural language and rules do not operate the same.
Here we agree.
Git is a communication tool
I do spend a lot using git to craft my changes.
I guess my question would be if that's really the best communication tool you have at your disposal and the energy you spend rewriting your git history would not be better spent elsewhere.
It seems to me that Pull Requests are much better ways to discuss things, and you can squash the end result and be done with it.
If there are issues left to be addressed, the issue tracker seems a better way to do it.
If your commit messages contain important notes for your colleagues, they should probably moved to your internal Wiki where they can be more easily found and udpated later.
For the users and new contributors of your projects, good communication is done via a good README, your blog posts describing it and the documentation website.
So yes, if you had unlimited time and energy, it's better to have a nice git history than a messy one.
But in real life we don't and I would argue that git communication is less important than all the others I cited.
I work in a distributed environment. Clients get custom builds with unique integrations. So my time spent is very much benefits the needs to distribute changes.
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
I am happy to hear that such fine grained effort is worth it in your context.
In general I think all "best practices" exist because they proved to be useful to some people, enough so that they made the effort to write and talk about it. The issue arise when you see some cool technique that proved useful for Facebook or Google, and an inexperienced team adopt it without reflecting on whether it has the same main pain points than Facebook or Google.
TL:DR it always depends on the context
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Here we agree.
I guess my question would be if that's really the best communication tool you have at your disposal and the energy you spend rewriting your git history would not be better spent elsewhere.
It seems to me that Pull Requests are much better ways to discuss things, and you can squash the end result and be done with it.
If there are issues left to be addressed, the issue tracker seems a better way to do it.
If your commit messages contain important notes for your colleagues, they should probably moved to your internal Wiki where they can be more easily found and udpated later.
For the users and new contributors of your projects, good communication is done via a good README, your blog posts describing it and the documentation website.
So yes, if you had unlimited time and energy, it's better to have a nice git history than a messy one.
But in real life we don't and I would argue that git communication is less important than all the others I cited.
I work in a distributed environment. Clients get custom builds with unique integrations. So my time spent is very much benefits the needs to distribute changes.
Git and Other Communication Tools
Jesse Phillips γ» Jan 9 '19 γ» 1 min read
Git provides every line with a comment about its existence, this is something not provided by other tools, only support it.
Why was this bug introduced?
Jesse Phillips γ» Jan 11 '19 γ» 1 min read
I am happy to hear that such fine grained effort is worth it in your context.
In general I think all "best practices" exist because they proved to be useful to some people, enough so that they made the effort to write and talk about it. The issue arise when you see some cool technique that proved useful for Facebook or Google, and an inexperienced team adopt it without reflecting on whether it has the same main pain points than Facebook or Google.
TL:DR it always depends on the context