I can do basic clone/pull/merge shit in git, and I can deal with your basic merge conflict. But my understanding really falls apart when it comes to more complex things (like rebasing and handling conflicts). Here is the scenario. Say you got your standard master branch in github, then you decide to do a staging branch for a bunch of changes you want to prep for an event in the future (let's assume that will happen in November). So you fork off master into a "staging" branch, you and a bunch of other devs are making to this staging branch happily for a couple weeks, and now the changes are pretty much in the final state that they need to be for November. However, you know for a fact that the master branch is evolving all the time, with little trivial changes. You want to periodically (say every few days), keep the staging branch relatively fresh, so come November, you're not trying to merge months of changes all at once and dealing with the inevitable conflicts. Now what I *think* I want to do in this case, is use git rebase, to make it seem like the most recent master changes happened before I forked. In my brain, this is how it looks when when I forked: And this is how I want it to seem after I rebase each week: I believe the commands to do this are: (assuming a branch called "feature") git fetch --all git checkout feature git rebase origin/master git add . git push origin feature (may need force flag here, not sure) But when I get to the rebase command, I get a merge conflict, because specific lines changed by the feature branch, conflict with changes made in commits C, D, and E. Fine, I have to resolve the merge conflict. However, when resolving the conflict, I don't know whether to keep the C/D/E changes, or the changes made in the feature branch (for purposes of the rebase). Does anyone know which set of changes (master or feature) to keep when resolving the confict? Does any of this make sense?