With the fork & pull strategy, contributors create their own (remote) copy of the original repository and push changes to that copy, which is referred to as a fork. Once a contribution is ready, it can be submitted through a pull request: the contributor basically requests the maintainer(s) of the original repository to pull into that repository the work that has been prepared in a fork. Note that nothing prevents multiple contributors from working together in the same fork prior to submitting their changes to the original repository. The main advantage of the fork & pull strategy is that the contributors do not need to be explicitly granted push access rights to the original repository. That's why that strategy is typically used for large-scale open source projects where most contributors are not known by the maintainers of the repository. Another advantage of the fork & pull strategy is that it prevents the original repository from being polluted with branches that are created and then abandoned but never deleted by their author.

1. Hackolade Tutorial
Working with Forks
Copyright © 2016-2023 Hackolade 1

2. We call this
Metadata-as-Code
2

3. Data models
Schema contracts
Application code
Git repository DevOps CI/CD
pipeline
Application
Database
Copyright © 2016-2023 Hackolade 3
Using GIT to Co-locate metadata with application code
Environments:
• Dev
• Test
• Integration
• Production
ALTER scripts

4. Repository strategies
• Every customer will need/want to have a strategy for how to organise
their repositories
• 2 main strategies exist for dealing with contributions:
• Shared repository
• Fork & Pull
Copyright © 2016-2023 Hackolade 4

5. 1. Shared repository strategy
• Contributors are granted push access rights to a single (remote)
repository
• Branches are created when changes need to be made
• Pull requests are useful to initiate peer review and discussions about
a set of changes prior to merging them into the main branch
• The use of shared repositories is more prevalent with small teams and
within organizations working on private projects
Copyright © 2016-2023 Hackolade 5

6. 2. Fork & Pull strategy
• Contributors create their own (remote) copy of the original repository and push
changes to that copy, which is referred to as a fork
• Once a contribution is ready, it can be submitted through a pull request: the
contributor basically requests the maintainer(s) of the original repository to pull
into that repository the work that has been prepared in a fork
• Note: nothing prevents multiple contributors from working together in the same fork prior to
submitting their changes to the original repository
Advantages of Fork & Pull strategy:
• Contributors do not need to be explicitly granted push access rights to the
original repository
• Therefore the strategy is typically used for large-scale open source projects where most
contributors are not known by the maintainers of the repository
• Prevents the original repository from being polluted with branches that are
created and then abandoned but never deleted by their author
Copyright © 2016-2023 Hackolade 6

7. Fork & Pull in the context of InnerSource
• See Introduction to InnerSource
• Brings the best practices of the open source community to
enterprises, such as the Fork & Pull strategy
• Improves collaboration, without sharing proprietary information
publicly
• Eg. in Github: internal repositories
• Contributors are architects, modelers and subject-matter
experts
• Maintainers are project’s leaders and key decision makers
• InnerSource = cultural shift.
• See Domain-Driven Data Modeling
Copyright © 2016-2023 Hackolade 7

8. Creating a fork
• See user documentation of the GIT provider
• Creating a fork in GitHub
• Creating a fork in GitLab
• Creating a fork in Bitbucket
• Creating a fork in Azure DevOps
• Once fork is created, you can clone it locally with Hackolade Studio
• Fork & Pull strategy is only supported for GitHub
• Other providers will be added shortly (and are maybe already available by the time you
watch this video…)
• Working in the fork is like working in any other repository
Copyright © 2016-2023 Hackolade 8

9. Contribute from a fork
• Submitting changes for review is
different
• if your changes are ready to be
reviewed by the maintainers of the
original repository, which is
named ”upstream”, then you
should open a pull request in that
repository directly
• if you are collaborating with other
contributors and your changes are
just an intermediary step, then you
should open a pull request in the
fork itself
Copyright © 2016-2023 Hackolade 9

10. Keep a fork up-to-date
• Your own fork will at some point become outdated, as it
does not contain the contributions that have been
merged in the upstream repository after you created it
• As soon as you choose to contribute to the upstream
repository, Hackolade Studio makes the branches of that
repository available in your local clone
• The new commits not only get pulled from your fork,
• Also: new commits from its upstream repository get pulled
from your fork
• You can then use the MERGE action to keep your fork up-to-date
with the upstream repository
• If the repository opened in Hackolade Studio is a fork of an
upstream repository that you chose to contribute to, then
the MERGE action selects the default branch of that
upstream repository (e.g. upstream/main) as the source of
the merge operation
• To keep the active branch of your fork up-to-date with
the default branch of the upstream repository, you must
trigger the PULL action and then click on the
button Merge & Push of the MERGE action
Copyright © 2016-2023 Hackolade 10

11. Compare a fork with its upstream repository
• Hackolade Studio makes the
branches of the upstream
repository available in your
local clone of the fork as soon
as you choose to contribute
to that upstream repository
• Those branches are also
visible in the History view
Copyright © 2016-2023 Hackolade 11

12. Compare a fork with its upstream repository (ctd.)
• Branches prefixed with origin/ belong to your
fork
• Branches prefixed with upstream/ belong to
the upstream repository
• The History view allows to compare arbitrary
commits: you can review the differences
between your fork and the upstream repository
• You can for example compare the latest commit on
the branch origin/main with the latest commit on
the branch upstream/main
• If you are only interested in the history of one
repository (the fork or the upstream repository
but not both at the same time), you can filter
the History view for a given Remote
Copyright © 2016-2023 Hackolade 12

13. Compare a repository with one of its forks
• As a maintainer of a repository,
you might be interested in tracking
progress in a given fork by
comparing that fork with the
repository that you are in charge
of
• You might also be interested in
comparing forks with each others
• In this use case, the repository that is
opened in Hackolade Studio is the
upstream repository, not a fork
Copyright © 2016-2023 Hackolade 13

14. Reading material
• See Hackolade online documentation
• The Hackolade Blog
• Hackolade’s on social media: LinkedIn page, Twitter page
• Download Hackolade Studio for free
• This excellent new book:
MongoDB Data Modeling & Schema Design
• Many of the principles in the book are related to query
driven modeling based on access patterns
Copyright © 2016-2023 Hackolade 14

15. Order on Amazon
Copyright © 2016-2023 Hackolade 15
Pre-order

16. Upcoming
Copyright © 2016-2023 Hackolade 16

17. Questions?
Answers!
Copyright © 2016-2023 Hackolade 17