Emma Jane Hogbin Westby
@emmajanehw
- Character development.
- Adventure map.
- Town planning.
- Interior design.
Four techniques to understanding the context of what's happening in Git.
- Describe the work your team does.
- Map your network of repositories.
- Diagram your branching strategy.
- Defend what gets stored in the repo.
Write down a list of the NAMES of all the people on your code team.
- UX researchers
- developers
- designers
- project managers
- clients
- ???
Write a list of all the (code-related) tasks you are responsible for.
- Writing code.
- Reviewing designs.
- Fixing broken code.
Create a linear assembly line that plots the order of tasks
and people who are involved.
Shared repository with two contributors.
Contributor does not have commit access to the main repository.
- Know who the characters are in your game of Git.
- Write down the actions they are allowed to take in the game.
- Plot a timeline of actions for each character. (This may turn into a decision tree.)
Are you allowed to "push" commits to each of those repositories?
Is it an automated gatekeeper?
Do I need to manually push/pull my cart between the towns?
- Draw a map of all the places where repositories are found.
- Identify on your map who controls each of these "towns".
- Identify the major routes between repositories.
- Illustrations should look like a network diagram.
Let's call branches which link commits
the streets which provide access to individual buildings.
- State / Environment Branching (GitLab Flow)
- Branch-Per-Feature (GitHub Flow)
- Scheduled Release (GitFlow)
- Environment branches
- Branch-per-feature
- Scheduled release
Draw the "swim lanes" (ball-and-chain graph) for how one new piece of work would be incorporated into your repository.
(this requires a BIG cognitive jump; I will help you)
- The strategy you use to separate work is entirely dependent on the type of work you are doing.
- Don't pick a convention because it's popular. Pick it because it allows your characters to achieve their goals with less friction.
- Diagrams should mimic the graphed output of
git log --graph.
What do you actually put in a repository?
- How do you manage dependencies?
- Where do you store very large files?
- How do optimise your build process for very fast deployments?
Version your build manifest
ignore the built files.
- Keep your "core" clean and track upstream work with named branches.
- Nest repositories without tracking by using subtrees (clone inside a clone).
- Git can track external repositories with submodules. There be dragons.
Easier:
- see the scope of a single repository.
- track all dependent files from a single location.
- adjust architecture decisions "on the fly".
- deploy all related code.
Easier:
- ship updates without waiting for other teams.
- independent systems with machine relationships (fewer points of system-wide failure).
- faster downloads of only relevant information.
Git: we tend to store only deployment files.
Perforce: we tend to store all project files.
Deployment binaries?
Project assets?
Do not version binaries in the repository;
reference them from another location.
- git-annex
- git-bigfiles
- GLFS * new shiny!
Note: Best Practice. http://blogs.atlassian.com/2014/05/handle-big-repositories-git/
Avoid grabbing all versions of a file for the deployment.
$ git clone --depth [depth] [remote-url]
$ git clone [URL] --branch [branch_name] \
--single-branch [folder]
- Consider the people and processes you are optimising for.
- If necessary, use off-site storage for very large files.
- There are ways to limit what is downloaded on clone, so don't be afraid to insist all files be included in the repository.
Best Practices
- Set political constraints for your players. (Access control.)
- Sketch the landscape you are going to play in. (Remote repositories.)
- Use one convention to build your roads. (Branches.)
- Include only what you need in each building. (Commits.)
https://github.com/gitforteams/game-of-chance
Emma Jane Hogbin Westby
@emmajanehw
emmajane.github.io/git-adventure-mapping
