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
<[email protected] <mailto:[email protected]>> 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 [email protected].
For more options, visit https://groups.google.com/d/optout.
