Git, a distributed version control system, offers a variety of ways developers can integrate changes from one branch into another: git merge and gi...
For further actions, you may consider blocking this person and/or reporting abuse
Wondering...
Assuming we are talking about a private repository with, say, 10-20 member team, it doesn't hurt to follow the "git --ff-only" pattern of development, for which you would need to rebase even the "shared" or "common" branches. In this case, we expect the team members to know about "git pull --rebase" when updating their local copy of those shared branches.
I like this pattern for the same reason: linear history. I don't see any disadvantages other than the fact that the commit date is almost always different than the authoring date.
Anyway, I am very much interested in any n all feedback here.
Thanks for your thoughtful comment and perspective on the use of the "git --ff-only" pattern in a team setting. It's indeed a valid approach, especially in private repositories with a sizable team.
Personally, I tend to prefer the use of git rebase, mainly because it allows me to keep the changes from the source of truth, which is usually the master branch, intact while incorporating my branch. This helps in presenting a cleaner and more sequential history for me.
The preference for a linear history is a subjective matter and often depends on the specific needs and workflows of a team. The advantages you mentioned, such as a clean history, can be significant, and it's great that you find value in this pattern.