u: The -u flag creates a tracking reference for every branch that you successfully push onto the remote repository. force: The -force flag is responsible for overriding the protective measures of the remote repository to ensure that your changes are forcefully pushed. UML diagrams, license headers, etc., so in that case, you could then pull the changes on origin develop to upstream develop, if needed.The options in the git push -force -u origin command are described as follows: Note that this may actually add commits compared to upstream develop if there is anything automatically added by a commit, e.g. Use a CLI tool such as Oh My Zsh to check that your branch is green indicating that there is nothing to commit and the working directory is clean (which is confirmed or also verifiable by git status). Note that instead of upstream/develop you could use a commit hash, other branch name, etc. Git commit -m 'Reset to upstream/develop' With all the changes together: git commit -m 'Saving work.' Otherwise use a mergetool with git mergetool. To preserve branch_name's conflicting changes. While use git merge -s recursive -X ours develop

Then if you need to merge these changes with another branch while where there are any conflicts, preserving the changes in develop, use: git merge -s recursive -X theirs develop I'm using the develop branch as an example, but it can be any existing branch name. On GitHub, you can also checkout the branch with the same name as the local one, in order to save the work there, although this isn't necessary if origin develop has the same changes as the local saved-work branch. of the original GitHub repo that you forked from, and/or git remote add origin. If you want to reset your local branch to the latest commit in the upstream branch, what works for me so far is:Ĭheck your remotes, make sure your upstream and origin are what you expect, if not as expected then use git remote add upstream, e.g. Otherwise in future avoid pushing to a branch that others push to, instead checkout and push to the said branch via the checked out branch. So the above should only be used if you have happened to commit changes to a branch that others have committed to, and need to reset. Same thing for other branches that others contribute to. Thus you only need to pull changes, not push any changes from master. Note that it is good practice not to make changes to your local master/develop branch, but instead checkout to another branch for any change, with the branch name prepended by the type of change, e.g. This is what I use often: git fetch upstream develop If you accidentally do this on the current branch (and git will not keep you from this), you may become confused, because the new branch content does not match the working tree, which did not change (to fix, update the branch again, to where it was before). Use caution when doing this, though, and use gitk or a similar tool to double check source and destination. This is especially helpful if multiple branches need to be updated to new remote heads. It simply moves mybranch's head to another commit, whatever is given as the second argument. This method leaves the checked out branch as it is, and the working tree untouched. If branch 'mybranch' is not currently checked out, to reset it to remote branch 'myremote/mybranch''s head, you can use this low-level command: git update-ref refs/heads/mybranch myremote/mybranch Since there is at least one 'duplicate' question, Reset branch completely to repository state, which does not assume that the branch is checked out, here's an alternative: In comments, OP hap497 clarified that the branch is indeed checked out, but this is not explicitly required by the original question.

Previous answers assume that the branch to be reset is the current branch (checked out). Otherwise, you should be aware that it's not recommended to push into a non-bare repository (and not into the currently checked-out branch, in particular). Did you recently push into your local repo? If not, then no worries - something else must have caused these files to unexpectedly end up modified. Note that the first example assumes that the remote repo's name is 'origin' and that the branch named 'master' in the remote repo matches the currently checked-out branch in your local repo.īTW, this situation that you're in looks an awful lot like a common case where a push has been done into the currently checked out branch of a non-bare repository. Now your work is saved on the branch 'my-saved-work' in case you decide you want it back (or want to look at it later or diff it against your updated branch).

If you want to save your current branch's state before doing this (just in case), you can do: git commit -a -m 'Saving my work, just in case' Setting your branch to exactly match the remote branch can be done in two steps: git fetch origin

Force git pull remote branch