When you are working locally and messing around with your local branches, you can do whatever you like as long as you haven't pushed the changes to the central repository. But as with any powerful tool, you basically need to know what you're doing or something might go really wrong. git rebase is a very powerful tool and enables you to squash commits together, remove commits etc. This is an important thing/concept in git that a lof of git users would benefit from knowing. I'm concerned that the message states feature -> feature rather than feature -> origin/feature but this may just be a presentation thing.Īm I missing something, or going about this in completely the wrong way? It's not critical to avoid doing the rebase on the remote server, but it makes fixing any merge conflicts from the rebase much harder. Git pull does the trick but causes a merge commit that I'd like to avoid. 'Note about fast-forwards' section of 'git push -help' for details. To prevent you from losing history, non-fast-forward updates were rejected However, this method causes Git to complain: To
To keep the remote feature branch up-to-date with the remote master. I'd like to be able to do: git checkout master What I would like to do from here is to rebase the feature branch to the master branch on the remote, but I would like to do this from my local machine. I then re-setup the branch to track the remote: remote:Īnd all is well. I can successfully push my feature branch back to the remote, and end up with what I expect: remote: The intermediate repository has its master branch rebased nightly from the upstream SVN, and we are working on feature branches. I am using an intermediate Git repository to mirror a remote SVN repository, from which people can clone and work on.
0 kommentar(er)
