Pull changes from remote git repository

Question

I'm new to git. What I have done is forked several repositories I'm interested in and then cloned them on my computer to work with them.

Some of the original projects may be significantly updated for I ever mess with my local copies, or I might make some insignificant changes.

From what I understand, I can "rebase" my clones to "pull" in the changes from the original.

What does that do to my changes? For example, suppose there is a file DoSomething.cpp from the original. I modify it, maybe fix a small bug or add a feature. Now! 1 year later the original project has gone through many revisions and is much better. I want to "pull" those changes into my clone BUT keep my change too! (so this is sort of the reverse of a push)

Is this easy to do? If so, what's the basic idea?

What I would like is that any changes in my clone from the original clone(things I've changed) are not overwritten but I can actually merge my changes and with the original(on my fork) and be given the ability to actually check and accept the changes. (for example, if DoSomething.cpp was changed on the original then I need to compare the changes to make sure they are compatible.

I guess this is not difficult since I am the owner of the fork I can rebase or hard reset it then push my local changes to my fork? (not sure if it will work though since there is a huge potential for versioning issues)

Answer 1

You're right, rebasing is one way you can keep your code up to date, and is very commonly used to do so.

In my experience, rebasing is more useful in terms of managing your git history. It keeps your history nice and linear, it makes it seem like the work happened sequentially rather than in parallel. Regular merges on the other hand will involve lots of diverging/converging commits. You can use git log --graph to see this difference visually.

In a nutshell, rebase takes your commits, turns them into patches, and then applies them to the branch that you're rebasing onto. If there are conflicts git will stop and ask you to resolve them, and then you can have it continue. So you're still merging and resolving conflicts, but just in a way that makes the history linear.

Answer 2

First you should know that whether you "merge" or "rebase" you will not loose your changes and git will give you the chance to commit your changes & resolve the conflicts (if any) and then push your modifications back to the remote repo you are pulling from.

when you git pull you are telling git to do this: (pull default is to use "merge")

pull the latest copy of the files from the remote, merge them with my local changes & if there is a conflict that you couldn't resolve automatically then notify me so that I resolve it manually; it is straightforward.

when you git pull --rebase you are telling git to do this:

temporary remove* the changes from my local copy (my modified files), pull the latest copy from the remote, merge my changes on top of it & if there is a conflict that you couldn't resolve automatically then notify me so that I resolve it manually. (technically nothing is removed; it is just to make this otherwise vague logic clearer.)

the difference is subtle, in the second case, your changes appear to be as if you have just made these changes on the top of the most recent copy that you pulled from remote... but as you could see, in both cases your changes are definitely kept (otherwise what is the use of git!).

Should you merge or rebase? it is long discussion & there are places where one is better than the other and there are best practices for this; some useful comments are already mentioned in this page and for more info you could search online, just type "git merge vs rebase" and you will see tons of pages about it : )

hope this helps.