Sample solution

A remote is a repository other than the current repo's default pull source or push
destination, used when there is another relevant repository we would like to pull
content from or push content to.

Sample solution

Branches are often used to introduce new code without altering the code
currently in place, e.g. to introduce experimental new features, fixes, or functionality
without modifying the existing code base.

Sample solution

A merge conflict arises when the same file has been altered in different ways in two
parallel branches of a repository, and an attempt is made to merge those two branches
together.  This necessitates identifying to git what the "correct" resulting version
of the conflicted file should be.

Sample solution

In the case of a pull or push, we have a conflicted file across two parallel repositories
rather than across two parallel branches.  The resolution is much the same as for regular
merge conflicts: edit each conflicted file to contain the expected "correct" content
to reflect the different alterations in each repo.

Sample solution

The git leader typically manages the initial setup of the team repo, granting the
needed invites/permissions/access to the other team members, and ensuring that safe
and effective processes are developed and followed to coordinate the development
of content in the team members' individual repositories and to merge that into
the central team repo.

Sample solution

One of the biggest challenges in this regard is that everyone has a different perception
of 'easy to learn' for any given product, heavily influenced by their familiarity with
the general knowledge domain of the product, their past experience with similar products,
and their general comfort level with exploring new tools or technologies.  A suitable wording
might instead list the ways in which learning is supported, e.g. "The product must include
a tutorial for each of the following use cases (...some list...), and must include tooltips
for each interactible field/control of the interface."

Sample solution

(Here using internationalization as the example, but very similar answers could be
given for either of the other two choices.)
Suppose we were developing a program that was initially planned for use here in Nanaimo,
with (Canadian) English as the presumed language.  If we weren't actively designing with
internationalization in mind, it might be perfectly natural to write all our output
statements "hard-coded" directly into the various functions/methods in our program,
and to assume all currency amounts were in dollars/cents, all measurements were in metric,
and all times were in BC's new year-round time zone (PCT).  In order to later
support other locations, languages, and measuresments, we would need to redesign and
rewrite the logic for every such function.  If we designed with internationalization
in mind then we could have written the original logic to reference configurable settings,
which would be far easier to add to in an incremental fashion.