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

[jpoole at digitaljedi.ca]

As another note, why feature branches are important in todays environments is if
you have a CI server (you do right?). Is that it's important to know, what
feature, broke the build.   We also have a rule, if you break the build, you owe
timbits for all, after you fix the build ;).  If multiple developers are
responsible, then it's an all-hands fix.

Our CI does a 'realtime' build of * branches.  Meaning, it builds on all
branches all the time (Only if there has been commits, in the last 7 days).

we have release branches, and feature branches.

Developers develop in feature/my_new_feature; commit, publish.
Once a build passes, merge with code review into 'develop' branch.
Build is spun, and deployed at this point - This tests deploy scripts,
migrations, etc.
Deploy successful, we merge from develop into a test branch, which encapsulates
all the features to be tested - QA tests and reports on this branch.
Release branches occur periodically where the Product Manger decides what
features are to go into a release and pulls them into release/release-1.0
Build is done on release, publsihed, packaged, and scheduled for production
release.
* Special cases where hotfixes are to be done - emergencies
 Apply the fix directly to the release/release-1.0 branch, and a new
release/release-1.0-hf1 is performed, built and deployed.  Then a merge from
release/release-1.0-hf1 into test and develop branches. Developers needing this
hotfix, will need to rebase.

Moving to a DRCS you kinda have to throw away the idea of CVS/SVN types of
setups and 'publish' less often.  Commit like crazy locally if you want, but
only publish to your remote branch when things are feature-complete.  Some folks
here still hold onto that fear of 'my laptop isn't being backed up!', so they
publish more frequently to their remote branch as a 'checkpoint'.  I frankly
tend to worry less about that now with Distributed systems, everyone has a copy
of the entire repository, so backups are not AS necessary, but still necessary.




> 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
>
> _______________________________________________
> kwlug-disc mailing list
> kwlug-disc at kwlug.org
> http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org
>