Skip to content
Everyone pushed code directly to master.No code reviews.No automated testing before merging.High risk of bugs, conflicts, and unstable code.
Create a new branch for each task (feature, bugfix, etc.).Make changes and commit them to your branch.Push the branch to GitHub.Raise a Pull Request (PR) to master.CI/CD runs automated tests. Reviewer approves the PR.Merge the PR into master.
feature/PCNS-10098fix/PCNS-10098
Go to GitHub.Open a PR from your branch → master.Assign reviewers.
The approach will be similar for the GitHub Desktop, and you have to follow the same approach using the GUI of GitHub Desktop.Never push directly to master.Always raise a PR and wait for approval.Communicate with teammates to avoid working on the same files simultaneously.
Branching Strategy
👋 Introduction
To improve code quality, collaboration, and stability, we’ve adopted a branching strategy that requires all team members to work on separate branches and raise Pull Requests (PRs) for merging into the master branch. This replaces the previous approach where code was pushed directly to master.
🚫 Old Approach
✅ New Workflow Overview
🧠 Branch Naming Conventions
Use clear and consistent names:
🛠️ Git Commands
1. Pull latest changed from master branch
git pull origin master
2. Create a new branch
git checkout -b feature/your-task-name
git branch
3. Check status and stage changes
git status
git add .
4. Commit your changes
git commit -m "Add login page UI"
5. Push your branch to GitHub
git push origin feature/your-task-name
6. Raise a Pull Request
7. Resolve conflicts (if any), then push again
git add .
git commit -m "Resolve merge conflicts"
git push origin feature/your-task-name
📣 Notes
Want to print your doc?
This is not the way.
This is not the way.
Try clicking the ··· in the right corner or using a keyboard shortcut (
CtrlP
) instead.