> ## Documentation Index > Fetch the complete documentation index at: https://docs.graphify.com/llms.txt > Use this file to discover all available pages before exploring further. # Share context with your team > Choose how to distribute graphs and keep each checkout up to date. You can share generated graph files in the repository, build them in each clone, or run a shared MCP server. Choose based on the size of the graph and who may access the source context. ## Repository workflow 1. Register the assistant skill in project scope if your team wants shared instructions. 2. Build and inspect the graph. 3. Decide which generated artifacts belong in version control. 4. Install `graphify hook install` once in each clone. 5. Run `graphify update .` after pulls and merges. The upstream project recommends committing `graphify-out/` to share a starting map. Review generated files first; they contain source-derived information. Keep local cost reports out of version control: ```gitignore theme={null} graphify-out/cost.json ``` You can also exclude `graphify-out/cache/` to reduce repository size, at the cost of less cache reuse. The portable manifest uses relative paths and is re-anchored on load. ## One graph per worktree Avoid multiple branches writing into one output location. Set `GRAPHIFY_OUT` to a worktree-specific directory when you use a shared or custom output setup. ## Shared MCP Run a [shared HTTP MCP endpoint](/mcp/shared-http) if several clients should query one managed graph. Define who refreshes it, which revision it represents, and who is allowed to access it. ## Review related pull requests [PR context](/guides/pull-requests) helps spot changes that touch the same files or graph communities. Use it to guide review and merge order alongside your tests and normal code review.