Proper way to create new branches? [message #894047] |
Fri, 06 July 2012 09:39  |
Eclipse User |
|
|
|
Hello there,
We've just recently started using Git. Previously our shop was using SVN. With that in mind this might just be a newbie question.
When I create a new local branch and then push it up to the github repository, I'm unable to pull changes until I go to the egit properties and manually add the repository settings for the new branch. I would assume that there is a way to create these settings automatically.
In addition anyone who tries to retrieve the new branch has issues. They are able to see the new branch in the remote repositories view but the only way we've been able to pull that branch down locally seems kind of convoluted.
The developer who wants to use the new branch first has to create a new branch locally with the same name and then they have to manually add the configuration for the new branch.
I'm really hoping that there's a better way to do this and we can chalk this up to our own ignorance about egit and git.
Thanks in advance for any help!
|
|
|
|
|
|
Re: Proper way to create new branches? [message #894346 is a reply to message #894073] |
Sun, 08 July 2012 10:09  |
Eclipse User |
|
|
|
Quote: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.05880 seconds