[kwlug-disc] Advanced(?) Git usage question
jvj at golden.net
Thu Apr 17 08:46:57 EDT 2014
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
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 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
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 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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the kwlug-disc