Magento 2 & Git

Versioning workshops
(Based on Magento 2.4 and Github)

Trainer: Łukasz Bajsarowicz

Magento Developer for

Working
directory

Staging
Area

Local
repository

Remote
repository

Online server

Local environment

$ git add

$ git commit

$ git push

$ git pull

$ git fetch

$ git reset [FILE]

$ git reset [COMMIT]

Branch Naming

A good naming convention
can improve your work organization.

Most important is to keep
your naming convention consistent a team

Typical naming convention start with issue tracker id...
...and end with short description. Example:

9966-add_mailing_to_client

adding issue tracker id allow you to find in future such task, and thanks to its made much easier to understand the code

Sometimes it is wise to start a branch name with its purpose, example:

It is mainly usefull if there is different gitflow for fixes and features
or if there is different priority for features and refactors

hotfix/9966-repair_mailing_to_client

feature/9966-add_mailing_to_client
refactor/9966-mailing_to_client

DIY #1

Discuss in your team what naming convention
would be the most suitable for your needs

Write it down as a set of rules for your team.

Limitations

They can include slash / for hierarchical (directory) grouping, but no slash-separated component can begin with a dot . or end with the sequence .lock.

git checkout -b .name
git checkout -b Refs/.name

git checkout -b name
git checkout -b Refs/name
git checkout -b Refs.name

Limitations

They cannot have ASCII control characters (i.e. bytes whose values are lower than \040, or \177 DEL), space, tilde ~, caret ^, or colon : anywhere.

git checkout -b part1:part2
git checkout -b ^part

git checkout -b part1.part2

Limitations

They cannot have question-mark ?, asterisk *, or open bracket [ anywhere. See the --refspec-pattern
option below for an exception to this rule.

git checkout -b part1\\part2
git checkout -b *part 
git checkout -b part[

git checkout -b part1\part2

Limitations

They cannot begin or end with a slash / or contain multiple consecutive slashes

git checkout -b part1//part2
git checkout -b /part 
git checkout -b part/

git checkout -b part1/part2

Limitations

They cannot start and end with a dot .

git checkout -b name.
git checkout -b .name

git checkout -b part1.part2

They cannot have two consecutive dots .. anywhere

git checkout -b part1..part2

git checkout -b part1.part2

Limitations

They cannot contain a sequence @{

git checkout -b name@{

git checkout -b name{@
git checkout -b @a{

git checkout -b @

git checkout -b @at

They cannot be the single character @

Single branch
for multiple tasks

TKT-82

TKT-83

InPost integration

DPD Integration

TKT-88

Shipping methods integration

the clearest solution is to create a new issue,
where you explain why all these issues
had to be on one branch.

Conflict Resolution

Sometimes git has no idea how to
connect code in different branches

Feature

Main

Usually, when you work on new features,
you create a new branch from the main branch.

When your work is done, you merge it back to the main branch.

Feature

Main

Hotfix

However, if some other changes appear in the main branch, merging may not be possible.

Such a situation we call a
"conflict"

<?php

echo "Not Implemented!";

hello.php

<?php

$customer = $block->getCustomer();
echo __("Hello %1", $customer->getFirsname());

hello.php

<?php

echo "Hi {$block->getCustomer()->getFirstName()}";

hello.php

Case 1: The same line file was changed in different branches

<?php

echo "Not Implemented!";

hello.php

stub.php

hello.php

Case 2: The file was renamed or deleted on one branch
and edited on the other branch

<?php

echo "Not Implemented!";

<?php
 
<<<<<<< HEAD
echo 'Hello ALICE!!!';
=======
echo 'Hello BOB!!!';
>>>>>>> dev

<?php
 
echo 'Hello ALICE && BOB!!!';

> > >

You may edit code manually as shown above

add conflicted files with command:

$> git add .
$> git commit

Resolving Conflict in PhpStorm

on your application toolbar choose VCS -> Git -> Resolve Conflicts...

now you can choose your preferred version or edit it manually

after resolving you can commit by choosing on your toolbar

VCS -> Git -> Commit File...

Resolving Conflict in Github

Click the "Resolve conflicts" button on the Pull Request page

now you can edit each conflict. jumping between them using "Prev" and "Next" buttons

DIY #1

Work in a group. Make one fork of Magento 2

Each of You ought to clone that new Repository to your local enviroment

Decide which file all of You are going to refactor. For example:

Magento\Catalog\Model\Indexer\Product\Eav\AbstractAction
Spend 20-30 minutes on refactoring separetly.

Each of You should merge her/his changes into one branch

What was the easiest way to solve the conflicts for You?

Main

Case 3: Changes were merged smoothly (without conflicts)
but the application is broken.

PrintString.php

index.php

<?php #file PrintString.php
 
class PrintString 
{
    public function print($string)
    {
    	echo $string;
    }
}

It may happen when changes in two different files from
two different branches do not work properly together

For example, let's assume that on our main branch we got 2 files like:

<?php #file index.php

echo "Hello World";

Developer A was asked to refactor PrintString.php

<?php #file PrintString.php
 
class PrintString 
{
	private string $toPrint;
    
    public function __construct($toPrint) {
    	$this->toPrint = $toPrint;
    }
    
    public function print()
    {
    	echo $this->toPrint;
    }
}

<?php #file index.php

echo "Hello World";

application works correctly on first_branch

Developer B used PrintString in index.php, at the same time

<?php #file PrintString.php
 
class PrintString 
{
    public function print($string)
    {
    	echo $string;
    }
}

<?php #file index.php

include 'path/to/PrintString.php';
 
 
$printer = new PrintString();
$printer->print("Hello World");

application is working on second_branch

After merging first_branch and second_branch code looks like that

<?php #file PrintString.php
 
class PrintString 
{
	private string $toPrint;
    
    public function __construct($toPrint) {
    	$this->toPrint = $toPrint;
    }
    
    public function print()
    {
    	echo $this->toPrint;
    }
}

<?php #file index.php

include 'path/to/PrintString.php';
 
 
$printer = new PrintString();
$printer->print("Hello World");

and git did not raised any conflicts, but application throws Fatal Error

Bisect Investigation

Use binary search to find the commit

that introduced a bug

Step 1

Tell Git where application does not work correctly

git bisect start

Step 2

Point out the latest commit that worked

git bisect good <<hash >>

Step 3

git bisect bad <<hash >>

At this point, bisect will automatically checkout the commit in the middle

Test application and tell Git whether it works or not

Step 4

git bisect bad <<hash>>

git bisect good <<hash>>

after that bisect will lead you to the new commit, repeat all the steps until bisect will find the first commit with the bug.

DIY #1

Clone the project:

https://github.com/adeptofvoltron/M2Coach

checkout the branch: bisect_task
run phpunit: phpunit app/code
find the first commit that is not passing phpunit tests.

Use git bisect for that

Something went wrong?

To stop bisect at any point, simply type command

git bisect reset

You can also automate tests with a custom script

git bisect run ./myScript

Git Revert

Enables you to rollback changes

without changing commit history

-14

+14

-5

Change X

Revert X

-14

Change X

Reset

Doesn’t change the project history, which makes it a “safe” operation for commits that have already been published to a shared repository
Allow to revert any arbitrary chosen commit

Advantages of Reverting

The easiest way to revert commit by hash

git revert <<commit hash>>

Commit hash might be found by command

git log

Check undo latest changes by reset HEAD state
where n stands for number of commits to revert

git reset HEAD~n

You can also revert latest pull request from Github page

Go to your merged pull request and click revert button

It will create pull request with all changes reverted

Github Actions

Automatyczne sprawdzanie jakości kodu,
eliminowanie błędów krytycznych
czy problemów z kompilacją.

name: Magento CI    # yamllint disable rule:line-length
on: pull_request    # yamllint disable-line rule:truthy
defaults:
  run:
    working-directory: webroot

jobs:
  build:
    name: Build Check
    runs-on: ubuntu-latest
    container:
      image: docker.io/davidalger/php:7.3
      env:
        MAGE_MODE: production

Środowisko uruchomieniowe

    steps:
      - name: Checkout repository
        uses: actions/checkout@v1
        with:
          fetch-depth: 1

Pobranie zawartości repozytorium


      - name: Initialize config
        id: config
        run: |
          echo "::set-output name=composer-cache-dir::$(composer config cache-files-dir)"
      - name: Validate composer files
        run: composer validate --no-check-all --no-check-publish

      - name: Retrieve composer cache
        uses: actions/cache@v2
        with:
          path: ${{ steps.config.outputs.composer-cache-dir }}
          key: ${{ runner.os }}-composer-v1-${{ hashFiles('**/composer.lock') }}
          restore-keys: ${{ runner.os }}-composer-v1-${{ hashFiles('**/composer.lock') }}

      - run: composer global require hirak/prestissimo
      - run: composer install --prefer-dist --no-interaction --no-dev --optimize-autoloader
        env: {COMPOSER_AUTH: "${{ secrets.COMPOSER_AUTH }}"}

Instalacja zależności Composer


      - run: php -d memory_limit=768M bin/magento setup:di:compile
      - run: php -d memory_limit=768M bin/magento setup:static-content:deploy -j $(nproc)

Kompilowanie DI & frontendu


      - uses: mediotype/phpcs-action@v2
        with:
          # This is required for magento-coding-standards to function
          enable_warnings: true
          only_changed_files: true
          phpcs_bin_path: ${{ github.workspace }}
              ${{ steps.config.outputs.working-directory }}/vendor/bin/phpcs 
              --standard=Magento2

Magento 2 & Git

Trainer: Łukasz Bajsarowicz

Branch Naming

DIY #1

Limitations

Limitations

Limitations

Limitations

Limitations

Limitations

Single branch
for multiple tasks

Conflict Resolution

DIY #1

Bisect Investigation

Step 1

Step 2

Step 3

Step 4

DIY #1

Git Revert

Github Actions

Magento 2 and Git

Magento 2 and Git

Łukasz Bajsarowicz

Magento 2 & Git

Trainer: Łukasz Bajsarowicz

Branch Naming

DIY #1

Limitations

Limitations

Limitations

Limitations

Limitations

Limitations

Single branch for multiple tasks

Conflict Resolution

DIY #1

Bisect Investigation

Step 1

Step 2

Step 3

Step 4

DIY #1

Git Revert

Github Actions

Magento 2 and Git

More from Łukasz Bajsarowicz

Single branch
for multiple tasks