Git and GitHub Foundations: From Project Folders to Team Collaboration

Module 7: Add an Integration Branch

Course progress0%
Course content

Module 1

Before Git: The Copied Folder ProblemGit and GitHub Are Different

Module 2

Start a Local RepositoryFrom a Change to a Commit

Module 3

Read Changes and Write Clear CommitsKeep Unnecessary and Private Files Out

Module 4

Publish a Local Repository to GitHubClone a Repository and Pull New Work

Module 5

One Task, One Short BranchOpen and Update a Pull Request

Module 6

Review, Merge and Clean UpResolve One Conflict and Repeat the Workflow

Module 7

Why Add a develop Branch?Work from develop to a Stable main
45 min

Work from develop to a Stable main

Follow the class workflow from one task to the next stable version

By the end of this lesson

  • Create task branches from updated develop
  • Move verified integrated work from develop to main

Create develop once

The repository owner creates develop from the current stable main:

git switch main
git pull
git switch -c develop
git push -u origin develop

After this initial setup, both permanent branches exist on GitHub. The team does not recreate develop for every task.

Begin each task from develop

Yassine receives an issue to add search. He first updates the integration branch:

git switch develop
git pull
git switch -c feature/add-search

He implements and verifies the change, then records and publishes it:

git add src/search.js
git commit -m "Add resource search"
git push -u origin feature/add-search

The Pull Request uses:

base branch:    develop
compare branch: feature/add-search

After review and successful checks, the team merges the Pull Request into develop and removes the completed feature branch.

Integrate several reviewed tasks

Omar can work separately on fix/loading-message, also created from an updated develop. Its Pull Request targets develop as well.

feature/add-search ----\
                       > develop
fix/loading-message ---/

The team verifies the combined behavior on develop. A feature can work alone but still conflict in behavior with another feature, so integration needs its own verification.

Move the verified version to main

When the planned work is integrated and stable, the team opens one Pull Request:

develop -> main

This Pull Request describes the complete version, includes the relevant checks and receives final review. After the merge, main represents the new stable version.

Do not create another personal branch to copy files manually from develop to main. The Pull Request preserves the history and makes the release decision visible.

The complete class workflow

1. Read the issue
2. Update develop
3. Create feature/, fix/ or docs/ from develop
4. Make one focused change
5. Review status and diff
6. Commit and push the task branch
7. Open a Pull Request toward develop
8. Review, correct and merge
9. Verify all integrated changes on develop
10. Open a Pull Request from develop toward main
11. Run final checks and review
12. Merge the stable version into main

Rules that keep the workflow clear

  • Do not develop directly on main.
  • Do not develop directly on develop.
  • Create task branches from an updated develop.
  • Send ordinary task Pull Requests to develop.
  • Send develop to main only when the combined version is stable.
  • Delete short task branches after merging them.
  • Keep main and develop; they are permanent team branches.

This course does not add release/ or hotfix/ branches. The class workflow needs only two permanent branches and short task branches.

What to remember

Task branches begin from develop and return to develop through review. Verified integrated work moves from develop to main through a separate Pull Request.

Lesson complete?

Your progress is saved on this device.