Best Practices
Everything in this chapter has been about what the panel can do. This final section is about how to use it well. None of these are hard rules — they are habits that have consistently paid off when versioning flow and load-test work inside a team, and every one of them is supported by a feature you have already seen in an earlier sub-section.
Commit Small, Commit Often
One cohesive change per commit is the single most valuable habit you can adopt. A commit that says "tightened the checkout flow assertions"with three assertion edits is easy to understand, easy to review, and easy to revert. A commit that says "misc" with fifty unrelated edits is none of those things.
Commit Mode is built for this: the checkbox file picker lets you include only the files that belong to the current change even if your working tree has unrelated edits as well. Tick the cohesive subset, write a message that explains why (not just what), and commit. The unrelated edits stay in the working tree for their own commit.
Branch per Feature or Scenario
Branches are cheap in the panel. Creating one is a few clicks in the Branches section, and the uncommitted-changes guard means switching between them is always a deliberate, safe action. Use that cheapness:
- •For flows: one branch per non-trivial change. A new flow, a big refactor of an existing flow, a risky assertion tightening — each is its own branch. When it looks good on the branch, merge back to main.
- •For load-test specs: one branch per scenario you want to try. Aggressive Stress profile? Branch. Different threshold? Branch. Run the test on the branch, compare results, then merge only if the experiment is worth keeping.
Because every group is its own repository, branches in one group never pollute another. You can have a dozen experimental branches in one spec group and leave every other group pristine.
Review the Diff Before You Push
The Changes section's diff viewer is there to catch surprises before they leave your machine. Before every push, take thirty seconds to scroll through the diff for every file on the commit and confirm it matches what you think you changed. You will occasionally catch:
- •A step you edited and then meant to revert but forgot.
- •A threshold that was relaxed while debugging and was never put back.
- •A temporary hard-coded URL you used to test a staging endpoint.
Side-by-side view is the better choice for verifying small surgical edits; unified view is more compact when the diff is long. Whichever you prefer, the Discard action in the same section is one click away if you spot something that should not be in the commit at all.
Use Compare Before You Merge
Before clicking Merge into current on a non-trivial branch, open the Branch Compare view on it first. The two-lane graph and the file list together give you a quick answer to three questions:
- •How diverged are we? The ahead / behind counts tell you if this is a quick fast-forward or a real merge.
- •Are we fighting over the same files? If the file list shows a lot of overlap between what you touched on each side, conflicts are likely and you want to know in advance.
- •Is any of this a surprise? Drilling into individual commits from the graph lets you spot an unexpected change before it becomes part of your main branch.
Thirty seconds in Compare can save you ten minutes of conflict resolution afterwards — and occasionally reveals that the merge is a bad idea at all.
Stash vs. Commit: Quick Triage
When you have pending changes and need to do something else, you have two tools. Picking the right one is mostly about how finished the work is:
- •Stash it when the work is half-formed, experimental, or you are not yet sure it is worth keeping. Stashes are perfect for "I was tinkering with this and need to go check something else" moments. They do not pollute the branch history and they are trivially drop-able.
- •Commit it on a branch when the work is a coherent step forward — even an unfinished one. A branch with a "WIP: new checkout flow" commit is easier to come back to a week later than a stash you cannot remember the context of.
The uncommitted-changes checkout guard dialog gives you both options side by side — Go to Commit and Go to Stash — exactly because the right answer depends on the situation. Make the decision consciously rather than always picking the same one.
Auto-Generated Commit Messages Are a Starting Point
The sparkles button in the commit form produces a commit message from the current staged changes. It is a useful shortcut and often gets most of the what right — "added assertion on X", "renamed step Y", and so on. It does not know the why, because the why lives in your head, not in the diff.
Treat the suggestion as a draft you are expected to edit. Click the chip to fill the input, then add the intent — which ticket it addresses, which previous bug it prevents, which SLO it protects. A good commit message is the one sentence your future self will thank you for when reading the History section six months later.
That is the complete tour of the Git panel. Pair these habits with the features from the earlier sub-sections and versioning your Tigrister work becomes as routine as versioning any other part of your stack — with the added bonus that everything lives inside the same application you use to build and run the tests in the first place.