Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

bobwurtz's avatar

Adding a Team Member

Hey All - I've been working on a solo project for a while now and I'm approaching the point where I might bring someone else into the project. My general question is - what are the best practices for doing this?

More specifically:

  • How do I share the code with them? If they are using their own device, do I ask for a public key and add access for them on Github?
  • How do I protect the master branch? I see that Github offers 'protected branches' but I have no experience with them. Is there a better way?
  • Do you all have a CI/CD pipeline you have found that works well? I see there is an episode on CI but it is almost 6 years old, so I'm wondering if something better exists now.
  • What is the best practice for sharing security credentials they will need (AWS, Stripe, other third parties)?
  • How do I make sure they can't do something destructive?
  • Should they have their own staging/testing environment (I use Vapor - if that matters)?

I know these answers are probably not Laravel-specific, but I thought this would be a place with a lot of knowledge on this topic. Thanks!

0 likes
2 replies
LaryAI's avatar
Level 58

Adding a team member to a project involves several considerations. Here are some best practices to follow:

  1. Sharing Code:

    • If your project is hosted on GitHub, you can add the team member as a collaborator to the repository. They will then have access to clone, push, and pull changes.
    • You can also use version control systems like GitLab or Bitbucket, which offer similar collaboration features.
    • Alternatively, you can share the codebase with them directly by creating a zip file or using a file-sharing service like Dropbox or Google Drive.
  2. Protecting the Master Branch:

    • GitHub's "protected branches" feature allows you to define rules for branch protection. You can enforce code reviews, require status checks, and restrict who can merge changes into the master branch.
    • Another approach is to use a branching strategy like GitFlow, where the master branch is only updated with stable releases, and development happens on feature branches.
  3. CI/CD Pipeline:

    • There are several CI/CD tools available, such as Travis CI, CircleCI, and Jenkins. These tools automate the build, test, and deployment processes.
    • Choose a CI/CD tool that integrates well with your project's technology stack and provides the features you need.
    • Laravel itself has built-in support for CI/CD through Laravel Envoyer and Laravel Forge.
  4. Sharing Security Credentials:

    • Avoid sharing sensitive credentials directly. Instead, use environment variables to store credentials and share them securely.
    • You can use tools like Laravel's .env file or services like AWS Secrets Manager or HashiCorp Vault to manage and share credentials securely.
  5. Preventing Destructive Actions:

    • Grant team members appropriate access levels based on their responsibilities. Limit access to critical systems and ensure they have read-only or restricted access where necessary.
    • Regularly review and audit access permissions to ensure they align with the team member's role.
  6. Staging/Testing Environment:

    • It's generally a good practice to provide team members with their own staging or testing environment.
    • If you use Laravel Vapor, you can create separate environments for each team member using the vapor env command. This allows them to test changes without affecting the production environment.

Remember, these practices may vary depending on your specific project requirements and team structure. Adapt them to fit your needs and consider seeking advice from experienced developers or project managers.

tangtang's avatar

@bobwurtz

just pointing on this issue

How do I make sure they can't do something destructive?

this issue can be more easy to solve if they really do something destructive. using some version control like Git feature you can see what the changed line or code they push in branch.

but how about if they aren't do it on purpose, just like they code but not even know the code they make (maybe because not fully test on flow or lack of structure) can cause bug to apps.

you can't avoid that 100% clearly.

but you can maintain the apps and the team if you have a good leader on team. this leader must really know what the team needs to do.

Please or to participate in this conversation.