Old File Versions Included into Commit

[Wayne Hans]

User2 stages changes to one file, commits, then pushes to repo called "processes-user2". User2 creates pull request for User1 to review.  While reviewing, User1 (me) realizes that commit includes other files that are a version old and should NOT be included. 

1 - Why are these files (other than the one file that was staged) in the commit?

2 - What options do I have to exclude these? (Shouldn't I have the option to simply exclude these when merging (via SourceTree or BitBucket)?

3 - Is there paid support available that I would be able to explain my setup and ask what I'm doing wrong?  I've been using this software for some time now and it still isn't behaving quite the way I understand despite viewing many tutorials.

Our setup includes 4 users (one of which is an admin).  We have a central repo which only the admin has write access to.  Then each user has their own repo with read/write access.  My thought was that when a user makes a change to a file locally, they stage, commit, and push to their repo.  Then create a pull request for admin, who reviews, then pushed changes to the central repo.  Is this not the correct usage?  If anyone can answer any of these questions, I'd greatly appreciate it.

[minnsey]

Hi,

I'm afraid its impossible to tell from here exactly why those apparently old files are included in the PR, but essentially it will be git determining that they are in some way 'newer' than the version in your central repo. I'm guessing you are effectively using forks of the central repository for each user.

For what it is worth I believe you can achieve what you want with a simpler model, of just one repository, rather than each user having their own repo.

If you have a single repository with, for example, the master branch being the one under strict control, then you can use Bitbucket's Branch Permissions to control who is allowed to merge changes to that controlled branch. https://confluence.atlassian.com/bitbucketserver/using-branch-permissions-776639807.html

Each user can clone this single repository and then create feature branches for their work and commit/push/pull as they like then create PRs prior to merging back to the controlled branch.

These PRs can have additional controls to ensure their quality, again via the branch permissions.