<div class="gmail_quote">On Thu, Oct 14, 2010 at 9:34 PM, David Doria <span dir="ltr"><<a href="mailto:daviddoria@gmail.com">daviddoria@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
A situation came up on the users list today which sparked a<br>
hypothetical question. There was a small issue with a function that<br>
two people agreed should be fixed. I have a topic branch that happens<br>
to deal with that function, so I was planning on adding the fix to the<br>
existing topic. If I hadn't mentioned that I was doing that, person B<br>
may have made their own topic branch just for this fix and merged it<br>
with master. Then when I go to merge my topic when it is finished,<br>
there would likely be a conflict.<br>
<br>
With the old "push directly to master" system, you would pull the<br>
latest version (the cvs mindset), then make changes to that. So, as<br>
long as person A and person B don't do this at physically the same<br>
time there won't be a problem. With the new system, person B would<br>
have to know about the branch that person A is working on in order to<br>
check if the fix has already been applied there. Once there are more<br>
than a handful of topic branches, keeping track of who is working on<br>
what will be tricky.<br></blockquote><div><br></div><div>There is very little difference between this situation, and the previous situation...with CVS you would have fixed it locally, continued working on what you were doing and then updated before committing. Now you continue working, but commit this fix with a meaningful commit message telling us what you did.</div>
<div><br></div><div>Please remember that these are 'topic branches', and should encapsulate topics - you should not bundle in random fixes. If it is a trivial fix, unrelated to your topic, then it would be better to,</div>
<div><br></div><div>git checkout -b bug-fix-topic origin/master</div><div><br></div><div>Fix the bug on that topic branch, stage, merge and then switch back to the topic branch you were previously working on. This is one fo the major advantages of the branchy workflow - you can work on meaningful topics, if a bug is discovered and you need to fix it switch to a new topic, fix it and get back to what you were doing.</div>
<div><br></div><div>There is always scope for conflicts, no matter what strategy is used. If you are making large changes then announcing what you are working on to the community is always good form. Conflicts will happen, and git gives us great tools to resolve them when they occur.</div>
<div><br></div><div>Marcus</div></div>