Collaboration with GitHub

Remote repositories (remotes)

A remote is a Git repository hosted on a server (GitHub, GitLab, Bitbucket). It enables collaboration by synchronizing code between developers.

# View configured remotes
git remote -v

# Add a remote
git remote add origin https://github.com/user/projet.git

# Change a remote's URL
git remote set-url origin git@github.com:user/projet.git

Push — send code

# Push the current branch
git push origin main

# First push of a new branch (with tracking)
git push -u origin feature/login
# Afterwards, a simple git push is enough
git push

# Push all branches
git push --all origin

# Push tags
git push --tags

Pull — retrieve code

# Fetch and merge changes
git pull origin main

# Equivalent to:
git fetch origin
git merge origin/main

# Pull with rebase (cleaner history)
git pull --rebase origin main

Fetch — retrieve without merging

# Fetch remote information without modifying your files
git fetch origin

# View remote branches
git branch -r

# View differences with the remote
git diff main origin/main

# Switch to a remote branch
git checkout -b feature/api origin/feature/api

Pull Requests (PR)

A Pull Request is a request to merge one branch into another, with a code review process.

Pull Request workflow

1. Create a branch
   git checkout -b feature/cart

2. Develop and commit
   git add .
   git commit -m "Add the shopping cart"

3. Push the branch
   git push -u origin feature/cart

4. Create the PR on GitHub
   → Clear title and detailed description

5. Code review
   → Colleagues comment and approve

6. Merge the PR
   → Squash, merge, or rebase

7. Delete the branch
   git branch -d feature/cart

Writing a good Pull Request

## Description
Addition of the shopping cart system allowing users
to add products and place orders.

## Changes
- Creation of the CartComponent
- Addition of CartService with localStorage management
- Integration with the /orders API

## How to test
1. Log in with a user account
2. Add a product to the cart
3. Verify that the counter updates
4. Complete the order

## Screenshots
[If relevant, add screenshots]

Merge strategies

Working as a team

Fork and open source contribution

# 1. Fork the project on GitHub (via the web interface)

# 2. Clone your fork
git clone git@github.com:your-user/projet.git
cd projet

# 3. Add the original repository as a remote
git remote add upstream https://github.com/original/projet.git

# 4. Create a branch for your contribution
git checkout -b fix/typo-readme

# 5. Make your changes and commit
git add .
git commit -m "Fix typos in the README"

# 6. Push to your fork
git push origin fix/typo-readme

# 7. Create a PR from your fork to the original repository

# Keep your fork up to date
git fetch upstream
git checkout main
git merge upstream/main
git push origin main

Code review — best practices

As a reviewer:

• Be constructive and kind
• Ask questions rather than imposing
• Focus on logic, not style (the linter handles that)
• Approve when it's ready, don't block on minor details

As an author:

• Keep PRs small and focused (< 400 lines ideally)
• Respond to all comments
• Don't take feedback personally

Tags and releases

Tags mark important versions in the history.

# Create an annotated tag
git tag -a v1.0.0 -m "First stable release"

# Create a tag on an older commit
git tag -a v0.9.0 abc1234 -m "Beta version"

# List tags
git tag
git tag -l "v1.*"                # Filter

# Push tags
git push origin v1.0.0
git push --tags                  # All tags

# Delete a tag
git tag -d v1.0.0                # Local
git push origin --delete v1.0.0  # Remote

Semantic Versioning (SemVer)

v MAJOR . MINOR . PATCH
  |       |       └── Bug fixes (backward compatible)
  |       └── New features (backward compatible)
  └── Breaking changes (not backward compatible)

Examples:
v1.0.0 → v1.0.1  # Bug fix
v1.0.1 → v1.1.0  # New feature
v1.1.0 → v2.0.0  # Breaking change

GitHub Actions — introduction to CI/CD

GitHub Actions allows you to automate tasks on every push or PR.

# .github/workflows/ci.yml
name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install dependencies
        run: npm ci

      - name: Run tests
        run: npm test

      - name: Run the linter
        run: npm run lint

Collaboration best practices

1. Always go through PRs — never push directly to main
2. Protect the main branch — require at least one approval
3. Sync regularly with git pull --rebase
4. Communicate in PRs — use descriptions and comments
5. Use conventions for branch names and commit messages
6. Automate with CI/CD — tests, lint, build on every PR
7. Tag your releases with semantic versioning