CODEWITHSUNDEEP
gitgitlab
mayconfsbrito
mayconfsbrito

Reputation: 2413

Git branch rolling back unchanged files after push force

A coworker from my team pushed a lot of legacy code in our Gitlab repository.

We don't know if it used push force, but we know that he did a merge in our master branch from the legacy branch.

We did the correction doing another push force with the correct and updated code. But now we are having a serious problem.

Example: If I change, add, commit, and push the A file and I have the B file on the version 3, and something else update the A file (the same that I've just pushed) but the B file is on the version 2 (but isn't changed or pushed), the B file is changed to the version 2 ignoring the latest version 3.

What is happening and how can I change that besides deleting my current branch and working with a new branch?

Upvotes: 0

Views: 61

Answers (1)

matt
matt

Reputation: 535304

There isn't actually any problem. This has nothing directly to do with the push-with-force actions — though it does sound as if there was a failure of communication, because, after the push-with-force, everyone should have basically thrown away their copy of the repo and cloned a new copy of the repo so as to ensure that all copies of the repo were in sync with one another. The actual underlying trouble that you are describing, however, is that you and someone else have different version of these files, especially file B.

You need first to understand what a push is. You do not push "files". You push a commit (or a sequence of commits).

Okay, so what is a commit? It is a snapshot of all the files in your project.

So if I have version 1 of file A and version 1 of file B and I commit and push, the commit that was just pushed has version 1 of file A and version 1 of file B, and that is what now appears at the end of the branch on the remote.

And then if someone else has version 2 of file A and version 2 of file B and they commit and push, the commit that was just pushed has version 2 of file A and version 2 of file B, and that is what now appears at the end of the branch on the remote.

It doesn't matter at all that the way this happened is that the other person only changed file A. If file B is on version 2, then it is part of the commit, because it is part of every commit. A commit is the whole state of the whole project.

Now, to sum up, many very wrong things are happening here — like the fact that you all allowed yourselves to get out of sync after the force pushes, or the more basic fact that two (or more?) people are pushing directly to the same branch (which, as far as I'm concerned, is a massive misuse of Git). But if that's the way you're going to behave, then the result you are getting is just the sort of thing that is likely to happen. In other words, what is wrong is not how Git is behaving, it's how you are behaving.

Upvotes: 2

Related Questions