SJW <shannon.whi...@gmail.com> writes:
I have a `master` branch which is in sync with our LIVE site
I have a `staging` branch which was in sync with our STAGING
site I created a new branch `feature-branch`, made some changes
and merged it into `staging` branch for testing
We have decided that we don't want these changes.
So I performed a git reset on the staging branch:
$ git reset XXXXXX (hash of last commit before the
feature-branch merge)
This left the branch with a load of files "not staged for
commit" - So resetting the branch didn't actually achieve the
desired result.
So I performed a hard reset:
$ git reset --hard XXXXXX (same hash of last commit before
merge)
This resulted in my working tree being clean - perfect. Exactly
what I wanted.
So I tried to push the branch to the remote server to "wipe the
latest update" but I get this message:
! [rejected] staging -> staging (non-fast-forward)
error: failed to push some refs to
'ssh://xxx.xxx.xxx.xxx:xxx/git/staging.xxx.xxx.xxx'
hint: Updates were rejected because the tip of your current
branch is behind
hint: its remote counterpart. If you want to integrate the
remote changes,
hint: use 'git pull' before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help'
for details.
Now, I would assume if I perform a `git pull` I'm just going to
be in the same position I was in at the start, with a sh**load
of files "not staged for commit"
So, please help me understand.
1. How do I make the remote `staging` branch realise that my
local branch is the correct branch and is up to date and not
make me integrate remote changes which I have already removed.
What you are trying to do is to rewrite history on the central git
repo. While git allows doing that, it does require you to signal
that you are completely sure you know what you are doing. Look at
'--force' and related flags in 'git push --help'.
If you are working on this repo by yourself you can pretty much do
whatever you want, but if you work with others and they have based
any of their work on the 'staging' branch after you merged in your
'feature-branch', then you should look at 'git revert --help'
instead.
2. How do I avoid this sh**show in the future so that when I
want to just go back to a commit, just go back and move on?
There are at least a coupld of things you can do
- invest in ways to test locally, then you don't have to push at
all.
- invest in ways to test on your 'feature-branch', then you don't
have to merge into 'staging' (and push the merge)
/M
--
Magnus Therning OpenPGP: 0x927912051716CE39
email: mag...@therning.org
@magthe@mastodon.technology http://magnus.therning.org/
"Rome wasn't burned in a day."
--
You received this message because you are subscribed to the Google Groups "Git for
human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/git-users/87bken8ulr.fsf%40therning.org.
