|Re: Proper way to create new branches? [message #894346 is a reply to message #894073]
||Sun, 08 July 2012 14:09
| R Shapiro
Registered: June 2011
Usually you have many local branches tracking origin/master (shortened form of refs/remotes/origin/master) since often you have multiple changes you are working on in parallel, which should end up on the same branch in the remote repository.
Certainly Git supports this mode. But in my experience a slightly different approach is much more common. Instead of multiple local branches tracking the same remote reference, one local branch tracks the remote ref, via 'merge', and all the others track that first one, via 'rebase'.
That first local branch, the one the tracks the remote ref, is used purely as a merge point - no edits are ever done here. The real work is always done in the other branches, which are kept in sync via 'rebase'. Think of it as a kind of staging area that sits between the per-task work branches and the remote.
So the branch 'master' is configured to track 'origin/master' in the usual way. To push to or pull from the origin, you always go through 'master'. The 'pull' (or 'fetch') will merge changes into 'master'
You never work directly in 'master'. Instead the work for each task is done in a new work branch that tracks 'master', in this case via rebase rather than merge. A 'pull' in one of these work branches will rebase it onto master. To get a the changes from a work branch back into master you would merge them.
There are more steps in this approach but I think it also lessens the likelihood of messy conflict resolution, and that's always a good goal.
The main downside with local tracking in egit is that status decorations are broken. This is a long-standing bug which I wish would be fixed.
Powered by FUDForum
. Page generated in 0.01546 seconds