Git spaces guide

A Flow Git repository is a real repository (you clone it and push to it with the git you already use) that lives inside Flow instead of on an external service. Code, tasks and pull requests sit where your files are: same sign-in, same members and permissions, same safety copy, same instance: in Europe or at your company.

It is made for teams that do not want (or are not allowed) to let their code leave: the repository is a space like any other, with its own members and two roles (editor pushes, viewer clones and reads), plus the administrators, who can do everything. Repositories appear in the Repositories section of the sidebar, and they count towards the plan's quota like everything else.

In the browser you will find five tabs: Code, Commits, Tasks, Pull requests and Access. The first two are for looking, the others for working: teamwork (who does what, what goes into the main branch) happens there.

Clone and push go over HTTPS, with credentials made for the purpose:

• user name = your email;
• password = a Git password, which you create yourself in the repository's Access tab ("How to connect", with the clone command ready to copy).

The password is shown only when you create it: save it in git's credential manager (osxkeychain on a Mac, Git Credential Manager on Windows) and you will not be asked for it again. If you lose it, it cannot be recovered: you create a new one and revoke the old one. You can see and revoke your Git passwords in Account → Git; a password works for all the repositories you have access to, and for nothing else: it does not open the app and does not work for the API.

Your role in the space decides who can do what: editor pushes branches and tags as with any remote, viewer can only clone and fetch. People who are not members do not see the repository at all.

The Code tab shows the file tree for the selected branch, and the repository's home page opens the README at the root, as you would expect. Text files can be read there; for a binary or a very large file, the browser does not pretend: it tells you to clone.

The Commits tab is the branch's history: each commit opens on its diff. In the text of tasks and comments, a sha takes you straight to the diff of that commit.

The browser is made for reading and deciding: you write locally, in your own editor, and push. The only write that goes through the web is the one that has to: merging a pull request.

Tasks are where the team talks: bugs to fix, changes to request, things to do, discussions. There are four types (Bug, Change request, To-do, Discussion) and otherwise the same shape: title, Markdown text, comments, open/closed status.

Every task has a number: writing #12 in a task, a comment or a pull request creates the link; a commit sha becomes the link to its diff. A task can have an assignee (one of the members), labels and a priority; the filters at the top of the list ("Open", "My tasks", search) help you find your way when there are many tasks.

You can see what you have not read yet: a task with news is shown in bold, and the tab shows an "unread" counter. Emails follow your preference in Account → Email notifications → Tasks: people taking part in a task (author, assignee, anyone who has commented) receive assignments, comments and closures.

You can attach files to a task: they go into a "Task #n" folder in the space, and the text keeps a reference to them. Useful for screenshots, logs and starting documents: they stay in the repository of the people working on it, not in an external chat.

A pull request proposes merging one branch into another. You open it by choosing the two branches (one open PR per branch at a time), and the tab tells you immediately and live how things stand: "Merges cleanly: n commits", or the list of conflicting files, which you resolve locally, and on the next push the tab updates.

Below are the incoming commits and the full diff. You can comment at the bottom or on a single line of the diff: each line opens a thread with Reply and Resolve, and threads on lines changed by a new push are not lost: they move to the end, with their path and line number.

Reviews give the verdict: Approve or Request changes (never on your own PR). Each person's latest verdict is the one that counts, and an approval applies to the version of the branch it was given on: after a new push it is marked "on an earlier version of the branch" and no longer counts.

Merge from the web, choosing how the commits come in:

• merge commit: the history stays as it is, with a merge commit signed by whoever clicks;
• squash: all commits squashed into one, signed by whoever opened the PR;
• rebase: the commits replayed in a row on top of the target, with no merge commit.

There is an option to delete the branch after merging, and if you merge from the terminal with git instead, the PR notices on its own and is marked "Merged with git".

On a protected branch nobody pushes directly, not even editors: anyone who tries gets a refusal from the server, stating why. There is only one way into the branch: by merging a pull request from the web.

You protect a branch from the Access tab (an administrator is required), and for each branch you can require a number of approvals: the PR can be merged only when there are enough approving reviews, and a "request changes" review blocks it until it changes. The administrator can still merge: the rule brings discipline to the team without taking the keys away from the administrator.

It is the way to say "main is reached only through a reviewed PR", and to have the server enforce it instead of a verbal agreement.

Every push is made safe immediately, in the same protected storage as your files: redundant copies, continuous checks, automatic repair. There is nothing to configure and nothing to remember.

The repository page tells you when the last copy was made ("Safety copy up to date…") and, if a copy has failed, it says so.

In the plan's quota, the repository weighs what it really weighs, with the same deduplication that applies to everything else: a normal repository takes up little space.

The Git password also opens one more door: the API routes for tasks and pull requests (/api/repos/…/tasks and /api/repos/…/pulls). With an authenticated curl (user your email, password your Git password), you can list tasks, read a PR, comment, and attach a file to a task or a PR. Only those routes: for the rest of the API you need a real API token (see the Developers page).

It is useful for anyone who automates their own workflow (scripts, development tools, agents) without handing out credentials broader than necessary: the Git password can always be revoked in one click from Account → Git, and its scope is work on the repository.