<div class="gmail_quote">On Fri, Dec 18, 2009 at 10:37 AM, Eric Junker <span dir="ltr"><<a href="mailto:eric@eric.nu">eric@eric.nu</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On 12/18/2009 10:15 AM, L. V. Lammert wrote:<br>
> I had originally thought that having my OWN 'working' repository would<br>
> allow me to share environments between office, laptop,& netbook, but git<br>
> does not seem to like two repositories (at least I can't get it working).<br>
><br>
> So, the question - is maintiaing a 'work' repository and a 'master'<br>
> respository a valid topology?<br>
<br>
</div>The way I've seen this done is that you would create your own branch.<br>
Then you would push your commits to your branch. You can then push/pull<br>
to the master branch.<br>
<font color="#888888"></font><br clear="all"></blockquote></div><br>Yes, at my company we use bzr which is a dvcs like git and uses the same philosophy as git.<br><br>Branching is very simple so you should use branches with abandon. For example,<br>
<br>bzr branch trunk bug1532<br><br>cd bug1532 && fix && merge back to trunk when ready<br><br>If you need to share your branch with someone else (or a different computer) then push it up to the server but not to trunk. When its ready to be merged into trunk then you merge it.<br>
<br>Launchpad.net, our online colaborative development tool, is built on this philosophy as well. So is github. Anyone can branch code, anyone can publish their branch, anyone can merge from one branch to another. You propose a branch for merging when it's ready. <br>
<br>There's no cost for branching and merging unless you leave your branch for so long that the code bases deviate dramatically.<br><br>-- <br>Matthew Nuzum<br>newz2000 on freenode, skype, linkedin, <a href="http://identi.ca">identi.ca</a> and twitter<br>