Git workflow setup for two developers with GitHub and issue tracking integration

I’m starting a new project with two developers and need advice on setting up our version control workflow. We want to use Git with GitHub for our code repository and integrate it with our bug tracking system.

I have experience using Git mostly for personal backups, but this is my first time setting up a collaborative development environment. Here’s the issue I’m facing:

Our bug tracker has a service hook that connects to GitHub. When someone pushes code to the repository, it automatically updates tickets and can mark them as resolved. The problem is that this integration uses a single authentication token, so all updates appear to come from the repository owner regardless of which developer actually made the changes.

I’m thinking we might need separate GitHub repositories for each developer, but I’m not sure about the best workflow. Should we each have our own fork? How do we keep everything synchronized?

What’s the recommended approach for handling pushes, pulls, and merges in this setup? Is there a better way to solve the authentication issue with the bug tracker integration?

The authentication token issue you’re experiencing is quite common with legacy bug tracking systems. I’ve dealt with this exact problem in several projects. Instead of creating separate repositories, consider using a hybrid approach that preserves developer attribution while maintaining the integration. One effective solution is to implement a webhook middleware that intercepts the GitHub events before they reach your bug tracker. This middleware can parse the commit author information and forward the request with appropriate context about who actually made the change. I built something similar using a simple Node.js service that sits between GitHub and our ticketing system. For the Git workflow itself, stick with a single repository using feature branches. Each developer works on their own branches for features or bug fixes, then creates pull requests for code review before merging to main. This approach keeps your integration intact while providing proper attribution in commit history. If building middleware isn’t feasible, many teams simply include developer initials or usernames in commit messages as a workaround. It’s not elegant but ensures accountability in ticket updates.

honestly just use a standard fork workflow - its way simpler than you think. each dev forks the main repo, works on thier own copy, then submits pull requests back to the original. no need for complex middleware solutions or seperate auth tokens. the bug tracker integration will work fine from the main repo, and you’ll still see individual commit authors in the git history anyway.