It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Old File Versions Included into Commit

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.

1 answer

0 votes
minnsey Atlassian Team Feb 27, 2018


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.

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.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published in Sourcetree

Sourcetree for Windows - CVE-2019-11582 - Remote Code Execution vulnerability

A vulnerability has been published today in regards to Sourcetree for Windows.  The goal of this article is to give you a summary of information we have gathered from Atlassian Community as a st...

4,927 views 0 12
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you