So I make my file changes, but when I try to push them source tree complains that some one else pushed before me.The files are different,yet I am forced to merge the changes. Some times I have to backup and reset my workspace before it can allow me to push again
Is there no way to force the push?
Open SourceTree Preferences
Tab: Advanced
Third checkbox: Allow force push
Enable the checkbox and close Preferences.
Next time you push, there will be an extra checkbox: Force push.
Checking it will also display an additional Confirm Force Push dialog box before the force push is actually performed.
Even though the files are different, you have to perform a merge or a rebase before you can push. The commits from your current working branch have to be merged into the current branch that exists on the server before you can update it. You're merging the branches, not the files.
Using the "force push" command does not force your commits to be applied in addition to what is on the remote branch - it forces your commits to replace the commits on the remote branch. Using this option would throw away all of the commits that had been made by the other user.
Because this is a destructive operation, SourceTree does not include GUI access to the "force push" command. Here's what Steve Streeting from Atlassian says about it:
SourceTree doesn't expose force push because it's almost always not what you want to do.
It means that someone else has pushed before you. What you should be doing is pulling their changes, merging them (or rebasing your changes on top of them), and then pushing.
Related
I've been using the git plugin for Eclipse for months without problems.
But lately (after a bad forgotten manipulation, probably) when I switch branch using the contextual menu "Team -> Switch To", the modifications are pushed to the last branch.
Now, each time I'm doing a push or pull after a switch, I need to remember to modify the ref mappings.
A temporary fix has been to set the mappings in "Configure push for remote origin" to :
refs/heads/*:refs/remotes/origin/*
but I prefer to avoid pushing all branches each time.
Is there a way to go back to the usual behavior where the current local branch is pushed to the correct remote location after a switch, without having to modify the ref mappings each time?
The solution was actually simple:
I just needed to remove all ref mappings declared in the push configuration. The system pushes the current branch to the corresponding one in the remote.
How do I go back to a previous build? For example going back to the July 30 state?
There are a number of ways to functionally undo a series of commits in Git. But given that the branch in question is published, and likely shared by several people, I would recommend using git revert here. git revert adds new commits on top of your current branch which undo previous commits. These revert commits can be thought of as mirror images of what was done in previous commits. Something like this should work:
git revert 00bfe1b^..a013402
This should add two commits, one to undo the Aug-9 commit and one to undo the Aug-13 commit.
As a side note, you could have also done this:
git reset --hard HEAD~2
This would have completely nuked the two commits on top of Jul-30. However, this involves rewriting the history of the branch, which isn't desirable if other people may already be sharing this branch with you. In this case, just play it safe and use git revert.
To view (browse the file tree) the repository state at a certain commit given at least the first four characters of commit's hash, the following URL schema for GitHub can be used (at the time of writing):
https://github.com/{username}/{repository name}/tree/{hash}
If you want to hard reset your GitHub repository to a specific commit, do a git reset --hard {hash} in your local (stored on your computer) repository then force push it to a remote repository (like GitHub) via git push --force.
Of course, hard resets are dangerous. You can git revert or git reset and stash unstaged changes, and I'm sure there are other ways to achieve similar effects.
I am using the git plugin for eclipse and I have noticed a problem with it and hoping this is a simple configuration change. Can anyone help?
When switching branches, the uncommitted changes are being merged across onto the newly checked out branch (only in certain circumstances). It seems as if this happens every time when it is "safe" to do so. The way to recreate is:
Create feature branch "branch1" from remote repository
Create feature branch "branch2" from same remote repository
Make changes on "branch2" and don't commit changes.
Switch to "branch1"
a. No confirmation message is shown.
b. The uncommitted changes from "branch2" are merged onto "branch1"
I want to be able to force the commit message to appear (just like it does using git-bash). Is this possible?
To my understanding, this behavior is intended by EGit: a checkout is performed as long as the files to be checked out do not collide with the working directory. And uncommitted changes are left as they are.
If you think EGit should offer a different strategy of handling uncommitted changes I suggest to open an enhancement request: https://eclipse.org/egit/support/
In the meanwhile, you may want to (manually) stash uncommitted changes prior to switching branches. That's what I see most people do in this situation.
I started using SourceTree few days ago and after I committed and pushed my changes to the remote GitHub repository, the numbers on the buttons remain the same, for example if the number on the push button becomes 3 when I committed a change, after I pushed it; it needs to be 0 or empty. But that's not the case here, it remains the same even though it has successfully been pushed. I also checked that my changes had been pushed using a web browser by going to the GitHub site. Is it because of the branch that I have pulled from and am pushing to are different or something else? Can any one please help cause I don't understand it... Thanks!
The numbers shown on the right hand side of the Branches panel reflect how many commits ahead or behind the Tracking Branch you currently are. If the numbers aren't what you expect, you should verify that the branch is tracking what you actually want.
You can verify the tracking branch by right clicking your local branch (as depicted below) and expanding the Track remote branch menu item. Finally, if you want to change the tracking branch simply click the new target from the list and Sourcetree will update accordingly. Hopefully that helps make sense of the disconnect that can happen when you rename branches and provides some details around why it happens and a simple way to resolve.
The same thing also happened to me too, I was working on branch I had push everting but was keeping appearing one unsend Push and miraculously also appear unsend Push on Master.
So what did was the same as Hristo Staykov and Sammie remove the Master branch from my local computer, since I had one miraculously unsend Push on Master did need to run this line terminal to remove the branch:
git branch -D master
And then Repository > Refresh Remote Status
I simply use the keyboard shortcut from the Repository menu:
CTRL+ALT+R (or control+option+R if you prefer)
My guess is that the shortcut would be the same or at least similar on Windows. Just look for the option called Refresh Remote Status under the Repository menu.
I am using Sourcetree for Windows for a git-repository and would like to undo an unpushed commit.
Is that possible? If I do "revert commit", it creates a second commit which reverts the first commit, but I don't want the first commit to appear at all in my source control.
I could also delete my local repository and pull it again without my local commit, but maybe there's another way?
Right click on the commit you like to reset to (not the one you like to delete!)
Select "Reset master to this commit"
Select "Soft" reset.
A soft reset will keep your local changes.
Source: https://answers.atlassian.com/questions/153791/how-should-i-remove-push-commit-from-sourcetree
Edit
About git revert: This command creates a new commit which will undo other commits. E.g. if you have a commit which adds a new file, git revert could be used to make a commit which will delete the new file.
About applying a soft reset: Assume you have the commits A to E (A---B---C---D---E) and you like to delete the last commit (E). Then you can do a soft reset to commit D. With a soft reset commit E will be deleted from git but the local changes will be kept. There are more examples in the git reset documentation.
If you select the log entry to which you want to revert to then you can click on "Reset to this commit". Only use this option if you didn't push the reverse commit changes. If you're worried about losing the changes then you can use the soft mode which will leave a set of uncommitted changes (what you just changed). Using the mixed resets the working copy but keeps those changes, and a hard will just get rid of the changes entirely. Here's some screenshots:
If you want to delete a commit you can do it as part of an interactive rebase.
But do it with caution, so you don't end up messing up your repo.
In Sourcetree:
Right click a commit that's older than the one you want to delete, and choose "Rebase children of xxxx interactively...". The one you click will be your "base" and you can make changes to every commit made after that one.
In the new window, select the commit you want gone, and press the "Delete"-button at the bottom, or right click the commit and click "Delete commit".
List item
Click "OK" (or "Cancel" if you want to abort).
Check out this Atlassian blog post for more on interactive rebasing in Sourcetree.
If You are on another branch, You need first "check to this commit" for commit you want to delete, and only then "reset current branch to this commit" choosing previous wright commit, will work.