Reviews and quality
Parallel work
How Yavaren keeps stories that change the same files from conflicting, and what it tells you about the order to merge.
Your engineers often work on several stories of one repository at the same time. When two of them change the same files, the second pull request would conflict with the first as soon as the first is merged. Yavaren checks for that before it starts.
What Yavaren does
- It predicts what each story will change: from the story's plan, from what a branch already changes, or — before there is a plan — from the story's text and the files in your repository.
- It orders stories that overlap. Stories that touch different code run in parallel, as before. When a story changes the same files as an earlier one (or your tracker says it depends on it), it waits. When the earlier story's pull request exists, the later one is stacked on it: it starts from that branch, and its pull request says "Stacked on PAY-7 — merge PAY-7 first".
- It always follows your tracker's dependencies ("blocks", "is blocked by", "depends on", predecessor and successor links).
- It checks before it pushes: each branch is test-merged with your main branch and with Yavaren's other open branches. Conflicts are written on the pull request.
- It refreshes a branch when related work merges: it brings the branch up to date, runs the checks again and pushes that branch only. If git cannot combine the changes, the agent resolves the conflict using both stories' intents; if it cannot, nothing is pushed and you are asked.
- It never overwrites your commits. If someone pushed commits to a Yavaren branch, Yavaren keeps them. It never merges a pull request.
A story that waits says why, for example: "waiting for PAY-7 because both change shop/discount.py". It starts by itself when that is done.
What you see
- On each pull request: a Related work in progress section with the other stories and pull requests, the files and functions they share, the order to merge, what this change builds on, the test merges and what changed when it was refreshed.
- On the related pull requests: a comment saying which pull request must be merged first.
- On your tracker items: a short comment about the related work and the merge order.
- In Waiting for you: "Merge PAY-7 before PAY-8", and conflicts that need a person.
- In the navigation, Parallel work: for each repository, the stories in flight, why one waits, what is stacked on what, and the order to merge.
What you can do
Members can Start now a story that waits (it may then conflict, and Yavaren refreshes it when the related work merges) and Refresh an open pull request.
Admins choose how stories that change the same files are coordinated, for the organisation or for one project:
- Coordinate (the default): wait for the earlier pull request and build on it, or wait for it to be merged.
- One at a time: a story that touches the same files waits until the earlier one is merged.
- Off: every story runs on its own, as before.