<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<big>On 2014-04-17 07:36, Jonathan Poole wrote:</big>
<blockquote
cite="mid:C4E73857-D841-4EF0-8267-0547ACEB2D44@digitaljedi.ca"
type="cite"><big>Hope this sort of helps, I’m just having a hard time
drawing a picture
in my head of when events occurred, what events need to be merged with
what.</big></blockquote>
<big><br>
Outside of git: Project: A web site comprising a number of pages (php)
each linked to the others.<br>
Information is moved between the pages using http (GET, POST, PUT) and
the session.<br>
The website back-end includes the directories, css, scripts and images,
shared between the various pages.<br>
<br>
Enter Git (timeline): init, init commit, develop, test, commit,
develop, test, commit, etc.<br>
Continuing timeline: develop, test, commit, develop, test, issue A
noted, commit (master)<br>
Continuing timeline: branch (newBranch), develop to address issue A,
test, commit, develop, test, commit, etc.<br>
Continuing timeline: (still in newBranch): test, issue B noted, and
determined that issue B was present for a number of the last commits in
newBranch.<br>
<br>
This scenario is similar to the one described earlier in this thread.
One poster advised taking a branch at the point where the "feature was
introduced ... fix the bug, then merge the fix in to whichever other
branches". I advised "to take a branch now of the [....] fix the bug in
that branch and migrate the patch back to the master and the feature
branch.<br>
<br>
In the other scenario the situation was described as "very minor
bugfix" and one which I presume is somewhat isolated. My current
scenario is not a "minor bugfix". Rather, it involves shared files in
/scripts and /css.<br>
<br>
The various rewind_xxxxxx branches I took were exploratory and were
made to help identify where/when issue B first appeared.<br>
<br>
(I know. I know. The testing in the "test" activities in the timeline
could have been wider and more thorough. Instead, at times the testing
was focused on the develop/change activities at the moment.)<br>
<br>
<b>Best practices: (Note to self): Have a testing checklist. And follow
the checklist.</b><br>
<br>
The work with /localhost/projectName/indexTest.php described in my
00:00 email was to discover how Git manages the project image as seen
through XAMPP while navigating between branches, making changes, w/o
commit and after commit.<br>
<br>
Back to my Git / develop timeline: I think I will, sort of, follow my
advice given to the OP in this thread. But w/o taking a branch now.
Instead, I will fix issue B in the current branch, newBranch, commit as
soon as possible and continue.<br>
<br>
The other branches, rewind_xxxxxx, have served their purpose and there
is no need to merge any changes made to branch newBranch back to these
branches. And there is no need for any changes made in the
rewind_xxxxxx branches to be merged with newBranch or with any other
branch.<br>
<br>
I may, however, elect to execute merges between the rewind_xxxxxx
branches to learn how merges work. These branches are throwaway anyway.<br>
<br>
Thanks for the tip to have, what I will name, a develop-feature branch.<br>
<br>
I think that having a develop-feature branch for a given feature is a
good idea as it isolates work for the feature from other work, e.g. for
other features.<br>
<br>
The develop-feature branch also focuses one to work on that feature.
And would, in another environment, allow for the assignment of work on
individual features to different members of the development team.<br>
<br>
Thanks, too, for the comments on deploy and publish.<br>
<br>
At this point, I am not ready for these steps, nor am I ready for a
rebase.<br>
<br>
Thanks<br>
John Johnson<br>
</big><br>
</body>
</html>