You know, I work with a lot of people with different work styles, many of which violate one or more of these rules, and my idea of not being a dick is to not act they are terrible people for e.g. putting TODOs in code. We don't really need yet another list of What Everyone Else Is Doing Wrong.
Sometimes it makes sense to have big changes in one commit instead of 10 commits that are logically one change.
> Never commit directly to develop/master, this is a classic git dick move.
> Rebase is your friend, merge commits are your enemy.
In one paragraph the author tells us not commit directly into the main branch, in the other one tells us not to do merges. The reality is that in some cases it makes sense to commit without branching first and sometimes it is nicer to rebase then to merge, however there is no one size fits all solution which this posts seems to suggest before it contradicts itself.
> Never commit directly to develop/master, this is a classic git dick move. Doing this side steps any code review or ci build safety checks you should have in place. Thus hugely increasing the chance of commiting broken code and breaking everything for everybody else when they pull down from remote.
I don't understand how are these things linked together, I think the author is confusing development process with version control and making absolute statements based on his specific process.
I also don't get how does the overuse of the word "dick" adds value to the content.
Overall this article is full of statements that are false in general, they are tied to the way the author works.
2 comments
[ 3.6 ms ] story [ 15.0 ms ] threadSometimes it makes sense to have big changes in one commit instead of 10 commits that are logically one change.
> Never commit directly to develop/master, this is a classic git dick move.
> Rebase is your friend, merge commits are your enemy.
In one paragraph the author tells us not commit directly into the main branch, in the other one tells us not to do merges. The reality is that in some cases it makes sense to commit without branching first and sometimes it is nicer to rebase then to merge, however there is no one size fits all solution which this posts seems to suggest before it contradicts itself.
> Never commit directly to develop/master, this is a classic git dick move. Doing this side steps any code review or ci build safety checks you should have in place. Thus hugely increasing the chance of commiting broken code and breaking everything for everybody else when they pull down from remote.
I don't understand how are these things linked together, I think the author is confusing development process with version control and making absolute statements based on his specific process.
I also don't get how does the overuse of the word "dick" adds value to the content.
Overall this article is full of statements that are false in general, they are tied to the way the author works.