What can you tell about the workflow process in…

The main workflow in GitLab revolves around Merge Requests (MR).

Creating a branch: The developer creates a new branch from the main branch (e.g., main or develop) for their task/feature.
```
# Create a new branch based on main
git checkout -b feature/add-new-button main
```

Development and commits: Changes are made in the new branch. Each logical set of changes is committed.

# Add changed files to Stage Area
git add .
# Commit with a description
git commit -m "feat: Add new submit button"

Push branch: The developed branch is pushed to the remote GitLab repository.
```
# Push the new branch to GitLab
git push origin feature/add-new-button
```
Creating a Merge Request (MR): An MR is created in GitLab from the new branch to the target branch (e.g., main). In the MR, you specify:
- Target branch.
- Description of changes.
- Assigned reviewers and executor.
- Related issues/tickets (if any).
CI/CD pipeline: Immediately after creating or updating the MR, the CI/CD pipeline defined in .gitlab-ci.yml is automatically triggered. It may include:
- Building the code.
- Running tests (unit, integration, static analysis).
- Code quality checks.
- Building Docker images.
- Deploying to a test environment (Review App).
Code Review: Assigned reviewers review the code in the MR, leave comments, suggest improvements, or point out errors. The discussion takes place directly in the MR interface.
Updating and iterations: The developer makes changes based on reviewers' comments, pushes new commits to their branch. The pipeline runs again.
Approving the MR: After successful pipeline completion and approval from all reviewers, the MR is ready to be merged.
Merge: The executor or reviewer performs the merge. GitLab allows choosing a merge strategy:
- Merge commit (default)
- Squash and merge (all commits are squashed into one)
- Fast-forward merge
Often, a CI/CD pipeline for deploying to the Prod environment is also configured at this stage.
Deleting the branch: After a successful merge, the feature branch is usually deleted to keep the repository clean. GitLab offers an option for automatic branch deletion after merging.

Important aspects of the GitLab workflow:

Single Application: GitLab combines VCS, CI/CD, Registry, Issue Tracking, etc., in one application, ensuring seamless transition between development phases.
Issues: Used for tracking tasks, bugs, suggestions. They can be linked to MR.
Labels and Milestones: Help organize and prioritize work.
Protected Branches: Settings to prevent direct pushes to important branches (main, develop) and requirements for MR (approvals, successful pipeline).
GitLab Flow: Often used as a basis, combining strategies like Branching Model (e.g., Gitflow or Trunk-Based Development) with Merge Requests and CI/CD capabilities.

Example of simple .gitlab-ci.yml stages:

# Define pipeline stages
stages:
  - build
  - test
  - deploy

# Build job
build-job:
  stage: build
  script:
    - echo "Building the project..."
    - # Build commands (e.g., make build or npm install)
  tags:
    - docker # Example of using a runner with the docker tag

# Test job
test-job:
  stage: test
  script:
    - echo "Running tests..."
    - # Test commands (e.g., make test or npm test)
  only:
    - merge_requests # Run only on MR
  tags:
    - kubernetes # Example of using a runner with the kubernetes tag

# Deploy to staging (example)
deploy-staging:
  stage: deploy
  script:
    - echo "Deploying to staging..."
    - # Deployment commands (e.g., kubectl apply -f deploy.yaml)
  environment:
    name: staging
    url: https://staging.example.com # Environment URL
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"' # Deploy to staging on merge into main

What can you tell about the workflow process in GitLab?