You can, optionally, specify a branch you want to push if you have outgoing changesets on several branches. Ofcourse these 2 solutions can coexist, having the generic push rule ensuring that you always send for review when pushing to a remote branch, and the custom action for when you want to send a feature branch for review on the integration branch. 1.4.2) issues a hg push -new-branch as needed, so if you create a new branch (as opposed to having two heads on one branch), you just do a regular push ( Repository Push ). Then, instead of clicking "Push", you right-click your commit, and select "Custom Actions -> Push for review". Remember to add Git to your path to enable cmd to use it. Parameters: /c git push origin $SHA:refs/for/develop In SourceTree you can create a Custom Action: Menu caption: Push for review If I use the generic push rule then "feature123" will be pushed for review on "origin/feature123", but what I really want is to push it for review on "origin/develop".
Our integration branch is "origin/develop". I have a local branch "feature123" which is ready for review (i.e. In such a case the generic push rule (mentioned by mozart27) will not work as it always pushes your local branch to the corresponding remote branch. If you have a setup with Git Flow ( ), or similar, you often want to push your local branch to a different remote branch. This difference makes it significantly more difficult to destroy.
You should probably not use this workaround if your submodules are under active/frequent development, but if they're relatively stable, then it should be safe. git push -force overwrites the remote branch, while git push -force-with-lease only overwrites the remote branch if your local copy is aware of all of the commits on the remote branch. Here is a workaround inside SourceTree itself instead of via the command line: Open the SourceTree Options, go to the Git tab and uncheck the 'Check submodules before commit & push' option. Once your changes have been merged into the master repo the number on the Push button will disappear. git push -force would do the job, although git push -force-with-lease is a safer command. This is because it is still fetching from the master repo and the changes you've pushed into gerrit have not yet been merged into the master repo. Note that after a push, SourceTree will still show a number on the Push button that says you still have stuff to push. ( you can now also just do git push without specifying anything else and it will push to gerrit ). In SourceTree you can now push and it will push to gerrit instead of the final repo. the push line i wrote is: push = refs/heads/*:refs/for/*įor clarity here is my remote origin entry in. You should do this via the git config command (tho i did edit the file manually i'm sure that's bad practice). Update: it turns out that you need to add a push entry under remote origin in the. Hope this helps even tho it's late to the game.
Sourcetree force push update#
I will update this post once I've figured that out.
The problem I have now is that the 'refs/for/master' value doesn't persist. This appears to have properly pushed the commits into Gerrit for me. Type in the new remo branch name - which would be 'refs/for/master' for me.Click on the remote branch name under the "Remote Branch" column (mine is presently 'master').I say this, because although I've experienced the issue being discussed with SourceTree before, I've never actually experienced any problems wih BitBucket itself before).I believe the answer provided by atlassian says to change the name of the remote branch when you see the Push dialog. To set this up, you can create a Custom Action in SourceTree: Tools -> Options -> Custom Actions Click Add Set Menu caption, e.g. (Also, AFAICT, the root of the problem is definitely SourceTree, and neither BitBucket itself nor anything else at Atlassian's side of things. If you’re using Atlassian SourceTree with a git repository and you do a local commit but then realise the message was incorrect, you can amend it before you push it to remote. Sharing this information, not to have a go at SourceTree, nor to complain, but simply because it might indicate a possible solution for others in the same situation as my own (in the sense that maybe that hadn't yet considered using Git bash to handle all their Git-related business). Would be great to be able to use SourceTree as intended, but until such a time comes, I'll just continue using Git bash (which has thus far worked perfectly for me, without any major problems) to interact with BitBucket (plus any other Git-related services and platforms). Not really a true "solution" to the *root* of the problem being discussed, but in my case, since my previous reply to this discussion, I've long since just been going about all my Git-related business via Git bash, which has worked out perfectly for me.
0 kommentar(er)
