[kwlug-disc] Advanced(?) Git usage question

[John Johnson]

On 2014-04-17 07:36, Jonathan Poole wrote:
> 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.

Outside of git: Project: A web site comprising a number of pages (php) 
each linked to the others.
Information is moved between the pages using http (GET, POST, PUT) and 
the session.
The website back-end includes the directories, css, scripts and images, 
shared between the various pages.

Enter Git (timeline): init, init commit, develop, test, commit, develop, 
test, commit, etc.
Continuing timeline: develop, test, commit, develop, test, issue A 
noted, commit (master)
Continuing timeline: branch (newBranch), develop to address issue A, 
test, commit, develop, test, commit, etc.
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.

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.

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.

The various rewind_xxxxxx branches I took were exploratory and were made 
to help identify where/when issue B first appeared.

(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.)

*Best practices: (Note to self): Have a testing checklist. And follow 
the checklist.*

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.

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.

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.

I may, however, elect to execute merges between the rewind_xxxxxx 
branches to learn how merges work. These branches are throwaway anyway.

Thanks for the tip to have, what I will name, a develop-feature branch.

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.

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.

Thanks, too, for the comments on deploy and publish.

At this point, I am not ready for these steps, nor am I ready for a rebase.

Thanks
John Johnson

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20140417/0a17bcc0/attachment.htm>