Commit the change

Committing is where your change stops being a file on your laptop and becomes a submitted change. The changelog is the deployable artifact. Version control is the path to execution, and the merge is what hands your change to the pipeline.

Nobody deploys from a laptop. Running update by hand against a shared environment bypasses review, checks, and attribution, and it manufactures drift.

What a reviewer needs

The pull request is the one human control point before automation takes over. Give the reviewer evidence, not promises.

• The changeset itself, small and focused. One logical change per changeset keeps review and rollback tractable.

• Validation output. Run validate before you push. See Validate and preview a change.

• The SQL that will run. For modeled changelogs, attach update-sql output so the reviewer sees the literal statements. See Generate SQL to update database schemas.

• A rollback path. Automatic for many modeled change types, written by hand for SQL changesets. See What is a rollback?.

Branching and merge

Follow your team's branching strategy, and let the merge be the trigger. See Choose a branching strategy. On merge, the pipeline takes it from there, running checks and deploying through the environments you configured. See Design your deployment pipeline.