(resend with correct 'identity')
Hi Karo,
You asked about a feature race - Obviously, at some point there needs to
be a little management applied (i.e a workable decision made) as to
which feature 'goes first'.
One aspect that can go wrong in these discussions is the potential
confusion between 'features' (user visible) and the 'area / file
responsibility' (devs) way of partitioning and managing the code.
By way of history, the old CM systems were based on the very historic
idea of the 'single master / source of truth', the difficulty of copying
it, and of preserving it. So now you have/had a system/tool/process that
'managed' the individual files, but the product coordination was
elsewhere. [Think of being asked to 're-touch' the Mona Lisa to correct
the smile.., before photography]
The Git model is that of one repository = one project [instead of a file
viewpoint], so the overall control is at the project level. Plus there
is the one 'golden' company build repository, as well as the individual
forks and local clones. There is a decision to be made about how devs
interact with the corporate storage server(s).
Personally, I'd suggest to get started, each dev should be able to have
their own project fork on the server, distinct from the golden build
server (that is the protected one!). This allows/encourages devs to push
their daily/hourly/15mins work up to their fork so that they get
protection from having a desktop/laptop crash. It also allows them to
indicate to the integrator which branch is ready to pull, and also act
as a reference point for discussions with area experts where they are
working on a 'co-requisite'.
Proving these mini snapshot commits is quick easy and uses almost no
space, and it is self managed. Because each dev has their own personal
copy of the files, they can try out things (committing locally and
pushing to their fork, but it won't be accepted 'upstream', without
mutual review by the integrator (and area specialist). The neat thing is
the Integrator can simply redirect the dev to rebase and improve the
code/doc, usually without needing to do any fix-up themselves.
I presume that you will also be looking at the test coverage, integrated
tests, etc. etc. Small incremental changes that the dev can test
/before/ upstream submission is important - without that capability the
partnership goes sour.
The other aspect is to re-think the old commit policy. I bet it was
major chunks of work only done infrequently with it only getting
accepted once everyone was tired out from putting in their
two-pennyworth... or something like that (it's a consequence of the old
master system that protected/prevented the master from change).
As noted above, the commits should be frequent, and hence very small,
almost obviously correct, with a sequence of preparatory patches, and
with doc patches. These are much easier to review and get accepted,
meaning one can more easily 'see the wheat for the chaff' on the key
change aspects. These small changes means that the merges get easier and
are almost always a success.
Some folk are still wedded to squashing all the small patches together
for the mainline. Personally I'd disagree with that, but it could be
that you create a nominal three-way branch, one which is the original
string of pearls, the second is the same changes squashed together,
resulting in a 'mainline-squashed-pearls' merge. Without the string of
pearls you won't be able to drill (bisect) down to the particular small
change.
It maybe worth having a review of how the git.git project sets itself up
and is managed
(https://github.com/git/git/blob/master/Documentation/SubmittingPatches)
and particularly how they structure the commit subject and messages.
Once it has been appreciated it makes the short sharp commits much
easier to do.
In summary, Git is project based, not file based. While 'control' is
distributed, the integration to the golden repo mainline is moderated &
managed by the Integration Authority. Co-requisites become easier to
work on /together!/
Philip
PS I've tried to avoid any tool based advice. I tried to stick at the
knowledge and understanding level so you can make choices that best suit
you.
On 21/09/2018 00:30, Karo Zans wrote:
Hi Philip. Thanks for the response.
Right now we are trying to migrate from IBM CMVC to GIT. We haven't
really migrated yet, we are trying to get a plan ready for the
migration, but we need some answers first on how GIT handles certain
things that CMVC already does.
We are running just vanilla GIT on Github Enterprise, and just GIT or
Github Desktop on our local dev machines.
Let's say Developer A starts working on Feature A, and Developer B
starts working on Feature B. If Feature B needs code from Feature A
to work, then Developer B will mark Feature A as a "corequisite".
This ensures that the build team gets both Feature A into the code
when it comes time for Feature B to be included in the main build.
What I am worried about is that if Feature B gets finished before
Feature A is complete, and Feature B is included in a build without
Feature A, then the build will be broken, because Feature B depends on
Feature A.
On Thu, Sep 20, 2018 at 3:58 PM Philip Oakley <philipoak...@iee.org
<mailto:philipoak...@iee.org>> wrote:
Karo,
You don't say what the existing 'tool' is, and whether there is a
way of running both old and new (Git) tooling in parallel.
When using Git branches (and local forks), it is possible for
individual devs to 'break' the rules regarding which files they
can touch, but only as a temporary measure, thereby allowing the
dev to indicate a _potential_ solution to the real owner of that
area.
The responsibility for the 'foreign area' is still with the old
hands, who get to pick and choose what they use in 'their' area
(cherry-picking ideas and code segments from those other
branches). Obviously they get to do the same back to the young
whippper-snappers (showing who are the wiser coders), and
hopefully everyone benefits from the mutual working.
The key step is that the area owners retain responsibility for
what they will accept into their segment of the master/trunk,
without having to actually do the work (when someone offers a
finished work item).
Most of this is careful social engineering using the best parts of
each particular tool and the process flows.
HTH
On 18/09/2018 00:37, Karo Zans wrote:
I see. Thank you for the response. I agree with what you say.
Unfortunately, I am dealing with about 250 different developers
who have been on the same project for 15, 25, and even 35 years
and they are all stuck in the old school way of doing things.
Asking them to adopt a new tool is like extracting teeth. I
can't tell you how many times I've heard, "What we do now works,
so why change?". Frankly the only reason why we are moving to
GIT from the old system is because the old tool isn't being
supported anymore.
Thanks for the information on the workflows. I think I have
heard that some people like Google use Gerrit in combination with
GIThub. That is supposed to enforce permissions, is that right?
Where can I find these workflow models? I think I saw some basic
ones in the GIT user manuals, but they didn't seem to work for
us. Is there a good place I can look at several workflows?
Thanks
On Mon, Sep 17, 2018 at 4:23 PM Philip Oakley
<philipoak...@talktalk.net <mailto:philipoak...@talktalk.net>> wrote:
Hi,
Most processes are driven by the limitations of the local
tool and the
experiences of local staff and managers. This also affects
the way teams
are structured (see Conway's Law).
Git, with it's 'Distributed control' model, tends to break
the old
paradigms which were based on the 'absolute single master '
idea (one
master drawing / paper record). Git avoids the need to limit
peoples
scope by separating the modification step from the acceptance
step.
Clearly it us reasonable that people generally stay within
their lead
area, but there is nothing wrong with stepping into other
areas with
carefully crafted and explained changes. They won't be
accepted, I hope,
if they fail that criteria. It is important to have a high
quality
senior dev at the acceptance stage who is firm but fair.
The fact that git branches are free and easy makes this
freedom easier.
Have a look at the various workflow models, including Nvie's
and that of
git itself (4 layer: master, next, pu (potential updates),
maint).
Philip
On 17/09/2018 21:17, Karo Zans wrote:
> Hi everyone. I have a question. At my current company, we
have quite a
> few developers. Each team has about 10 or 15 developers
that are only
> allowed to modify their specific code areas.
>
> On our current bug and new development tracking system, we
have bug ticket
> that code changes are tied too, and sometimes a bug ticket
is marked at a
> CoRequisite of another bug ticket.
>
> Basically if a person on another team has to implement a
function or
> feature or bug fix in their code, I will mark my bug ticket
as a
> CoRequisite of their bug ticket, if my code depends on the
new function
> they are adding or fixing.
>
> So I was wondering, how does GIT enforce this?
>
> I realize that I could simply create a branch off of
another person's
> branch and that will indicate that my code depends on their
code, but
> suppose I finish my code before they finish their code.
>
> If a sub branches code is merged into Master before, the
parent branch is,
> the code will be broken.
>
> How does GIT mitigate/enforce this so that the build isn't
broken?
>
> Thanks
>
--
You received this message because you are subscribed to the Google
Groups "Git for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to git-users+unsubscr...@googlegroups.com
<mailto:git-users+unsubscr...@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Git for
human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
