Git & GitHub Basics

Eight examples to get you started with Git and GitHub - six basic and two intermediate.

Prerequisites

• Git installed locally (git --version to check; any recent 2.x release works).
• A GitHub account and, for the push/PR examples, a repository you can push to.
• No AWS SDK install is required for this page - these are general version-control skills every AWS SDK project sits on top of.

Basic Examples

1. Initialize or Clone a Repository

Every project starts with either a new local repo or a copy of an existing one.

# Start a brand-new repo
git init my-aws-project
cd my-aws-project
 
# Or copy an existing one
git clone https://github.com/your-org/aws-sdk-service.git

• git init creates a .git folder that tracks history from this point forward.
• git clone copies the full history, not just the current files, so you can browse past commits immediately.
• Cloning over HTTPS will prompt for credentials; most teams use a GitHub personal access token or SSH keys instead of a password.
• Run git status right after either command to confirm you're in a clean, tracked working directory.

2. Stage and Commit a Change

Git splits "what changed" from "what you're about to save" - staging is that middle step.

echo "print('hello')" > app.py
git add app.py
git commit -m "Add initial script"

• git add moves a file's current contents into the staging area; it does not save history yet.
• git commit takes what's staged and creates a permanent snapshot with a message.
• git add . stages everything changed in the current directory; use it carefully so you don't stage files you didn't mean to commit.
• A good commit message says what changed and why, not just "fix" or "update".

3. Check Status and View a Diff

Before committing, confirm exactly what you're about to save.

git status
git diff

• git status lists modified, staged, and untracked files in one summary.
• git diff shows line-by-line changes for unstaged edits; git diff --staged shows what's already staged.
• Reading the diff before committing catches accidental changes, like a debug print or a stray credential.
• Run both often - they cost nothing and prevent most "why did this change" surprises later.

4. Create and Switch Branches

Branches let you work on a change without touching the shared history until it's ready.

git branch feature/add-retry-logic
git checkout feature/add-retry-logic
 
# Or in one step
git checkout -b feature/add-retry-logic

• A branch is just a movable pointer to a commit; creating one is instant and cheap.
• Work on a feature or fix branch, not directly on main, so the shared branch stays deployable.
• git branch alone lists your local branches; the current one is marked with *.
• Delete a branch after it merges (git branch -d feature/add-retry-logic) to keep the list manageable.

5. Push a Branch and Open a Pull Request

Local commits stay local until you push them to the remote.

git push -u origin feature/add-retry-logic

• The -u flag links your local branch to the remote one, so future git push calls need no arguments.
• After pushing, open a pull request (PR) on GitHub comparing your branch against main.
• A PR is where teammates review the diff, leave comments, and approve before the code merges.
• Push small, focused branches - a PR that touches one concern is easier to review than one that touches ten.

6. Ignore Files That Don't Belong in Git

A .gitignore file tells Git which paths to never track, before you accidentally commit them.

cat > .gitignore <<'EOF'
.env
__pycache__/
*.pyc
node_modules/
.aws-sam/
EOF
 
git add .gitignore
git commit -m "Add .gitignore"

• .env files often hold local AWS credentials or endpoint overrides - never commit them.
• __pycache__/ and *.pyc are Python bytecode caches; node_modules/ is installed JavaScript dependencies - both are regenerated, not authored.
• Add .gitignore entries before the first commit that would include these paths; Git won't retroactively un-track files already committed without an extra step.
• A leaked credential in a committed .env is a real incident even if you delete the file in a later commit - the old commit still has it.

Related: Preventing Leaked AWS Credentials in Commits - what to do if a secret slips past .gitignore.

Intermediate Examples

7. Merge a Branch and Resolve a Conflict

Merging brings a branch's commits into another branch; conflicts happen when both branches changed the same lines.

git checkout main
git pull
git merge feature/add-retry-logic
 
# If a conflict appears, Git marks it in the file:
# <<<<<<< HEAD
# ...current main content...
# =======
# ...incoming feature branch content...
# >>>>>>> feature/add-retry-logic
 
# Edit the file to keep the right content, then:
git add app.py
git commit

• git pull before merging brings main up to date so you're merging against the latest shared history.
• A conflict marker means Git couldn't automatically decide which version to keep; you choose by editing the file directly.
• After resolving conflict markers, stage the file and commit to complete the merge.
• On GitHub, most teams merge PRs through the web UI instead of the command line, but the underlying operation is the same.

8. View and Search History

Once a repo has real history, git log and its variants help you find when and why something changed.

git log --oneline -10
git log --oneline --follow -- app.py
git blame app.py

• git log --oneline gives a compact one-line-per-commit view; add -10 to limit how many you see.
• --follow -- app.py shows the history of a single file, including across renames.
• git blame shows which commit last touched each line - useful for finding who introduced a config value or a hardcoded region string.
• These commands are read-only and safe to run at any point; use them before assuming a change is a mystery.

Related: Git Workflows for AWS SDK Teams - how branching and PRs fit together on a real team.

Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+). 636f64656775696465732e696f7c6367696f313138397c323032363037