Begin with the simpler workflow
The previous modules used this path:
feature branch
|
v
Pull Request
|
v
main
This workflow is enough for many teams. It is important to understand it before adding another permanent branch.
Now imagine that several student features must be combined and tested together before the class considers the project stable. The team needs a shared place for integrated work that is not ready for main.
Give each permanent branch one meaning
main = stable version
develop = next version being assembled
Short task branches connect to develop:
feature/add-search ----\
fix/loading-message ----> develop ----> main
docs/setup-guide -------/
develop contains reviewed work planned for the next stable version. main receives that work only when the combined version has been verified.
This is a team convention
Git does not require a branch named develop. Some teams work successfully with only main and short branches. Other teams add develop because their release process needs a separate integration point.
In this course, the class chooses develop to make two states visible:
| Branch | Meaning |
|---|---|
main |
Stable and ready to present or deploy |
develop |
Reviewed changes being prepared together |
The names are useful only when the team follows their meaning consistently.
What does not change
Adding develop does not change the purpose of commits, branches or Pull Requests. A student still works on one short task branch, creates focused commits and asks for review.
Only the normal Pull Request target changes:
Before: feature/add-search -> main
Now: feature/add-search -> develop
What to remember
develop is an integration branch chosen by the team. It receives reviewed task branches while main remains the stable version.