Loading

Manage Access and Best Practices for Sharing Code

Measures to Control Access and Best Practices:

1. Repository Visibility: Keep it Private!

  • Most Important: Ensure your repository is private. This is fundamental. If it’s public, anyone can see and clone all your code, including all branches, always.
  • If your repository is currently public, navigate to its settings on GitHub, go to the “Danger Zone” section, and change its visibility to “Private.”

2. Invite as an “Outside Collaborator” (Personal Account) or “Member” with Limited Role (Organization Account)

  • Personal Account (Your personal GitHub profile owns the repo):
    • Go to your repository on GitHub.
    • Click “Settings” (usually near the top right).
    • In the sidebar, click “Collaborators and teams” (or “Access” then “Collaborators”).
    • Click “Add people.”
    • Search for their GitHub username or email.
    • Choose “Write” permission. This allows them to push to branches, create new branches, and open pull requests. It does not give them administrative control over your repository.
    • They will receive an email invitation that they must accept.

3. Implement Branch Protection Rules (Crucial for Write Access Control)

This is how you enforce that developers (including freelancers) don’t directly push to sensitive branches like main or develop.

  1. On GitHub:
    • Go to your repository.
    • Click “Settings.”
    • In the sidebar, click “Branches.”
    • Under “Branch protection rules,” click “Add rule.”
    • Branch name pattern: Enter the name of your protected branch (e.g., main, develop). You can create multiple rules for different branches.
    • Recommended settings for protected branches (like main):
      • Require a pull request before merging: This is the cornerstone of good workflow. It means no one (except repository admins, or those explicitly allowed to bypass) can push directly to main. All changes must go through a pull request.
        • Require approvals: Set a number of required reviews (e.g., 1 or 2). This means another person (you or someone else) must approve the changes before they can be merged.
        • Dismiss stale pull request approvals when new commits are pushed: Ensures reviews are fresh.
        • Require review from Code Owners (if you set them up): Good for larger projects.
      • Require status checks to pass before merging (if you use CI/CD): E.g., tests must pass.
      • Include administrators: (Optional but highly recommended) Apply these rules to admins too, to prevent accidental direct pushes.
      • Do not allow bypassing the above settings: Unless you have a very specific reason for an admin to bypass.

4. Workflow for the Freelancer

With the above in place, the freelancer’s workflow will be:

  1. Clone the repository.
  2. git checkout feature/deduction-fix (or whatever branch name you give them).
  3. Make their changes, commit locally.
  4. git push origin feature/deduction-fix (push to their working branch).
  5. Create a Pull Request (PR) on GitHub: From feature/deduction-fix into develop or main (whichever is your integration branch).
  6. You (or another designated reviewer) will then review the PR.
  7. Once approved, you will merge the PR. The freelancer generally won’t have permission to merge into a protected branch themselves.

Best Practices for Sharing Code with a New Freelancer:

  1. Clear Communication:
    • Onboarding: Provide a clear onboarding document or conversation covering your expectations, communication channels, code standards, and the Git workflow.
    • Scope of Work: Clearly define the task, deliverables, and timelines. Use GitHub Issues for task tracking.
    • Code Review Expectations: Explain your code review process.
  2. Start with a Small, Isolated Task:
    • The payroll deduction fix is a good example because it’s a specific, contained problem. Avoid giving them access to the entire codebase for a broad, undefined task initially.
  3. Use Private Repositories: As discussed, essential for proprietary code.
  4. Least Privilege Principle:
    • Grant the minimum necessary permissions. “Write” access is usually sufficient for a developer. Avoid giving “Admin” access unless absolutely necessary.
    • For organizations, use custom roles or teams to fine-tune permissions.
  5. Branching Strategy:
    • Use a clear branching strategy (e.g., GitFlow, GitHub Flow). For a freelancer, a feature branch (feature/deduction-fix) off your develop branch (or main if it’s your primary development branch) is ideal.
  6. Code Reviews (Pull Requests):
    • Always require code reviews for any freelancer’s work before merging into core branches (main, develop). This is your primary quality control and security gate.
    • Provide constructive feedback.
  7. README.md and Documentation:
    • Ensure your repository has a comprehensive README.md with setup instructions, how to run tests, and any critical information about the project structure.
    • Good comments in the code itself are also invaluable.
  8. Environment Variables & Sensitive Data:
    • Never commit sensitive data (API keys, database credentials, secret keys) directly into the repository.
    • Use environment variables (e.g., a .env file that’s .gitignored) for local development and a secure vault (like AWS Secrets Manager, Azure Key Vault, HashiCorp Vault) for production.
    • Instruct the freelancer on how to set up their local environment variables.
  9. Two-Factor Authentication (2FA):
    • Strongly encourage or require all collaborators, especially external ones, to enable 2FA on their GitHub accounts for added security. If you’re on a GitHub Organization, you can enforce this.
  10. Offboarding Process:
    • When the freelancer’s contract ends, immediately remove their access from your GitHub repository (and any other systems they had access to).