I am new to Git and I have been tasked with setting up Git for a new project. They already have Stash licenses, and I would ideally use that for the back-end repo synchronization and the integrated pull request feature for code reviews.
I just installed SourceTree for Windows as well and it seems slick, a polished client GUI for sure. However, I am a little murky on how best to setup the workflow between stash and sourcetree in regards to Pull Requests.
So just for an example and not intended to represent our future branch structure... say I have a Stash project/repo called master. I then create a local only branch called "test_branch", branched from my local master in SourceTree. I then commit a simple change to my "test_branch", say a new file. So now I have a remote master, local master, and a local test_branch which is one change ahead.
So I am assuming... the "test_branch" MUST be pushed to the remote in a corresponding "test_branch", for a pull request to take place? Or should this work with a local only feature branch to remote master? Anyways say for sake of argument, I push the "test_branch" separately to my stash repo first, and now I have a local and remote "test_branch" that are in sync, and both 1 change ahead of my local and remote master. At this point, if I in the interface choose "Repository->Create Pull Request", and pick "test_branch" as my local branch, and "master" as my remote branch, and then click "Create Pull Request on Web", I would expect it to open up a browser window, launch stash's web interface, and bring up a pull request creation page, with the basic information for the request pre-filled.
Instead, all I get is the main stash page, and on the backend it just pushed my local "test_branch" changes directly to the remote master without asking. It completely ignored my request for a "pull request".
So either I have something configured wrong, or I have a bad assumption about how I should be using the two together. I notice in the "Create Pull Request" form box in SourceTree that it says "Latest commits will be pushed before creating pull request"... that sounds wrong?
As an alternative workflow, is it better and should it be possible, if I instead first merged my local only test_feature branch to my local master, and then create a pull request from my local master to the remote master? From the interface of the pull request in Stash this doesn't seem possible... but somehow this sounds better.
Separate, but nice to know:
Any guides on best practice for using this two together would be great, if anyone has links.
Also does anyone know of any good alternatives to StashBot for integrating Stash with Jenkins seamlessly?
After you set this up, the create pull request option should work.
Hi, thanks for your answer! My "Host Root URL" field was not using the root but rather the specific repo. So now it does go to the "Pull request page" as expected. However, it's still not working correctly.... 1) Using my test setup as described in OP, with a "test branch" and a "master branch" created both locally and remotely on the same stash repository; the "Create pull request" from "Test branch" to "master" seems to simply push the changes to master before loading the Pull Request page. This is the exact opposite of what I expected... I thought the point of a pull request was to ask to merge, from a branch with newer changes to another branch, blocking the final commit until approved by the reviewers. 2) On the "Pull Request" page, it didn't properly select the source branch. It just has source and destination set as master. Is this expected behavior, and you have to choose it yourself each time? Not a big deal, but just seems wrong. Of course based on point 1 above, the master is also already up to date with my test branch changes. Separately, am I correct in assuming the test branch MUST be cloned and available on Stash directly, or is there a way to do a pull request from a purely local branch to stash remote branch? If it must be cloned remotely, must the cloned test branch be on the same repository in stash, or can it at least be in another repository on the same stash?
Some further clarification and some confusion on terminology... (which I think is all I'm missing here) If I setup my local "test_branch" to track "origin/test_branch" (which it was originally of course), and then go to repository->create pull request and choose "local branch" -> "test_branch", "remote branch" -> "master", then it incorrectly first commits my changes from test_branch to master, and loads the wrong source in the pull request as listed in my previous comment. I noticed it also changes which remote branch which my local branch tracks to "origin/master". If I instead do a pull request with the field "local branch" -> "test_branch" and also "remote branch" -> "test_branch", then it loads the pull request with every field as expected. It also hasn't committed anything (Can do the same it seems by right clicking on "test_branch" in sourcetree and choosing "create pull request". Didn't see this one before :) ). So... I am guessing this is all by design, and I'm just misunderstanding the terminology? Somehow the pull request to master is just assumed, and the designation for local and remote here is just to match up the source repo for Stash? Which is why it says "Latest commits will be pushed before creating pull request" in the "Create Pull Request" modal dialog? Assuming this, then my other question at the end of my last comment... I would assume confirms my assumption that my local feature branch MUST be replicated in Stash, in order to do a pull request. Is there an easy way to do this? Maybe even from within sourcetree? I need to write up a user guide for our other programmers, and I want to make this as easy as possible so they aren't constantly switching back and forth between the stash webinterface and sourcetree (except for of course when completing a pull request).
The tracking relationship defines which local branches get synchronised with which remote branches when you push/pull. Git allows you to set up a local branch X to track a remote branch Y, but it is very much not recommended. E.g. local master should track origin/master and so on. Most probably the create pull request option uses these tracking relationships to figure out the default values of the source/target branch on the web interface when it launches the dialog.
Thanks, I do understand what you mean about tracking, but am confused by the modal dialog for "Create Pull Request". I guess I am right in assuming that the local and remote fields there are in fact an additional opportunity to change which remote branch the pull request will use as a source? Then it re-tracks the given local branch to the new remote branch, does a git push to this new track target, and then launches the web interface? I find this highly unintuitive... because I am not understanding how it knows to assume "Master" is the target branch given my new understanding. I mean originally it was branched off of master.... but how is that knowledge maintained? Also if someone can answer my other questions related to the need for the feature branch to be cloned locally and remotely, and the ability to clone the feature branch into stash from sourcetree, that would be helpful.
Pull requests can only be made from/to branches which are already pushed to the server. (I have never even tried creating a pull request using an unpushed branch.) About the dialog: not sure what happens if you change the local/remote, but when it loads the dialog, it should be correct if the tracking relationship is correct. BTW the easiest way to create a PR is by right clicking the branch name and selecting "create pull request". Then you don't even see this dialog.
As a project manager, I have discovered that different developers want to bring their previous branching method with them when they join the team. Some developers are used to performing individual wo...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs