We have a relatively simple version control process: master branch, dev (otherwise known as integration) branch, and our individual branches for every user story.
We check out from dev, branch at the beginning of a new user story to a new branch and once we finish, we merge again to the dev branch.
There is the opinion that while developing a story on a new branch, we should not pull down latest changes from dev branch and then merge those changes into the branch for the user story.
Why is that bad? If once you pull down latest changes from dev into your branch, you then merge your branch back to dev once you are completely finished with your story?
Best Answer
This is likely the result of one of three situations:
For the first, which seems likely, it's a matter of laziness. If you have an active dev branch you will have to pull multiple times on a feature and potentially multiple times per day. The solution is recognizing that resolving small merge conflicts frequently is much easier than a massive merge at the end.
If the developers are afraid of git merges, for whatever reason, it might be they just do something horribly hacky. Full disclosure: my first experiences with git I had no idea what I was doing (now I do) and for merges, I normally did a "manual" merge without even resolving the merge diffs. If your team is similarly naive about how git works, they might be doing this out of desperation.
And last, if your codebase is the root cause, you might be out of luck. In this sort of situation it is hard to keep your local updated because you are constantly getting breaking changes to your code. Refactoring may be the only way.
Ultimately though, figure out why your devs want to do that. It will make your easier life generally speaking to make a practice of doing this.