Git is usually treated as a separate developer tool. The repository lives in one service, issues in another, product decisions in documents, customer feedback in a helpdesk, and everyday discussion in chat. The code may be well organized while the reason behind the code is scattered across five different places.
Aamu.app takes a different view. Git is part of the shared workspace. Repositories, branches, commits, pull requests, code review comments, tasks, Docs, meetings, support conversations, and notifications can live inside the same team and project context.
The useful part is not simply that Aamu can host a Git repository. The useful part is that the repository does not become an island.
Code has context outside the repository
A code change rarely begins with code. It may begin with a customer reporting a bug, a product discussion in a meeting, a task created from support, or a decision written in a Doc.
When Git is a separate destination, the team has to carry that context across tools. Someone copies a support link into an issue. Another person pastes the issue into a pull request. The final decision stays in a comment thread that the rest of the team may never see.
Inside Aamu, the repository belongs to a project. The same project can contain the tasks, documents, conversations, meetings, files, and customer work surrounding the implementation. The team can move from the reason for a change to the code itself without leaving the workspace.
Repositories and issues share the same project
Aamu repositories have their own linked task view. These tasks can work as practical issues for the repository: bugs, features, maintenance work, review follow-ups, or release tasks.
A repository shows its active and completed task counts, and new tasks can be created directly in the repository context. The task still has the normal Aamu work features around it, including assignment, status, due dates, comments, attachments, reminders, and project visibility.
This keeps engineering work connected to the broader team. A support person does not need to learn a separate issue tracker just to follow a reported bug. A project lead can see the task in the same workspace as the meeting or Doc that produced it. A developer can open the repository from the work item and return to the surrounding discussion when needed.
Pull requests are team conversations
Aamu supports the normal pull request workflow: compare a branch with the default branch, open a pull request, review its commits and changed files, discuss the change, merge it, close it without merging, or reopen it later.
The conversation is not only a description attached to a diff. Pull requests have their own comment thread, and reviewers can also discuss specific lines in changed files. Inline review comments remain anchored to the relevant file, line, and side of the diff.
That distinction matters. A general comment can discuss architecture, scope, testing, or release concerns. A line comment can point to one exact implementation detail. Both stay connected to the pull request and visible to the people participating in the review.
Unread comments become shared awareness
The quiet failure mode of code review is not usually that comments cannot be written. It is that the right person does not notice them, or notices them once and then loses the thread.
Aamu tracks unread activity around pull request discussions and inline code comments. Comment counts, participants, and unread indicators help show where a review is still active. Git-related activity can appear alongside the workspace's other notifications instead of requiring the team to maintain a separate notification habit for every service.
This creates a more useful kind of awareness. A developer can see that a reviewer replied on a line. A project member can notice that a pull request discussion is still unresolved. The notification leads back to the exact repository, pull request, file, and line where the conversation belongs.
The repository is usable from Git and from the browser
Developers can use repositories through normal Git workflows with SSH keys. Aamu shows the repository's SSH address and lets each user manage Git SSH keys from their settings.
The browser interface is useful when the team needs to inspect or make a small change without switching tools. Aamu can show the repository tree, branches, commits, commit diffs, pull requests, and changed files. Files can also be created or edited in the browser and committed with a message.
The browser is not meant to replace a developer's local editor. It gives the rest of the team a readable window into the code and provides a quick path for small documentation, configuration, or content changes.
A practical connected workflow
Consider a customer-reported bug:
The report arrives in Aamu Helpdesk.
The support person creates a task for the internal follow-up and links the customer context.
The task is associated with the relevant repository and assigned to a developer.
The developer creates a branch, implements the fix, and opens a pull request.
A reviewer comments on the pull request or on an exact line in the diff.
Unread indicators and notifications keep the review visible until the discussion moves forward.
The pull request is merged and the task is completed.
The support person returns to the original ticket with the implementation status and can answer the customer.
Every step has its own proper object: the customer conversation remains a Helpdesk ticket, the internal follow-up is a task, the implementation is a branch and pull request, and review details stay attached to the code. They still belong to one project workspace.
Fewer integrations to babysit
Teams often try to recreate this workflow by connecting a Git host, issue tracker, chat service, documentation tool, and helpdesk with bots and webhooks. That can work, but the integration layer becomes another system the team has to understand.
A link preview is not the same as shared context. A bot message saying that a pull request changed does not necessarily preserve the task, customer request, decision, review conversation, and notification state around it.
Aamu's approach is simpler: keep the objects in the same workspace model from the beginning. The repository is project-scoped. The tasks are project-scoped. Comments and notifications know which team and project they belong to. Access follows the workspace instead of being reconstructed separately in every integration.
What Aamu Git is for
Aamu Git is a good fit for teams that want code hosting and review close to everyday product work. It is especially useful for small product teams, agencies, consultancies, internal tool teams, and organizations where developers work closely with support, operations, content, or customer-facing colleagues.
The point is not to claim that every team needs to replace a large dedicated developer platform. Teams with highly specialized enterprise release processes, large extension ecosystems, or deeply established external CI/CD infrastructure may prefer to keep their existing Git host.
The Aamu question is narrower and more practical: if code, issues, comments, notifications, customer feedback, and project knowledge already depend on each other, how much coordination work is created by keeping them in separate products?
The bottom line
A Git server stores code. A shared workspace keeps the team oriented around why the code is changing, who is waiting for it, what was discussed, and what should happen next.
Aamu.app brings those two ideas together. Repositories, branches, commits, pull requests, inline review comments, issue-like tasks, and unread notifications live in the same project environment as Docs, meetings, Helpdesk, email, chat, and the rest of the team's work.
That is the larger value of Git in Aamu: the code stays versioned, while the context stays with the team.