Git Notes
Learn to create and manage GitHub Personal Access Tokens for API access, Git authentication, and automation. Understand token scopes and security best practices.
Back in 2021, GitHub deprecated password authentication for Git operations over HTTPS. If you try to push using your GitHub password today, you get a clear rejection: "Support for password authentication was removed." Personal Access Tokens (PATs) are one of the replacement mechanisms, and understanding them is essential for any developer who uses HTTPS URLs or needs programmatic access to GitHub.
A Personal Access Token is essentially a password with superpowers: it can be scoped to specific permissions, set to expire after a defined period, restricted to certain repositories, and revoked independently without affecting your account password. Think of it as a specialized key that opens only the doors you designate.
Types of Personal Access Tokens
GitHub offers two generations of tokens with very different security models:
| Feature | Fine-Grained (Recommended) | Classic (Legacy) |
|---|---|---|
| Repository access | Per-repository selection | All repositories |
| Permissions | Granular (40+ individual) | Broad scopes |
| Expiration | Required (max 1 year) | Optional |
| Organization approval | Can require admin approval | No approval needed |
| Audit visibility | Full audit trail | Limited |
| Best for | Production automation | Quick personal scripts |
Always prefer fine-grained tokens for any serious use case. Classic tokens grant overly broad access.
Creating a Fine-Grained Token
Navigate to: Settings → Developer settings → Personal access tokens → Fine-grained tokens → Generate new token
| Token name | deploy-production-app |
| Expiration | 90 days (or appropriate period) |
| Description | "Used by CI/CD to deploy main branch" |
| Resource owner | your-organization |
| Repository access | Only select repositories |
| Contents | Read and write (needed for git push) |
| Pull requests | Read (needed to check PR status) |
| Actions | Read and write (needed to trigger workflows) |
| Members | Read (only if needed) |
After creation, the token is displayed once. Copy it immediately — you cannot view it again.
Using Tokens for Git Authentication
Method 1: Credential Helper (Recommended)
# Store credentials securely using the system credential manager
# macOS:
git config --global credential.helper osxkeychain
# Windows:
git config --global credential.helper manager
# Linux (stores in memory for session):
git config --global credential.helper cache --timeout=3600When you next push or pull, enter your token as the password. It gets stored securely.
Method 2: Inline URL (Scripts and CI)
# Clone with token embedded in URL
git clone https://oauth2:ghp_xxxxxxxxxxxxxxxxxxxx@github.com/org/repo.git
# Set remote URL with token
git remote set-url origin https://oauth2:ghp_xxxxxxxxxxxxxxxxxxxx@github.com/org/repo.gitWarning: Never hardcode tokens in scripts committed to version control. Use environment variables.
Method 3: Environment Variable (Best for Automation)
# Set the token as an environment variable
export GITHUB_TOKEN=ghp_xxxxxxxxxxxxxxxxxxxx
# Use with Git credential helper
git config --global credential.helper '!f() { echo "password=$GITHUB_TOKEN"; }; f'
# Or use GitHub CLI which handles auth elegantly
gh auth login --with-token <<< "$GITHUB_TOKEN"Using Tokens in CI/CD Pipelines
GitHub Actions (Built-in Token)
Cross-Repository Access (Custom Token Required)
# When you need to access another repository
jobs:
trigger-deploy:
runs-on: ubuntu-latest
steps:
- name: Trigger deployment in another repo
env:
PAT: ${{ secrets.CROSS_REPO_TOKEN }} # Stored as repository secret
run: |
curl -X POST \
-H "Authorization: token $PAT" \
-H "Accept: application/vnd.github.v3+json" \
https://api.github.com/repos/org/deploy-repo/dispatches \
-d '{"event_type":"deploy","client_payload":{"version":"${{ github.sha }}"}}'Token Security Best Practices
- Always set expiration dates: Never create tokens without expiry. 90 days is a good default for automation; shorter for sensitive access.
- Principle of least privilege: Grant only the exact permissions needed. If a token only needs to read code, do not give it write access.
- Use fine-grained tokens: Scope to specific repositories rather than account-wide access.
- Rotate tokens before they expire: Set calendar reminders to generate replacements before expiration causes service outages.
- Never commit tokens to repositories: Use environment variables, CI/CD secrets managers, or secret vaults.
- Revoke immediately if exposed: If a token appears in logs, screenshots, or is accidentally committed, revoke it instantly.
- Audit active tokens regularly: Review Settings → Developer settings → Personal access tokens and revoke any you do not recognize or no longer need.
# Check if a token has been exposed in your repo history
git log --all -p | grep -i "ghp_\|github_pat_"Revoking and Managing Tokens
When you revoke a token, any automation using it immediately stops working. Plan replacements before revoking production tokens.
Common Mistakes
Mistake 1: Using a classic token with full repo scope for a CI/CD pipeline. This gives the pipeline access to every repository on your account. Use fine-grained tokens scoped to the specific repository.
Mistake 2: Committing tokens to .env files that are not properly gitignored. Always verify .env is in your .gitignore before committing.
Mistake 3: Creating tokens without expiration. Tokens without expiry that are forgotten about become permanent security risks. Always set an expiration.
Mistake 4: Sharing tokens between services. Each service should have its own dedicated token so you can revoke access to one without affecting others.
Interview Questions
Q1: What is a Personal Access Token and why is it needed?
A PAT is a credential that replaces your password for Git operations over HTTPS and GitHub API access. GitHub removed password authentication in 2021, making tokens (or SSH keys) mandatory. Tokens provide scoped, revocable, time-limited access without exposing your account password.
Q2: What is the difference between fine-grained and classic tokens?
Fine-grained tokens can be scoped to specific repositories with granular permissions (40+ individual settings) and require expiration dates. Classic tokens have broad account-wide scopes, optional expiration, and access all repositories. Fine-grained is significantly more secure.
Q3: Why should tokens always have expiration dates?
Expiration limits the damage window if a token is compromised. A leaked token that expires in 30 days is far less dangerous than one that never expires. It also forces regular rotation, ensuring tokens reflect current access needs.
Q4: How should tokens be stored in CI/CD environments?
Use the platform's secrets management: GitHub Secrets for Actions, AWS Secrets Manager, HashiCorp Vault, or similar. Never store tokens in workflow files, environment files committed to repos, or plain text configuration.
Q5: What is the GITHUB_TOKEN in GitHub Actions?
An automatically generated token available in every workflow run, scoped to the repository with permissions defined in the workflow file. It expires when the workflow completes and requires no manual creation or rotation. It cannot access other repositories.
Exam Focus
Revise definitions, diagrams, examples, and short-answer points for Personal Access Tokens - Authenticate with GitHub.
Interview Use
Prepare one clear explanation, one practical example, and one common mistake for this Git & GitHub topic.
Search Terms
git-github, git & github, git, github, security, personal, access, tokens
Related Git & GitHub Topics