<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<big>As a new Git user (and budding enthusiast) I am following this
thread with interest.<br>
<br>
While not directly related to Git, I will toss out this story about
revision control in general. <br>
<br>
A few years ago, when interviewing a candidate for a job he told me
that one of the fellows in the development team would check out code,
work with it for 6 months or so. All without checking in the work (or I
assume merging). And when the work was checked in, a lot of work was
required, on the part of the team (of course), to reconcile the changes.<br>
<br>
The problem: The culprit was the lead developer, the team manager.<br>
<br>
A tip on Git that I read somewhere was to develop a consistent style in
the git commit messages, e.g. git -am [message text], so as to make
subsequent searches easier. For example, if one was using an issue
tracking system with issues SCR 1024 SCR 2031 SCR 112 being active and
the commit was to combine repairs that addressed these issues, the
commit message could be: git commit -am "issues: </big><big> SCR 1024
SCR 2031 SCR 112" or similar.</big><br>
<big><br>
In this example: SCR == Software Change Request.<br>
<br>
JohnJ<br>
</big> <br>
<br>
On 2014-04-15 20:26, Jonathan Poole wrote:
<blockquote
cite="mid:2E7AB484-C4AF-4142-966E-238E35AD9594@digitaljedi.ca"
type="cite">
<pre wrap="">Yes, we had a fellow that was 42 days behind on his branch, spent a few weeks rebasing, and then ultimately just merging and dealing with the mess. Rebase is your friend.
On Apr 15, 2014, at 8:09 PM, Chris Frey <a class="moz-txt-link-rfc2396E" href="mailto:cdfrey@foursquare.net"><cdfrey@foursquare.net></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Tue, Apr 15, 2014 at 07:43:13PM -0400, Jonathan Poole wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I’ve adopted the git-flow branching model at home, and work.
With little hesitations now, we are growing to love it. Merging and
rebasing is fairly straightforward, but I don’t know what kind of code
your writing that would not inherit the model successfully.
</pre>
</blockquote>
<pre wrap="">
I assume you're referring to this:
<a class="moz-txt-link-freetext" href="http://nvie.com/posts/a-successful-git-branching-model/">http://nvie.com/posts/a-successful-git-branching-model/</a>
I mostly do use that flow, but in my experience, the number of merge
commits (as opposed to fast-forwards) are pretty low, since I highly
favour rebasing before ultimately merging with master, wherever possible.
It keeps history simple, and keeps my development in sync with the
lastest good code.
- Chris
_______________________________________________
kwlug-disc mailing list
<a class="moz-txt-link-abbreviated" href="mailto:kwlug-disc@kwlug.org">kwlug-disc@kwlug.org</a>
<a class="moz-txt-link-freetext" href="http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org">http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org</a>
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
kwlug-disc mailing list
<a class="moz-txt-link-abbreviated" href="mailto:kwlug-disc@kwlug.org">kwlug-disc@kwlug.org</a>
<a class="moz-txt-link-freetext" href="http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org">http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org</a>
-----
Checked by AVG - <a class="moz-txt-link-abbreviated" href="http://www.avg.com">www.avg.com</a>
Version: 2014.0.4355 / Virus Database: 3882/7345 - Release Date: 04/14/14
</pre>
</blockquote>
<br>
</body>
</html>