![]() Now if you did a "normal" pull you would get A - B - C - X - Y <-(origin/master)īut if you use git pull -rebase then the pull will rebase the local master onto the newly-fetched origin/master instead, so you get A - B - C - X - Y <-(origin/master) You instead had A - B - C <-(origin/master)īecause you did your work directly on master. Let's say instead of A - B - C <-(master)(origin/master) What -rebase lets you do is not create the branch in the first place but still end with a linear history (if you're into that sort of thing). When pulling master, -rebase changes what the pull does with commits in master but not in origin/master - and in your scenario there are none. You could do a -rebase pull, and it would work exactly the same, because you're not in the situation where -rebase is meaningful. Then when you pull, the resulting merge is a fast-forward, and you can then rebase your branch onto master to keep a linear history (if you're into that sort of thing). In your current procedure, you leave master at origin/master (because you're working on a branch). Question: Can/Should I change the above steps to: git clone **git push -set-upstream origin feature/my-branch** In the steps above I have rebased onto the HEAD of master, whereas most git pull -rebase explanations appear to focus on rebasing upon commits made to the same branch (not the original master). My question is (assuming that is correct) how does the git pull -rebase know which branch I am rebasing on? My understand of git pull -rebase is that it does as I've described above. My understanding is that - at this point - all the commits I've made while working on my branch will be applied "after" those master commits. What I would then do, locally, is git checkout master, git pull, then checkout my branch and git rebase master Other commits have, during my branch work, been PR'd into master. So in this case you must indeed pull first (I would recommend pull -rebase to not create a merge commit, and keep your history cleaner, but that's very subjective), then push (and after pulling, no -force will be needed).īottom line is, know what git push -force does, know when it is ok to overwrite the upstream with your local (you can then push force) and when it is not ok (you need to pull).Īnd to come back to your original case, you rebased your branch, so it diverged (by definition), so if you work alone on the branch or if you made sure that nobody pushed anything on it in the meantime, git push -force is what you need.Starting point: I have created a branch from master and locally made commits. In this case it is important to not push -force otherwise your colleague's work will be erased, and he/she will be pretty upset. However, if you work with people on a same branch and one person pushes the branch with new changes while you make your own changes, then when you will want to push, Git will also tell you that the your local branch and its upstream diverged, and so you should pull first and so on. In this case it is fine to tell git: "Take this version, discard the one you have". So you know that they diverged and that your local version is the correct one. For example your branch was not up to date with master, so you rebase it to "move it" on top of master (technically, the commits are recreated from the new base, in this case master but effectively it looks as if it has been moved). If you rebased (and therefore created a new chain of commits for your branch), your branch and the remote diverged, which is to be expected. There are two cases, one where it is fine to push force, and one where it is not fine at all: What it does is to replace the remote head of your branch with your local. There is nothing wrong with git push -force on principle. This dosent seem like an solution at all, for me, for such commonly used tool. I've read many threads about this, and the only solution seem to be to use -force I just want to update my feature branch so it's even close to version on master. I have locally: feature branch, master ( up to date )Īnd remote: featureBranch ( which is ahead now ?! ) and master. Hint: See the 'Note about fast-forwards' in 'git push -help' for details. ![]() and end up in same situation? error: failed to push some refs to Updates were rejected because the tip of your current branch is behind Or pull again and deal with the merge conflicts again. I have two options, use -force which seems risky and stupid. Git is really telling me that after doing a rebase ( dealing with n:ths of conflicts ) I know this has been asked before but i cant seem to wrap my head around this thing.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |