This may happen when you have made changes to your local files and the remote repository has new changes that conflict with your local changes. Once you have put the file into the state you want it, you indicate that you are done merging the file and it is ready to commit using git add, and then you can commit the merge with git commit.When working with Git, it is common to encounter situations where you need to force overwrite local files on a Git pull. Or, you can check out the version from one or the other sides of the merge, using git checkout -ours or git checkout -theirs.
#GIT PULL REMOTE BRANCH DICARD LOCAL CHANGES CODE#
In order to resolve the conflict, you can either edit the file that is in your working copy, removing the conflict markers and fixing the code up so that it works.
In the index (also known as the "staging area" the place where files are stored by git add before committing them), you will have 3 versions of each file with conflicts there is the original version of the file from the ancestor of the two branches you are merging, the version from HEAD (your side of the merge), and the version from the remote branch. In this case, Git will do as much of the merge as it can, and produce files with conflict markers ( >) in your working copy. The final possibility is that there's a real merge, and there are conflicts. By default, when a clean merge happens, it is automatically committed, though you can disable this with -no-commit if you need to edit it beforehand (for instance, if you rename function foo to bar, and someone else adds new code that calls foo, it will merge cleanly, but produce a broken tree, so you may want to clean that up as part of the merge commit in order to avoid having any broken commits). One is that the merge happens cleanly all of the changes are in different files, or are in the same files but far enough apart that both sets of changes can be applied without problems. In this case, there are two possible outcomes. Then you get into the situations in which you actually need to merge two revisions. In this case, you're "already up to date", and nothing happens.Īnother possibility is that their revision is simply a descendent of yours, in which case you will by default have a "fast-forward merge", in which your HEAD is just updated to their commit, with no merging happening (this can be disabled if you really want to record a merge, using -no-ff). The simplest is that you're on the same revision. When you merge in someone else's code (which also happens during a pull a pull is essentially a fetch followed by a merge), there are few possible situations. I'll expand a bit on how conflicts and merging work in Git.
If you don't do this, and the filename happens to match the name of a branch or tag, Git will think that you want to check that revision out, instead of checking that filename out, and so use the first form of the checkout command. It's also a good habit to have, when passing in a filename, to offset it with -, such as git checkout -ours. or a filename in order to get the second behavior from git checkout. So, if you want a behavior that will overwrite existing files, you need to pass in. The way it distinguishes is by whether you've passed a filename in if you haven't passed in a filename, it tries switching branches (though if you don't pass in a branch either, it will just try checking out the current branch again), but it refuses to do so if there are modified files that that would effect. git checkout has two modes one in which it switches branches, and one in which it checks files out of the index into the working copy (sometimes pulling them into the index from another revision first). Git add -u # mark all conflicted files as merged # checkout our local version of all files Then you need to mark the conflicts as resolved, which you can do with git add, and commit your work once done: git checkout -ours. to git checkout to tell it to check out everything in the tree. Git checkout has the -ours option to check out the version of the file that you had locally (as opposed to -theirs, which is the version that you pulled in).
0 kommentar(er)
