Busca en todas las páginas de la documentación
Git itself has no opinion about AWS. A commit is a commit whether it changes a React component or an IAM policy attached to a Lambda function. But the workflow a team builds around Git - which branches exist, how long they live, what a pull request must pass before it merges - matters more when some of those commits can change what your code is allowed to do in a live AWS account.
This page explains the two dominant Git workflows, why most AWS SDK teams land on a variant of one of them, and what changes about branching and review the moment a diff touches infrastructure rather than just application logic.
Trunk-based development means most engineers work off a single shared branch (commonly main), create a short-lived branch for a change, and merge it back within a day or two. Feature-branch workflows (sometimes called Git Flow or a variant of it) instead keep longer-lived branches per feature or release, merging into main only when the feature is complete and stable.
Neither is right or wrong in the abstract. Trunk-based development pairs well with continuous deployment and small, frequent commits; it requires discipline about keeping main always deployable and CI that actually catches problems before merge. Feature-branch workflows suit teams shipping on a slower cadence, or working on changes too large to land safely in pieces, but branches that live for weeks accumulate merge conflicts and drift from what production actually runs.
# Trunk-based: short-lived branch, fast merge
git checkout -b fix/retry-backoff
# ...small change...
git push -u origin fix/retry-backoff
# open PR, review, merge same day
# Feature-branch: longer-lived branch, staged merges
git checkout -b feature/new-ingestion-pipeline
# ...multiple commits over days/weeks...
git merge main # periodically, to stay currentMost AWS SDK teams end up on a pragmatic middle ground: trunk-based for day-to-day application code, with slightly longer-lived branches reserved for genuinely large infrastructure migrations that can't be split further.
What actually differs for AWS SDK work is not the branching model - it's what a reviewer treats as a routine change versus a change that needs a harder look. A pull request that adds a helper function or fixes a typo carries essentially no risk beyond the code itself. A pull request that adds a new IAM permission, changes which region a client targets, rotates how credentials are resolved, or touches a resource ARN carries a different kind of risk: if it's wrong, the blast radius extends into the AWS account itself, not just the application's behavior.
This is why many teams route PRs by content rather than by branch name. A lightweight label or file-path convention flags anything under an infra/, iam/, or cloudformation/ path (or any diff containing strings like PolicyDocument or Effect": "Allow", or a client region override) for a second reviewer or a stricter check, even inside an otherwise trunk-based flow.
# A routine PR: application logic only
git diff main --stat
# src/handlers/process_order.py | 12 +++++++---
# An infra-touching PR: worth a second look
git diff main --stat
# infra/iam/lambda-execution-role.json | 8 ++++----
# src/clients/s3_client.py | 3 ++-The second diff above is small in line count but changes what a running Lambda function is permitted to do in IAM, plus how an S3 client is configured - exactly the kind of change where a fast rubber-stamp review is the wrong instinct, even if the team is otherwise optimizing for merge speed.
At scale, teams formalize this distinction with tooling rather than trusting reviewers to notice. A CODEOWNERS file can require a specific reviewer (often someone on a platform or security team) for paths that touch IAM or CloudFormation. Branch protection rules can require a passing policy-linting check (such as a least-privilege scanner) before merge, on top of the usual test suite. None of this replaces the underlying Git workflow decision - it layers on top of it.
The other dimension that matters at scale is rollback cost. A revert of an application-logic PR is usually a clean git revert and a redeploy. A revert of an infra-touching PR might mean an IAM policy briefly denies an action that live traffic depends on, or a CloudFormation stack update that needs to roll forward rather than back. This asymmetry is a strong argument for keeping infra-touching PRs small and isolated from unrelated application changes - mixing a refactor with a policy change makes both harder to review and harder to safely undo.
Recency matters too: a workflow that made sense for a five-person team doesn't automatically scale to twenty engineers touching the same AWS account. Revisit the workflow when merge conflicts, review bottlenecks, or a near-miss incident on an infra change suggest the current process is straining.
Most teams do best with trunk-based development for day-to-day work - short-lived branches, frequent merges - reserving longer-lived branches for large migrations that genuinely can't be split. The right choice depends more on deploy cadence and CI maturity than on the fact that the codebase uses AWS.
Any change to IAM policies, resource ARNs, client region or endpoint configuration, or infrastructure-as-code templates (CloudFormation, CDK, Terraform). These changes can alter what the running application is permitted to do in AWS, not just how it behaves.
No. Importing an SDK client is routine. The risk signal is in what the diff changes - permissions, credentials, regions, resource identifiers - not in which library the code happens to call.
Common approaches: a CODEOWNERS entry that requires a specific reviewer for infra/ or iam/ paths, a required status check that runs a policy linter, or a label applied by a bot that scans the diff for patterns like PolicyDocument or region overrides.
Reverting an application-logic change is usually a clean git revert and redeploy. Reverting an infra change can leave a policy denying something live traffic depends on, so keeping those PRs small and isolated reduces how much has to be untangled if something goes wrong.
It's best avoided. Mixing the two makes the PR harder to review carefully and harder to revert cleanly, since undoing the infra change would also undo the unrelated refactor.
When merge conflicts or review bottlenecks become frequent, when the team has grown significantly, or after any near-miss where an infra change almost shipped without adequate review.
Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).
Revisado por Chris St. John·Última actualización: 23 jul 2026