Thanks for the post and detailed examples. I'm glad you mentioned "the controversial" part, because my experience has been against using git rebase especially when merging new pull requests on master branch. You have listed the disadvantages of rebase clearly, and I think having less error prone git flows is more valuable than the "very" clean history. The history is still clean and its useful to quickly see all code changes by PR when going through the merge commit itself. As for the point of "team lead or customer can ask for daily commits", I find that a weird and unhealthy way of progress tracking (what prevents me doing pointeless commits with low value?). Shouldn't the work progress tracking be done on the Jira tickets instead which has my deliverables listed?
Thanks for the post and detailed examples. I'm glad you mentioned "the controversial" part, because my experience has been against using git rebase especially when merging new pull requests on master branch. You have listed the disadvantages of rebase clearly, and I think having less error prone git flows is more valuable than the "very" clean history. The history is still clean and its useful to quickly see all code changes by PR when going through the merge commit itself. As for the point of "team lead or customer can ask for daily commits", I find that a weird and unhealthy way of progress tracking (what prevents me doing pointeless commits with low value?). Shouldn't the work progress tracking be done on the Jira tickets instead which has my deliverables listed?
Thank you for comment. They can ask for daily commits to compare logs with code. For example you can log 3 days but real work was in one or two
That's just silly. People could just break down 2 days work to 3 commits, one each day...
i agree