Images are AI-generated illustrations, not documentary photographs or product screenshots.
Git workflow: use version control to make changes understandable
Git is valuable because it records changes and supports collaboration, not because it magically makes a project safe. A freelance client project needs a workflow that another person can understand after you leave. GitHub documents GitHub flow as a lightweight, branch-based approach. Adapt it to the project’s requirements rather than adopting a complex branching strategy by habit. Agree on repository ownership, access and review responsibilities before beginning important work.
Keep the default branch predictable
Clarify what the default branch represents and who can update it. It might represent reviewed code, but that does not necessarily mean every commit has already been deployed. Document the relationship between source code, staging and production. Use appropriate protections when the platform and project support them. Do not treat a branch name as a security boundary by itself; credentials, permissions and deployment systems need separate controls.
Create a branch for a coherent change
Use a descriptive name that identifies the work, such as fixing a layout issue or improving a documented feature. Keep unrelated changes separate when practical. GitHub’s guidance explains that a branch lets you work without immediately affecting the default branch and gives collaborators a place to review. Make focused commits with messages that explain the change. Avoid a single unexplained upload that mixes a redesign, plugin updates and unrelated configuration edits.
Write a pull request that supports review
Explain the problem, the proposed solution, the tests performed and any limitations. Include useful screenshots for visual changes without exposing private information. Link the relevant issue or brief when appropriate. Use a draft pull request when you want early feedback. A reviewer should not have to infer the entire project context from a code diff. Good documentation also helps a future maintainer understand why a decision was made.
Handle feedback and checks before merging
Respond to review comments and update the branch as needed. Check the relevant tests and verify the behavior in the appropriate environment. GitHub flow includes addressing feedback and merging after approval, while repository protections can impose additional requirements. Automated checks are helpful but cannot prove every business requirement. For a client website, still test the important page, form or purchase flow affected by the change using a safe, authorized process.
Keep secrets and private data out of the repository
Do not commit passwords, API keys, customer exports or private backup files. Use approved secret-management and configuration practices for the environment. If a credential is exposed, deleting it in a later commit does not necessarily remove it from history or other copies; follow the relevant incident and rotation process. Review repository visibility and collaborator access. A private repository is not a reason to store unnecessary sensitive material in version control.
Treat deployment and handover as explicit steps
Merging code does not replace a deployment plan, a backup or a rollback procedure. Document how a reviewed change reaches production, who approves it and how important behavior is verified afterward. After merging, remove completed branches where appropriate and leave the client with repository access, setup instructions and an understandable history. The goal is not an elaborate Git ritual. It is controlled change, reviewable work and a maintainable project.
Sources and further reading
Related reading
Writing a Useful Bug Report for a Software Team
Software Dependency Security: What Maintainers Should Review