Hello all, So we've (as in my place of work) have switched from SVN to GIT although I do have a few questions -- hopefully they're not too obvious. :) We have our master branch which is where all the latest changes are added to as a "remote shared repository which everyone pushes and pulls to. That's emulating pretty much what SVN did -- which is fine. As for myself, I maintain _locally_ a few branches (branchX, branchY) which dictate some bits and pieces I'm working on. Periodically, I will tend to merge either merge to master and then push those changes out. So far so good... But, I've now come up against a case whereby if one of my colleagues changes a file (call it fileA) in branch master, and, in the course of my working in branchX means i modify fileA also, when I come to merge branchX into master I find the original change in master (as submitted by my colleague) being reverted by my changes in branchX. Luckily I don't commit that since I do a git-diff beforehand. :) One suggest solution to this is to merge master into branchX/branchY periodically, although this has the same problems as described when I try to merge -- if I'm going to make branchX the same as master, I might as well just work in master and be done with it, right? So I was wondering if it's fine to branch from master at any given point and perhaps use git-rebasse when I come to merge? Is this even the correct mode of working? Indeed, there might be times when git-rebase isn't necessary if a merge to master from branchX or branchY won't revert a commit in master because that file had been edited, so how do I determine when to use git-rebase in this case? Or is that the correct indicator? I do hope that makes sense. Kindly, Thomas Adam - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
