7

I'm new to GIT as you might have guessed. I'm working on two different computers and it finally happened, I forgot to do a git pull before working. When I tried git push I got an error

! [rejected] master -> master (fetch first) error: failed to push some refs to ...

Tried git pull and got

CONFLICT (content): Merge conflict in Project.html Automatic merge failed; fix conflicts and then commit the result.

Now the file that I was working on is kind of messed up. How do I fix it so that I can push again? What should I have done (besides not forget to git pull at start) to make this right? Thank you all for your time and effort.

Des
  • 213
  • 1
  • 3
  • 14

2 Answers2

5

When you pulled, git found that the new changes you made affected some of the same parts of the code as were also affected by changes you hadn't yet pulled. That is why it generated a 'CONFLICT' message.

While it is nobody's favorite part of source control, conflicts (and conflict resolution) are a normal part of the process. They do not necessarily mean that anything was done wrong. If you're working alone and you can develop in a very linear way, then you could try to hammer out some discipline by which you can never have conflicts. But while git certainly can handle that use case, a big part of the point of git is that it can also handle non-linear cases (including efforts with many contributors who may be loosely coordinated).

The files you say are "messed up" contain conflict markers. As the git prompts indicated, git expects you to edit the affected files to decide how the files should look, accounting for both attempts to change them. (If you do git status, it will reminder you which ones are yet to be handled.)

So you might see something in the file like

<<<<<<< HEAD
This is the result of the local edits to this section of code
-------
This is the result of the edits you are trying to merge in
>>>>>>> other_branch

You examine that, figure out a single block of code that will account for what you were trying to do in both instances, and so you replace it with

This is the result of applying all the changes in a way that work together

No more conflict markers, one cohesive piece of code. Do that for each conflict marker, save the file, git add the file, and when status says that everything is resolved / staged, you can complete the merge.

Mark Adelsberger
  • 42,148
  • 4
  • 35
  • 52
  • 1
    Thank you. This is a very concise answer. I was hoping for some "git magic" where I could put all the changes that I made on PC1 since the last pull "on the side", than do a pull and ... oh, I see now how this would not work and I would be back in the same situation where I am now since git can't magically know what I want to keep. Thank you again, I'll get to work sorting things out. :) – Des Jan 20 '19 at 17:34
  • By the way, how do people on big teams resolve this? It seams like it would be a mess! – Des Jan 20 '19 at 17:35
  • @Des - You can put changes "to the side" with something like `git stash`, but as you realized when talking it through, you would still have to resolve the conflict (when applying the stash). In practice conflicts just don't seem to come up / cause problems as often as you might expect. It can be important to coordinate how major changes that touch all the code will be done, but other than that rarely do I hear of teams specifically seeing this as a problem to be addressed. I guess it helps to have appropriate branching strategies for the project – Mark Adelsberger Jan 21 '19 at 00:03
  • And good to know git can help you with these merges. When this happens and you have loads of files with conflicts, you can also tell git to either resolve conflicts in a way that keeps one or the other copy using --theirs --ours . More detail here https://stackoverflow.com/a/10697551/337598 because it is a larger topic and this thread explained it easier. –  Nov 30 '20 at 14:30
5

One of the most common ways to work with git is using feature branches. The idea is to create a new branch every time you start a new feature and when you finish the feature you merge it to the development branch. Ideally, you merge your branch to the development branch doing a Pull Request.

Sometimes you could forget about creating the new branch before starting to work and you create some commits in the development branch.

If that's case, you can create a new branch from your current one and then reset the original branch to the origin state

For example, if you added some commits to the development branch shouldn't be there, you should do:

git checkout -b new_feature_branch to create the new branch based on your development branch

git checkout development to return to development branch

git reset --hard origin to reset your development state to the origin state

git checkout new_feature_branch to return to the development branch

git merge development to try to get the new changes from development. This can also be done with git rebase development.

After that, based on the way you work, you can push your branch to your git server and then create a Pull Request or go again to your development branch to merge in the console the changes from your new_feature_branch

Fede
  • 460
  • 3
  • 10