0

I am having a bit of a trouble with my Git.

Here is the preface: a couple days ago I made a few commits and pushed them to the Github remote. It turned out that some of these features interfered with those of another developer. Hence, she reverted 3-4 of my commits so she could test her feature.

Now the story. Today I made a couple more changes and commits locally. When I went to push them, I was told that remote is different and I need to use the merge tool. I did (the changes were minor and trivial). Then, I made a merge commit. The problem with this commit is that it completely overrides the local changes I made. Having asked in another thread, I used git reset --hard <commit number> to get back to my working code. From now on, no matter what I try to do, I keep getting my code overwritten by the remote version.

Why does this keep happening and how can I resolve it? I basically want to make sure my local is up-to-date with remote and that I can push my changes to remote.

Edit:

After I do git reset --hard and try to do git push origin <commit number>:<remote branch name>, I get the following error:

error: failed to push some refs to

'https://github.com/xxx/xxx.git' hint: Updates were

rejected because the tip of your current branch is behind hint: its

remote counterpart. Integrate the remote changes (e.g. hint: 'git pull

...') before pushing again. hint: See the 'Note about fast-forwards'

in 'git push --help' for details.

ArtforLife
  • 359
  • 1
  • 5
  • 16

1 Answers1

2

This happens precisely because your local "master" (let's say it's master) branch is not equal to nor more advanced than the remote "master".

You're experiencing the very basis of a software "fork". You just tried to "push" a totally different story to the remote repository, contradicting your co-worker. Git does not like this behaviour and normally blocks you from doing that.

You and your colleague really need to have a sit-down and talk about which version is best between your "start point + your changes" vs their "start point + their changes".

Maybe you need to merge, manually.

Whatever the end result should be, that's for your team to decide.

Hence, she reverted 3-4 of my commits so she could test her feature.

Ouch -- she should be getting some blame for the troubles. She should have tested her feature using an independent branch/fork.

It's important to take the time to learn the concepts of "branch, fetch, merge, push" properly. Use practice repositories to experiment and get comfortable with git. Also, there are many "learn to use git" online coursewares you can use; many are interactive. Related, learn some git workflows: https://www.atlassian.com/git/tutorials/comparing-workflows

One option is to "force" the push to the remote server, assuming that it's a friendly, push-over of a server. (Force "git push" to overwrite remote files)

# -- CAUTION --

# > With great power comes great responsibility.

# -- CAUTION --

git push <remote> <branch> -f
git push origin master -f # Example

git push <remote> -f
git push origin -f # Example

git push -f

git push <remote> <branch> --force-with-lease

Your co-worker probably won't like that to happen without consultation, just like you don't like how the reverts caused you problems. Again, please talk to your co-worker(s) to decide on the best course of action together in this situation.

Community
  • 1
  • 1
starlocke
  • 3,407
  • 2
  • 25
  • 38
  • Thanks a lot for a very elaborate answer. Her reverts were more to make sure that "questionable" and perhaps not fully working features do not go on deploy. (I realize that the workflow sounds really dumb, but it is a small project and I have just joined it). I suspected that reverts had something to do with these woes. What could be the downside of the forced push? Could something go awry with that branch altogether? – ArtforLife Dec 08 '15 at 01:00
  • Ah. Sounds like a legit revert then. Well, in that case, it sounds like your "questionable and possibly not working code" should be on a new branch. That's the whole point of branches in git. Commit anything else, and then do `git branch my_feature_branch`, and push that out for peer review with `git push origin my_feature_branch` (assuming origin is the right name), and then `git reset --hard [commit_id]` to abandon your presumably faulty/experimental advancement of `master`. Follow that up with `git checkout my_feature_branch` if you wish to pursue work on that branch's topic. – starlocke Dec 08 '15 at 01:08
  • I think I understand. Suppose I push out that branch like you said. If the remote did not have it before, it will be created and all my commit history will be sent to remote, correct? Also, will it be easier to simply merge these branches later when my features are ready to be added (at the current point of commit, they should be added)? – ArtforLife Dec 08 '15 at 01:12
  • Righto. Although, only the new commits are transferred. Git is smart/efficient that way. It won't send the whole history all over again. – starlocke Dec 08 '15 at 01:14
  • I did as you said and here is what happens. My "featured" branch is called Heroslider. It works as I want it (my features). I go to Development branch and it also works how I want it. Now, I do git pull in Development branch. It incorporates/overwrites some changes. This branch stops working as I want it. Now, I do git merge Heroslider. It tells me that there is nothing to merge. How could it be? Clearly, the branches are different since I can see the different behavior in the browser. Am I doing something wrong or misunderstanding your advice? – ArtforLife Dec 08 '15 at 01:21
  • It's not that you're misunderstanding me. It's more like you haven't caught on yet that you should be merging the "released branch" into your "experimental branch". Assuming you start from any branch and there's nothing to commit... `git checkout new_feature_branch` -- `git merge master` (incorporating upstream changes to outdated new feature branch) -- if stuff breaks, then fix, commit, push for peer review. Eventually, your team should be `git checkout master` -- `git merge new_feature_branch` (incorporating a new feature to release). – starlocke Dec 08 '15 at 01:29
  • I see. I have tried it both ways (direction of merging braches). It "breaks" my changes either way. The problem is that I have created some new assets and placing them in manually would be a pain-in-the-neck. Looks like I may not have a choice at this point. Too bad that I still don't know why what happened did. – ArtforLife Dec 08 '15 at 01:36
  • [may not have a choice] is to be expected with merges. It's very common. That's all folks. – starlocke Dec 08 '15 at 01:41
  • @ArtforLife: Just one more comment on the "What could be the downside of the forced push": if you cannot answer this question by yourself, don't use it. No offense meant, but you can *really* mess things up with a forced push. – Marvin Dec 08 '15 at 22:27