Save a version with Git

3 minute read · Projects & Git

A Git commit saves a named version of your project locally. It gives you a concrete point to review later as the app changes.

• Save one understandable change
• Understand synchronization controls
• Resolve a conflict with evidence
• Connect GitHub or GitLab
• Work through Git Flow

Save one understandable change#

Open source control and confirm the checkout and branch. Inspect staged, unstaged and untracked files. Use explicit staging if the commit should contain only part of the current work; otherwise review the full change set before choosing the all-changes commit action. Write a message that explains the resulting behavior, such as “Keep article edits after reload”. Commit-message assistance proposes text for review, not permission to commit without checking the files.

Manual commit is available independently of an active agent. It does not require the automatic-commit proof conditions, so you remain responsible for choosing the right snapshot. A Git error must be resolved before treating the commit as saved.

Understand synchronization controls#

Fetch refreshes remote information. Pull brings remote changes into the current checkout; push sends local commits to the remote. Publish branch is a distinct action for a branch that needs an upstream. The synchronize action pulls when behind and pushes when ahead, subject to the current checkout conditions. Review incoming/outgoing counts and branch information before invoking it.

A commit stays local until you explicitly push. Successful tests or automatic commit do not authorize a push or deployment. A dirty checkout, an active operation or a changed branch may require attention before a mutation can continue.

Resolve a conflict with evidence#

Read which files conflict and which operation stopped. Inspect both intended changes, resolve the content and run the relevant checks again. Avoid discarding all local work just to make a pull succeed. Branch history shows bounded commits, parents, refs and tags so you can identify the intended base.

Git flow feature/release/hotfix operations use the configured conventional branches. Finishing a flow should identify the target and report partial failures; it does not silently authorize tagging, pushing or deployment. For independent checkout work, use worktrees.

Connect GitHub or GitLab#

Open Account → Integrations and connect the hosting account through the available browser sign-in flow. Review the requested provider access and return to Vortex. The hosting account is separate from your Vortex login and your coding-agent account. Git credentials and tokens belong in protected integration settings, not project prompts.

Choose the repository and visibility before creating a remote or publishing a branch. Check the remote URL and branch/upstream in source control. Being able to list repositories does not prove that the account can push to a protected branch. A denied push may need repository permission, a review or a different target branch rather than another local commit.

Work through Git Flow#

Use feature, release or hotfix operations when the repository follows those conventional branches. Inspect the configured base and current branch before starting. Keep the change bounded, review its diff and run the project's checks before finishing it.

Finish shows the target branches and reports any partial merge failure. Resolve that state before repeating the operation. Finishing is not permission to delete other work, create a tag, push or deploy automatically. Decide those actions separately and verify the hosting service's result after an authorized push. For simultaneous tasks that should not share files, use worktrees.

Related guides: worktrees, automatic commit conditions.