Short answer: How Aamu.app keeps Git repositories, issue-like tasks, pull requests, code review comments, and notifications inside one shared team workspace.
A code change often starts with a customer report, task or product decision. Aamu Git keeps the repository in the project that holds that context.
Repositories, branches, commits, pull requests and review comments sit alongside Tasks, Docs, meetings and Helpdesk conversations.
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.
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.
Pull requests have a discussion thread and inline comments anchored to a file, line and side of the diff.
Reviews and branch protection make decisions explicit
A pull request now shows reviewers’ submitted decisions and its approval count. A signed-in reviewer can approve a pull request or withdraw their own approval; the author cannot approve their own change. The review remains attached to the pull request, where the team can see whether it is ready to merge.
Team administrators can protect a repository’s current default branch from direct pushes, including force pushes by administrators. They can require a chosen number of pull request approvals before a merge. When Aamu CI is enabled for that repository, they can also require its check to pass. Protection applies to the selected default branch; if the default branch changes, its rule should be reviewed.
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.
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.
Repository settings and one-way mirrors
Repository administrators can manage the name, description, website, default branch, merge methods, and whether a source branch is deleted after merging. These settings sit beside the code and pull requests in the repository view.
Aamu can also push a repository to an existing GitHub, GitLab, or Bitbucket repository over HTTPS. Administrators can choose a branch filter, synchronize on commits, trigger a sync manually, and see the latest sync time or error. This is one-way push mirroring, not two-way collaboration: destination changes can be overwritten, so the destination should be treated as a mirror.
Checks beside the pull request
Aamu Git includes CI settings at team and repository level. A team can define defaults and a repository can opt in to them, or an administrator can configure that repository’s check command, push and pull request triggers, and time limit. When CI is enabled and a runner is available, Aamu runs the check for the commit, shows its status and log in the repository and pull request views, and can use the result as a required check for the protected default branch.
The check runs in an isolated environment without network access, so its command must work with the files and tools already available there. Team administrators can store CI secrets separately and select which ones a repository receives. CI availability depends on the deployment and repository settings; configuring a command alone does not start a run.
Git also has a project-scoped API
The Aamu REST API can list and create repositories, read and update files, list or create branches, inspect commits and diffs, and create or act on pull requests. It also exposes repository settings, default-branch protection, push mirrors, CI settings and run history. API keys use Git permissions: reading code and run results requires read access, writing code and pull requests requires write access, and administrative settings require the Git admin scope. Requests are scoped to the Aamu project, so automation can work with the same repository context as the browser.
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.
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.