CODEWITHSUNDEEP
gitversion-controlgithub
maneesha
maneesha

Reputation: 685

incorporate git changes without losing my work

Let's say I go to github and clone a website project template from github. It could be anything but I'm just giving an example for the sake of this question.

So it has a bunch of files like:

index.html
about.html
source
-styles.css
-scripts.js
images
-banner.jpg
-icon3.jpg

So I clone it from github, and start adapting it for my own project. The original author is not involved in what I'm doing in any way. I'm confident in using git to make commits, branches, and merge branches back to master as long as we're just talking about my work. So I've done a lot of work on it, maybe adding in more html pages and editing some of the js & css.

Now the original author of this project template made changes to the original scripts.js (maybe fixing a bug, or making an enhancement or something).

How do I merge that change into my project without losing any of the work I've done with this project? So let's say there are lines in scripts.js that differ between my project and the most recently pushed one from the original author. Some lines will differ because I changed them myself, and some lines will differ because the original author changed them.

Let's say I changed lines 34, 78-81, 145, & 213 for the purposes of my own project. The original author changed lines 12, 16-20, 78, & 199 as bug fixes/enhancements.

I want to keep my changes to lines 34, 78-81, 145,& 213. I want to incorporate the original author's changes to 16-20 & 199 but NOT line 12 because I don't want to make the change and not line 78 since I changed that myself.

Can I do a merge that asks for confirmation line-by-line for all lines that differ? Is there something else I can do? I am still learning how git handles conflicts.

Upvotes: 1

Views: 124

Answers (2)

janos
janos

Reputation: 124656

Let's say I changed lines 34, 78-81, 145, & 213 for the purposes of my own project. The original author changed lines 12, 16-20, 78, & 199 as bug fixes/enhancements.

Lines that only one of you changed will be merged automatically. Lines that both of you changed will result in conflicts: git cannot know whose change it should keep, you must tell it yourself.

When there are no conflicts, git performs the necessary changes and commits them. When there is a conflict, git adds some markers in the conflicted files like this:

<<<<<<< HEAD
... stuff
... that
... the current branch did
=======
... stuff that
... the other branch did
>>>>>>> name_of_the_other_branch

So here git cannot tell which block should be the correct one, you have to choose one or more typically combine the two. Of course you also have to remove the <<<<<<< === >>>>>>> markers too, sometimes called the fishbone markers.

And since git did not commit the merge, you have to stage these changes and commit yourself.

PS: a graphical merge tool can help resolving merge conflicts. It deserves its own article, the help page of the mergetool command should get you started.

Can I do a merge that asks for confirmation line-by-line for all lines that differ?

Not that I know of, and I don't think that would be much use anyway. From a single change it can be difficult or impossible to understand the intent of its author, typically you need to consider the full set of changes. Remember that if there are no conflicts, git will automatically commit the merge.

If you want to review the changes first, use git merge --no-commit. In some cases you might need the --no-ff flag too. If there were conflicts, the conflicted areas are apparent with git diff, and since the auto-merged changes are staged, you can view them with git diff --cached. This way you can (and actually, you should!) review line by line what changed. (To review the details after an automatic merge, you can do simply git show, as it shows the diff of the last commit, in this case the merge.)

Upvotes: 1

Marcel Blanck
Marcel Blanck

Reputation: 866

When you have conflicts (both of you changed the same paragraph) a human has to decide what is right, the one solution, the other, a combination of both or maybe nothing or something completely different.

If you pull, merge or rebase, git will not finish this step until all conflicts are resolved.

If you see a conflict and a merge not being finished, just type "git mergetool" in commandline. If you have installed a diff viewer like meld or vimdiff, git will open it and you can resolve the conflict. If you do not have a mergetool you can change the files by hand, the conflicts are marked in the text.

When you feel confident that all conflicts are solved, you can then clean up the staging area by adding al the resolved files git git add. When everything is green, just commit the mergeresult asyou would do with a patch. It it was a rebase, you must type "git rebase -- continue" instead of doing a commit.

Anyways just follow the commandline hints from git for such an situation, everythign will be fine.

And do not make yourself to much stress. You can only start a merge when you have commited everything or cleaned up in another way (like using stash). In case of you having commited everything it is totaly save, you can not break anything. Just reset your branch to the commit before the merge. (With rebase it is a little different, depending on how you rebase and this is going to far here)

If this is too much stress for you you can also give the original develeloper a pull request or send him a/many patch text file(s) and let him to the integration.

Upvotes: 1

Related Questions