chore: update dev-es branch with main branch

[electrocucaracha]

Apparently, the use of Merge pull request option difficult the rebase process, resulting in cherry-picking changes and the recreation of dev-es branch. One possible solution for keeping a linear project history in the long-running dev-es branch could be the use of Squash and merge option

[netlify]

✅ Deploy Preview for cncfglossary ready!

Name	Link
🔨 Latest commit	c1f3b0c
🔍 Latest deploy log	https://app.netlify.com/sites/cncfglossary/deploys/624b81a093bba80008255927
😎 Deploy Preview	https://deploy-preview-692--cncfglossary.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[raelga]

/approve

[krol3]

LGTM

[seokho-son]

Hi @electrocucaracha :)
The PR LGTM.

I am trying to understand your comment. :)

Apparently, the use of Merge pull request option difficult the rebase process, resulting in cherry-picking changes and the recreation of dev-es branch. One possible solution for keeping a linear project history in the long-running dev-es branch could be the use of Squash and merge option

Do you want Squash and merge for this PR ?

I think these are a way to minimize conflicts.

1. in dev-es branch, focus on content/es/* and try to avoid changing files outside content/es/

• except config.toml for the first round of localization.

1. in main branch, avoid changing files in content/es/

If we can minimize conflicts, we might rebase the branch simply without cherry-picking changes. (I think)

[electrocucaracha]

@seokho-son my main problem was with individual translations (PRs to dev-es branch) which were merged with Merge pull request option, this is resulting in a multiple branches in history.

Let's take the PR #641 as an example. After the Merge pull request option was selected, the history looks like this.

flowchart TB
    subgraph main
        . --> 8933ae6 --> 1a46bee --> 96dcc01 --> ..
    end
    subgraph dev-es
        96dcc01 --> a9e784d --> d78bb81 --> 11fd690 --> ...
    end
    subgraph PR-641
        11fd690 --> c9a080d --> d669f8b --> b391f36
    end

Loading

So what I suggest for this kind of changes is to chose Squash and mergeoption to keep a linear history like this

flowchart TB
    subgraph main
        . --> 8933ae6 --> 1a46bee --> 96dcc01 --> ..
    end
    subgraph dev-es
        96dcc01 --> a9e784d --> d78bb81 --> 11fd690 --> PR-641
    end

Loading

For this PR, I'm not sure if the Merge pull request option or Rebase and merge option are correct, but definitely not the Squash and merge option.

[seokho-son]

@electrocucaracha

oh :)

I strongly agree with using "squash and merge" for individual PRs to dev-es branch.
It is the recommendation from maintainers as well :)

• Branch management: using a proper merge methods

  • For glossary approvers and maintainers

    • In case of general PRs like new term or update term
      • Please use Squash and merge
    • the other cases: approvers need to select an appropriate method
      • Ex: use Create a merge commit when we handle commits in different branches

  • For l10n approvers

    • L10n PRs
      • Please use Squash and merge