github·Jul 15, 2026·3 min readCurated summary

GitHub for Beginners: Your roadmap to mastering the GitHub essentials

GitHub for Beginners presents a step-by-step roadmap from understanding version control to collaborating on projects through GitHub. It explains the essential Git concepts, account setup, repository creation, Markdown, and the GitHub flow. The central message is that beginners can master GitHub by learning a small set of practical tools and following a repeatable workflow. ## Understanding Version Control and Git - Version control tracks file changes over time, allowing developers to see what changed, when, and why. - Git replaces confusing file copies such as `final_v2` or `FINAL_actually` with a complete change history. - Git uses three main areas: - **Working directory:** where files are edited - **Staging area:** where changes are prepared for saving - **Local repository:** where committed history is stored - Core commands include: - `git status` to inspect changes - `git add` to stage changes - `git commit` to save a snapshot - “Pushing” code means uploading local commits to GitHub. ## Securing and Personalizing a GitHub Account - A GitHub account acts as a developer identity and should be protected with two-factor authentication. - 2FA can be enabled under **Settings → Password and authentication**. - Recovery codes should be downloaded and stored securely, such as in a password manager. - A profile README can serve as a public portfolio describing skills, projects, and interests. - The README appears on the profile when stored in a public repository named after the user’s GitHub username. ## Essential Git Commands - Beginners do not need to memorize all of Git; a small group of commands supports most daily workflows. - Important commands include: - `git config --global user.name "..."` to identify commits - `git init` to create a repository - `git clone <url>` to copy a remote repository locally - `git add .` to stage changes - `git commit -m "message"` to save changes - `git switch -c <branch>` to create and enter a branch - `git push` to upload commits - `git pull` to retrieve and merge remote changes - `git merge <branch>` to integrate another branch ## Creating a First Repository - A repository is a project’s home base: it stores files, tracks history, and supports collaboration. - To create one: - Select **New** from the GitHub dashboard - Choose a name - Set it as public or private - Optionally initialize it with a README - A `.gitignore` file excludes generated files, dependencies, system files, and temporary build output from version control. - A license communicates how others may use or share the project. ## Writing with Markdown - Markdown is a lightweight text-formatting language used throughout GitHub. - It powers READMEs, issues, pull requests, and comments. - Simple symbols and optional HTML tags can create readable documentation without complex tools. ## Following the GitHub Flow - GitHub flow provides a repeatable process for contributing safely: 1. Clone the repository 2. Create a branch 3. Make changes 4. Commit the work 5. Push the branch to GitHub 6. Open a pull request - Pull requests let colleagues review changes before they are merged. - The workflow applies to many shared projects, including repositories containing reusable AI prompts or other collaborative resources. Start with the basic Git commands, protect and document your GitHub profile, then practice the branch-and-pull-request workflow on a small repository. These fundamentals provide a practical foundation for contributing to larger team projects and open source.

Read original(opens in new tab)

GitOpen SourceGithubMarkdown+3

gitlab·Jun 29, 2026·2 min readCurated summary

What's new in Git 2.55.0?

Git 2.55.0 introduces improvements focused on stacked-branch workflows, large repositories, multi-remote setups, and clearer history visualization. Highlights include `git history fixup`, a built-in Linux filesystem monitor, remote-group pushing, and a configurable width limit for `git log --graph`. The release also continues Git’s Rust adoption and improves performance for partial clones. ## `git history fixup` - Adds `git history fixup <commit-id>`. - Takes staged changes and amends them directly into an existing commit. - Avoids creating a separate fixup commit and running an interactive autosquash rebase. - Automatically updates other local branches containing the amended commit, making it useful for stacked branches. ## Built-in fsmonitor support for Linux - Git’s filesystem monitor speeds up `git status` by tracking changed files instead of scanning the entire worktree. - Git 2.55 extends the built-in `core.fsmonitor=true` daemon from Windows and macOS to GNU/Linux. - Linux support uses `inotify`, avoiding the elevated privileges required by `fanotify`. - The daemon needs a watcher for every repository directory, so large repositories may require increasing `fs.inotify.max_user_watches`. ## Pushing to remote groups - Remote groups were previously supported by `git fetch` but not `git push`. - Configure a group, for example: ```bash git config set remotes.forks "origin upstream" ``` - Push to every remote in the group with: ```bash git push forks main ``` - Each remote is handled independently and follows its own `remote.<name>.push` mappings and mirror settings. ## Limiting `git log --graph` width - `git log --graph` can become difficult to read in repositories with many parallel branches. - Git 2.55 adds a way to limit the graph’s lane width, preventing the ASCII history from expanding indefinitely. - This is particularly useful for large projects such as Git itself, where the graph can become many lanes wide after only a few commits. ## Rust adoption and partial-clone performance - The release continues the gradual evolution of Rust within Git’s codebase. - `git grep` and `git cherry` receive performance improvements when operating in partial clones. Git 2.55 is especially useful for developers working in large monorepos or stacked-branch workflows. Enabling the Linux fsmonitor, using `git history fixup`, and configuring remote groups can provide immediate productivity benefits, while graph-width limits make complex histories easier to inspect.

Read original(opens in new tab)

GitRustLinuxVersion Control+2

github·Jun 16, 2026·2 min readCurated summary

What are git worktrees, and why should I use them?

Git worktrees let developers check out multiple branches simultaneously in separate directories, avoiding the stash-and-switch cycle. They preserve editor state, reduce context-switching friction, and make parallel work—especially AI-assisted development—much easier. Their main drawbacks are dependency duplication, folder cleanup, and restrictions on checking out the same branch twice. ## Switching Contexts with Branches and Stashing - Traditional urgent-work flow often requires: - Stashing unfinished changes. - Checking out and updating `main`. - Creating a hotfix branch. - Committing, pushing, and merging the fix. - Returning to the original branch and restoring the stash. - This process creates mental overhead and may involve reloading files, reinstalling dependencies, or resolving stash conflicts. - Some developers compensate with multiple repository clones or increasingly complex stash commands. ## Working in Parallel with Worktrees - A worktree creates another working directory connected to the same Git repository: ```bash git worktree add ../hotfix-workspace -b hotfix-bug main ``` - The original feature branch and editor remain untouched while the hotfix is developed in a separate folder. - After merging, the temporary worktree can be removed: ```bash git worktree remove ../hotfix-workspace ``` - Worktrees eliminate stash conflicts and support truly parallel development. - Tools such as VS Code provide built-in worktree support. ## Why Worktrees Are More Popular Now - Worktrees have existed since 2015 but were historically overlooked because Git GUIs offered limited support. - Developers increasingly run multiple tasks, coding sessions, reviews, and AI agents simultaneously. - Modern tools, including the GitHub Copilot app, use worktrees as a default way to isolate parallel sessions. ## Limitations to Consider - **Dependency bloat:** Each worktree may contain its own `node_modules`, Python packages, or other dependencies. - **Folder management:** Temporary worktrees must be deleted to prevent clutter. - **`.gitignore` concerns:** Worktrees created inside the repository may need to be ignored; placing them outside the repository avoids this issue. - **One-branch restriction:** Git prevents the same branch from being checked out in multiple worktrees simultaneously. ## Worktrees in the GitHub Copilot App - New Copilot sessions can be created in a new worktree by default. - The app displays the generated worktree name, location, associated project, and changes. - Worktree management is integrated into the session workflow. Worktrees are especially useful for parallel development and AI-assisted workflows, but they are not mandatory. Developers can use worktrees, traditional branching and stashing, or a combination depending on their workflow and resource constraints.

Read original(opens in new tab)

GitGithub CopilotVersion ControlAi Assisted Development+1

gitlab·Jun 10, 2026·3 min readCurated summary

GitLab: Built for the agentic engineering era

GitLab argues that AI coding only becomes truly “agentic engineering” when paired with infrastructure built for machine-scale concurrency, lifecycle context, and enterprise governance. At GitLab Transcend, it announced new source control, context, security, orchestration, and purchasing capabilities designed to let agents work faster without sacrificing control. The overall goal is to convert rapid AI-generated development into reliable business value rather than unmanaged complexity. ## The challenge: speed without control - Research across more than 1,500 developers and technology leaders found: - 91% of organizations use at least two AI coding tools. - 54% use three or more. - Some customer codebases are growing by as much as five times per year. - Fragmented development lifecycles create several problems: - Human-scale source control systems struggle with thousands of concurrent agents. - Agents lack context about dependencies, deployments, and production behavior. - Rapidly changing code is difficult to govern. - Fixed contracts make AI adoption difficult to forecast. - 73% of respondents worry about maintaining AI-generated code, while only 21% see productivity improvements across the full SDLC. ## GitLab’s agentic infrastructure model GitLab presents its platform as four coordinated systems: - **Motor system:** Source control, pipelines, and deployments that execute work. - **Nervous system:** Context that helps agents and humans make informed decisions. - **Immune system:** Security, governance, identity, policy, audit, and approvals. - **Orchestration system:** GitLab Duo Agent Platform, which coordinates work across the lifecycle. The company says these systems operate consistently whether work is performed by a developer or an agent. ## Next-generation source control for agent concurrency Git’s traditional workflow creates bottlenecks when every developer runs hundreds of agents: - Agents repeatedly clone repositories even when they need only one file. - Thousands of simultaneous sessions can overwhelm a human-oriented backend. - Shared accounts and branches make it difficult to isolate, audit, or discard agent work. GitLab’s next-generation SCM, currently in private beta, retains Git protocol compatibility while redesigning the backend and interfaces for agents. It is intended to support thousands of parallel agents working safely across repositories. Early internal tests reported: - Up to 2× fewer tokens - Up to 50× faster wall-clock execution - Up to 1,000× less network traffic ## GitLab Orbit: lifecycle context for agents Agents often understand the code they modify but not the broader software lifecycle, causing wasted iterations, hallucinations, and incorrect work across large or multiple repositories. GitLab Orbit, in public beta, provides a continuously updated context graph connecting: - Code - Work items - Pipelines - Deployments - Production signals This gives agents and engineers a shared source of truth. GitLab reports that Orbit-grounded agents achieved up to 11× faster responses, 4.5× better cost efficiency, and 45× fewer hallucinations in early testing. Compare the Market’s testing on 79 merge requests found that graph-grounded agents placed inline review comments correctly 69.6% of the time, compared with 57.7% for a conventional RAG approach. ## Governance, orchestration, and purchasing GitLab also announced: - **Agents for security and governance for agents**, covering identity, policy, auditing, and approval of agent actions, in private beta. - **GitLab Duo Agent Platform**, generally available since January, allowing agents to pick up issues, review code, and fix pipelines. - **GitLab Flex**, a purchasing model intended to accommodate the unpredictable pace of AI adoption. - A Transcend hackathon inviting developers to build agents and workflows using Orbit. GitLab’s practical recommendation is not to slow down AI-assisted development, but to pair it with dedicated infrastructure for concurrency, full-lifecycle context, and enforceable governance.

Read original(opens in new tab)

GitAI AgentsCI/CDGitlab+4

github·Jun 8, 2026·2 min readCurated summary

GitHub for Beginners: Answers to some common questions

The post is a beginner-friendly guide to common GitHub questions, focusing on SSH authentication and Personal Access Tokens (PATs). It explains how to securely connect a computer to GitHub, create credentials for command-line and API access, and limit those credentials appropriately. The provided excerpt ends just as it introduces merging versus rebasing. ## SSH Keys and GitHub Authentication - An SSH key consists of: - A private key that stays on the computer and must never be shared. - A public key uploaded to GitHub. - Git uses the matching key pair to verify identity when pushing and pulling code. - To create an Ed25519 key pair, run `ssh-keygen` with the email associated with the GitHub account. - Users can accept the default file location and protect the key with a passphrase. - `ssh-agent` securely stores the key so the passphrase does not need to be entered repeatedly. - The public key can be copied with `cat ~/.ssh/id_ed25519.pub` and added through **Settings → SSH and GPG keys → New SSH key**. - A descriptive title, such as “work-laptop,” helps identify the device later. ## Personal Access Tokens - A PAT is a GitHub-managed credential for authenticating command-line tools and API requests. - Tokens can be revoked and configured with limited permissions. - GitHub offers: - **Fine-grained tokens**, which can be restricted to specific repositories and individual read or write permissions. - **Classic tokens**, which use broader predefined scopes. - When creating a fine-grained token, users choose: - A name and description. - An expiration date. - Repository access. - Specific permissions and whether each is read-only or read/write. - Classic tokens are created through **Developer settings → Personal access tokens → Tokens (classic)** and use scopes to define access. - GitHub displays a token only once, so it should be copied immediately and stored securely, such as in a password manager. - A PAT can be supplied instead of a password when Git prompts for credentials in a terminal. ## Merging and Rebasing - The excerpt begins introducing the difference between merging and rebasing and how to resolve merge-related problems. - The supplied content ends before that explanation is provided. Use SSH keys for secure Git operations from a trusted device, and use narrowly scoped, expiring PATs when tools or APIs require token-based authentication. Never share private keys or tokens, and store credentials securely.

Read original(opens in new tab)

GitGithubVersion ControlSsh+2

figma·May 28, 2026·2 min readCurated summary

Figma Make, Now on Your Local Code | Figma Blog

Figma is bringing Make beyond prototyping by connecting it directly to local production codebases. Designers can visually edit interfaces, use annotations and prompts for more complex behavior, and manage changes through Git workflows without leaving Figma. The broader goal is to make design and code a continuous, collaborative workflow rather than separate tools. ## Visual Editing in Production Code - Make connects to a local codebase and translates visual changes into code. - Users can select interface elements and modify: - Layouts - Colors - Fonts - Sizing - Other visual properties - Annotations let users describe interactions, animations, and other changes that go beyond simple property edits. - The feature is currently best suited to designers who already have access to their organization’s codebase. ## Git-Based Branching and Shipping - Make supports standard development workflows, including: - Creating branches - Reverting commits - Reviewing commit history - Creating pull requests - Changes remain in local commits until the team intentionally opens a pull request. - Engineering teams can review Make-generated changes like any other production contribution. ## Collaboration Between Design and Code - Local code changes can be shared as files and links with teammates who have access to the relevant branch. - Teammates can inspect changes, build on them, and compare versions through commit history. - Screens, pages, and components can be copied from Make into Figma Design as editable layers. - Changes made in Figma can be detected and brought back into Make, creating a round-trip workflow between the design canvas and codebase. ## Beta Availability - Direct editing, annotations, chat, and pull-request creation enter limited beta on May 28, 2026. - Beta access is limited to Figma’s Mac desktop beta app and requires joining a waitlist. - The features will not consume credits during beta; pricing for AI credits will be announced later. - Figma plans to expand availability to other platforms. Figma’s recommendation is effectively to use whichever environment best fits the current task—design canvas, code-based prototyping, or production code—while maintaining a shared workflow between them.

Read original(opens in new tab)

GitAI AgentsCollaborationFigma Make+3

github·May 25, 2026·3 min readCurated summary

GitHub for Beginners: Getting started with Git and GitHub in VS Code

VS Code provides an integrated way to manage Git and GitHub without leaving the editor, reducing context switching and simplifying common version-control tasks. The post walks beginners through initializing a repository, staging and committing files, creating branches, tracking edits, and reviewing diffs. It emphasizes that Git manages source code locally, while GitHub hosts repository copies remotely. ## Git, GitHub, and VS Code - **Git** is the program used to manage source code and version history. - **GitHub** hosts copies of Git repositories. - **VS Code** uses Git to provide a graphical workflow for managing code and synchronizing it with GitHub. - Following along requires installing both Git and VS Code. ## Initializing a Repository - Open a project folder in VS Code through the **Explorer** panel. - Select **Source Control** and click **Initialize Repository**. - VS Code creates a local Git repository, initially using the `main` branch. - The branch can be renamed through the Command Palette: - macOS: `Shift-Command-P` - Windows/Linux: `Ctrl-Shift-P` - Choose **Git: Rename Branch**. ## Staging and Committing Files - Newly detected files appear with a **U**, meaning “untracked.” - Click the plus sign beside a file—or beside **CHANGES** to stage everything. - Staged files receive an **A** indicator. - Enter a commit message in the Source Control panel and click **Commit**. - Git commits changes locally; they are not uploaded to GitHub until they are pushed. ## Creating and Switching Branches - Use the Command Palette and select **Git: Create Branch…**. - Enter a branch name such as `new-features`. - VS Code creates the branch and automatically switches to it. - The active branch is displayed in the bottom-left status bar. - Branches allow developers to work on features separately from `main`. ## Understanding Change Indicators VS Code displays edits directly in the editor gutter: - A green line marks newly added code. - A blue patterned line marks modified existing code. - A red arrow marks deleted code. - Modified files appear under **CHANGES** in the Source Control panel. - Hovering over a file provides controls to open it, discard changes, or stage it. - The **CHANGES** header also provides actions for reviewing, discarding, or staging changes across all files. ## Reviewing Diffs - Clicking a changed file opens a side-by-side comparison of the current and previous versions. - The diff menu’s **Inline View** option displays changes in a single editor pane. - Inline diffs can also be edited directly, allowing corrections before staging or committing. VS Code’s Source Control integration gives beginners a practical, visual workflow for Git. A typical process is to initialize a folder, create a working branch, inspect edits, stage selected files, commit them with a descriptive message, and then push the commits to GitHub.

Read original(opens in new tab)

GitGithubVersion ControlVisual Studio Code+3

gitlab·May 21, 2026·2 min readCurated summary

Transform MRs from manual tasks to an automated workflow

GitLab 19.0 expands Developer Flow from generating merge requests to managing much of their entire lifecycle. Its AI agent can respond to reviews, investigate codebases, resolve conflicts, and split oversized MRs, while automation handles rebasing and merging. The result is less manual effort between opening and merging an MR, with developers supervising rather than executing every step. ## Developer Flow Across the MR Lifecycle - Can be triggered from: - An issue via **Generate MR** - An issue or MR assigned to the **Duo Developer** service account - Any issue or MR discussion using the new **@mention** trigger - Continues working on the same MR instead of creating separate changes to reconcile. - Handles: - Multiple rounds of reviewer feedback - Merge conflicts on long-running branches - Codebase research and technical evaluations - Oversized MR splitting - New feature implementation - Uses a single agentic loop with tools such as `read`, `grep`, file editing, and command execution. - Reads `AGENTS.md` for project conventions and operational guidance. - Uses `agent-config.yml` to configure dependencies, tooling, tests, and pre-commit hooks. These capabilities are available through GitLab Duo Agent Platform on Premium and Ultimate plans. ## Autonomous Merge Conflict Resolution - The beta **Resolve with Duo** button is available on the MR conflict page and merge checks widget. - The agent: - Reviews the MR’s intent and both branches - Selects a resolution strategy - Edits conflicting files - Commits and pushes the resolution - It leaves a summary comment explaining the conflict and resolution path. - If it cannot resolve the conflict safely, it reports that rather than guessing. ## One-Click Rebase and Merge - The beta feature combines rebasing and merging into one action. - It is designed for teams using semi-linear or fast-forward merge methods. - It is available on Free, Premium, and Ultimate tiers. ## Reducing Manual MR Work GitLab distinguishes between AI-driven judgment and mechanical automation: - AI handles code changes, reviewer feedback, and conflict resolution. - Automation handles tasks such as rebasing before merge. - Together, these features reduce the time developers spend on repetitive MR maintenance while preserving human oversight for steering, reviewing, and final decisions. Developers can try Developer Flow through a GitLab Duo Agent Platform trial. Existing Premium and Ultimate users with the platform can use it on merge requests, while older GitLab versions may require manually configuring the mention trigger.

Read original(opens in new tab)

GitAI AgentsCI/CDGitlab+4

github·May 15, 2026·3 min readCurated summary

Raising the bar: Quality, shared responsibility, and the future of GitHub&#8217;s bug bounty program

GitHub is reaffirming its commitment to external security researchers while tightening bug bounty submission standards. Rising report volumes—partly driven by AI and other tools—have increased both valuable findings and unvalidated noise. GitHub’s central message is that tools are welcome, but researchers remain responsible for validating vulnerabilities, demonstrating impact, and understanding the platform’s shared security boundaries. ## Rising Submission Volume - New tools, including AI, have lowered the barrier to security research and expanded the number of people examining attack surfaces. - GitHub has also seen more reports that: - Lack a working proof of concept - Describe only theoretical attack scenarios - Concern categories already listed as ineligible - Because this challenge affects the wider industry, some bug bounty programs have shut down; GitHub instead plans to improve its program. ## Requirements for Strong Reports - Submissions must include a working proof of concept demonstrating concrete security impact. - Researchers should show what an attacker can actually accomplish, rather than merely describing a possible attack path. - Reports must respect GitHub’s published scope and ineligible findings list. Examples of generally ineligible issues include: - DMARC, SPF, or DKIM configuration problems - User enumeration - Missing security headers without a demonstrated attack path - Scanner, static-analysis, or AI-generated findings must be manually validated before submission. - Unverified false positives create unnecessary triage work and may affect a researcher’s HackerOne Signal and reputation. ## AI Is Welcome, but Validation Is Required - GitHub supports the use of AI in security research and uses AI internally. - AI-assisted reports are acceptable when findings are reproduced, verified, and supported by a working proof of concept. - Researchers remain accountable for the accuracy of their submissions, regardless of which tools produced them. - GitHub recommends a concise report structure: - A short issue summary - Clear reproduction steps and evidence, such as screenshots, HTTP requests, or terminal output - An impact statement explaining what an attacker can achieve - Lengthy theoretical explanations and AI-generated filler can obscure the actual vulnerability and slow triage. ## Shared Responsibility and GitHub’s Security Boundary - GitHub protects users through automated scanning, manual review, and other systems for detecting malicious content. - Users are still responsible for deciding what repositories, issues, code, and scripts to trust. - Users should review content before executing or interacting with it. - Cloning a repository is considered an act of trust because Git hooks, build scripts, and other automation may run locally. - Users must also secure their own environments, including tokens, credentials, and local security settings. - Scenarios generally do not bypass GitHub’s security controls when they require victims to deliberately engage with attacker-controlled content. ## Common Shared-Responsibility Scenarios - Prompt injection in content a user intentionally provides to an AI tool - Git hooks or filters executing code from a repository the user checked out - Malicious content in a repository the user chose to clone - Unexpected LLM output caused by untrusted input supplied by the user Research into these areas remains useful when it identifies a way to bypass an actual GitHub security control without requiring the user to actively trust malicious content.

Read original(opens in new tab)

GitGithubAi SecurityStatic Analysis+4

line·May 15, 2026·3 min readCurated summary

ODW #6: The Pros and Cons of MCP and Agent Skills from a Git Automation Perspective

The post presents agent skills as a simpler, more practical alternative to building MCP servers for many AI-agent workflows. It demonstrates how to use Anthropic’s `skill-creator` to build a Git release automation skill that analyzes commits, updates a changelog, bumps versions, commits, tags, and pushes releases. The author emphasizes that precise requirements and explicit constraints are essential for preventing unintended agent behavior. ## Why Agent Skills Are Practical - Agent skills can simplify both implementation and architecture compared with custom MCP servers. - Although online examples explain the concept, the post focuses on a practical, work-oriented use case. - The tutorial assumes familiarity with the basic concept of skills and concentrates on building and applying one. ## Git Smart Release Automation The example skill automates releases for a Git project in the current working directory. - Reads the Git history after the most recent tag. - Summarizes changes and adds them to the top of `CHANGELOG.md`. - Creates `CHANGELOG.md` if it does not exist. - Updates the version in `pyproject.toml`. - Commits the changelog and version changes. - Creates a corresponding Git tag. - Operates based on the terminal’s current `pwd`. ## Using `skill-creator` - Anthropic’s official `skill-creator` skill is used to generate the new automation skill. - The user provides a detailed requirements specification rather than implementing everything manually. - Explicit workflow steps and constraints help keep the agent focused on the correct directory and avoid unnecessary complexity. - The development process is demonstrated with Claude Code. ## Clarifying Requirements Before generating the skill, the agent asks questions to resolve ambiguous behavior. - Support patch, minor, and major version bumps. - Use `v0.1.0` for the first release when no prior tag exists. - Follow a structured changelog format. - Push both commits and tags to the remote repository. - Abort with an explanation if the working directory contains uncommitted changes. ## Generated Skill Structure The completed skill contains: - `SKILL.md` — instructions and metadata for the agent. - `scripts/smart_release.py` — a local Python script that performs Git operations and file modifications. - `evals/evals.json` — evaluation cases for testing the skill. The skill also includes: - Keep a Changelog-style updates. - Dirty working-directory checks. - Automatic remote pushing. - Commit categorization such as `feat`, `fix`, and `docs`. ## `SKILL.md` and the Python Script - The frontmatter in `SKILL.md` acts as a concise discovery description that helps the agent decide when to load the skill. - The Markdown body provides the detailed execution workflow. - `smart_release.py` handles operations requiring deterministic file and Git manipulation, reducing the need for the language model to process raw data directly. - The post then begins testing the skill with a simple Python calculator project. A practical approach is to define release behavior, edge cases, and safety constraints before asking an agent to generate the skill, while delegating file and Git operations to a local script.

Read original(opens in new tab)

GitModel Context ProtocolPythonClaude Code+3

gitlab·May 11, 2026·4 min readCurated summary

GitLab Act 2

GitLab is restructuring its organization and strategy to prepare for an agent-driven software industry. It expects AI agents to dramatically increase software production, making scalable infrastructure, orchestration, context, and governance more important than traditional developer tooling. The company is reducing geographic footprint and management layers while reorganizing R&D around smaller, autonomous teams, reaffirming its FY27 guidance pending final restructuring costs. ## Organizational Restructuring - GitLab is conducting the process openly, including a voluntary separation window. - The new organizational shape is expected to be finalized by June 1 where possible; local legal processes may extend timelines. - Planned operational changes include: - Reducing the number of countries with small GitLab teams by up to 30%, while relying on partners in affected markets. - Removing up to three management layers in some functions. - Reorganizing R&D into approximately 60 smaller teams with end-to-end ownership. - Automating internal reviews, approvals, and handoffs with AI agents, then adjusting roles accordingly. - The restructuring and strategic shift are related but independently justified. - GitLab will disclose the restructuring’s final scope and financial impact during its June 2 earnings call. ## Software Development in the Agentic Era - Software will increasingly be produced by machines under human direction. - Agents will plan, code, review, deploy, and repair software. - Engineers will remain responsible for architecture, customer understanding, judgment, and difficult tradeoffs. - Lower software-production costs are expected to expand demand for software and increase the value of developer platforms. - Deep engineering skills—such as system design, distributed systems, failure analysis, and integrating new capabilities safely—will become more important and scarce. - GitLab points to its Duo Agent Platform, released in January, as an initial investment in this future. ## Infrastructure for Machine-Scale Development - Agents can create merge requests, trigger pipelines, and push commits at volumes far beyond human teams. - Git and existing development platforms were not designed for this level of activity. - GitLab plans to: - Reengineer Git for machine-scale workloads. - Replace parts of its monolithic architecture with API-first, composable services. - Provide agent-specific APIs so agents can interact as first-class platform users. - The company argues that reliability, performance, and scalability at this level will become a major source of platform value. ## Orchestration Across the Software Lifecycle - Enterprises need more than individual agents that generate code or open merge requests; they need software that reaches production and delivers business value. - GitLab’s orchestration layer is intended to coordinate agents across the lifecycle by: - Assigning work and managing state. - Passing context between tasks. - Resolving conflicts. - Enforcing policies and guardrails. - Keeping humans involved where judgment is required. - CI/CD is being reconsidered as part of this shift, with orchestration serving as the runtime for validating and safely deploying machine-rate changes. ## Context as a Competitive Advantage - Code generation capabilities are increasingly similar across developer-tool vendors. - GitLab believes its advantage lies in the connected context accumulated across planning, code, review, security, deployment, and operations. - It plans to make this data model a first-class, API-accessible service. - More contextual information should allow agents to use fewer tokens and produce better results. ## Governance Built Into the Platform - As agents perform more work, enterprises need strong control over identity, permissions, policies, auditing, and data location. - GitLab intends to make governance core infrastructure rather than an add-on product. - Every agent, pipeline, and merge request should operate through platform services that can: - Control who or what may perform an action. - Record what happened and why. - Protect sensitive code and data. - Support flexible deployment models. ## One Platform, Three Modes - GitLab notes that most business software cannot realistically be rewritten for the agentic era. - Its platform strategy is therefore intended to support existing codebases alongside newer development models. - The provided text ends before explaining the three modes in detail. GitLab’s overall recommendation to itself is to reshape both its organization and platform around machine-scale software development, while preserving human control over architecture, judgment, and governance.

Read original(opens in new tab)

GitAI AgentsCI/CDGitlab+4

gitlab·May 7, 2026·3 min readCurated summary

Consolidate your GitLab stack with Gitaly on Kubernetes

Gitaly on Kubernetes is now generally available with GitLab 18.11, allowing teams to run their entire GitLab stack in Kubernetes instead of maintaining Gitaly on separate virtual machines. GitLab addressed Kubernetes-specific challenges involving cgroup isolation, pod restarts, and request reliability. The result is a more unified deployment model, though full high availability still depends on Gitaly Cluster support for Kubernetes. ### Challenges of Running Gitaly on Kubernetes - Git operations can consume unpredictable amounts of memory. - Gitaly isolates individual Git processes in dedicated cgroups so an out-of-memory failure does not bring down the main Gitaly process. - Kubernetes deployments required special handling because containerd traditionally restricted cgroupfs writes to privileged containers. - GitLab solved this by using an init container to mount `/sys/fs/cgroup` and make it writable. ### Handling Pod Restarts - Virtual-machine deployments can upgrade Gitaly in place and reload gracefully while preserving the socket. - Kubernetes StatefulSet replacements cause pods to stop and restart abruptly during upgrades, node drains, or configuration changes. - This could cause downtime, particularly for Gitaly Sharded deployments without built-in high availability. - GitLab made Gitaly client retries configurable, allowing clients such as Rails to retry requests until Gitaly becomes available again. - Users may experience slightly higher latency during restarts, but requests generally succeed without visible downtime. ### Benchmark Results and High Availability - GitLab tested common Git operations against VM-based and Kubernetes-based Gitaly installations during upgrades. - Success rates were nearly identical in both environments despite Kubernetes abruptly terminating pods and closing sockets. - Achieving complete success across every operation still requires Gitaly Cluster with Praefect. - Praefect does not yet support Kubernetes, but Kubernetes support is being developed. ### Benefits for GitLab Deployments - Teams with hybrid infrastructure can move Gitaly from virtual machines into their existing Kubernetes cluster. - This removes the need to maintain and monitor a separate VM fleet. - Organizations adopting GitLab on Kubernetes can use a fully Kubernetes-native deployment through the official Helm chart. - Gitaly can run as part of a complete GitLab installation or as an external component. ### Installation - The recommended deployment method is the GitLab Helm chart. - Users should review the Gitaly on Kubernetes documentation before installation. - The documentation covers configuration guidance, common pitfalls, full installations, and external Gitaly deployments. Gitaly on Kubernetes is a practical option for consolidating GitLab infrastructure and simplifying operations. Teams should use the Helm chart and configure client retries carefully, while recognizing that Kubernetes-based high availability through Praefect is still forthcoming.

Read original(opens in new tab)

GitKubernetesGitlabGitops+4

line·Apr 21, 2026·3 min readCurated summary

ODW #3: Boosting Development Efficiency by Safely Utilizing MCP Servers

LY Corporation is expanding AI use across its engineering organization through MCP servers, which connect AI assistants with internal and external tools through a common protocol. The company combines this flexibility with allowlists, automated security checks, and internal standards to reduce risk. Its Orchestration Development Workshop demonstrates practical applications such as Jira ticket automation and multi-agent code reviews, while emphasizing shared learning and experimentation as AI practices evolve. ## MCP Servers and Their Benefits - MCP servers act as translators between AI assistants and external systems. - Before MCP, each assistant required a separate integration for every tool. - With MCP, a tool can implement one standardized interface and work with multiple compatible assistants. - This improves interoperability, scalability, and the ability to combine different AI tools. ## Security Risks and LY Corporation’s Controls - A 2025 Astrix Security report found that: - More than 5,200 public MCP servers were analyzed. - 53% relied on long-lived static API keys or personal access tokens. - Only 8.5% used newer authentication methods such as OAuth. - LY Corporation manages externally developed MCP servers through: - An allowlist permitting only approved servers. - Automated security verification based on internal standards. - Internal MCP servers for groupware and business systems are built to meet the company’s security requirements. - Centralized infrastructure lets teams focus on applying AI rather than independently rebuilding integrations and controls. ## Workshop Applications The Orchestration Development Workshop taught participants how to understand, configure, and safely apply MCP servers with AI assistants. - Topics included MCP fundamentals, security risks, internal policies, development rules, and configuration in Claude and Cline. - The internal plugin marketplace was introduced as a way to distribute MCP configurations. - Participants practiced using Claude Code with the internal groupware MCP server to: - Generate a Jira ticket title and summary. - Create the ticket automatically. - The exercise showed how AI can remove repetitive administrative work and free time for higher-value tasks. ## Multi-Agent Code Review Demonstration - A demonstration combined Claude Code, Codex CLI, Context7 MCP, and Codex MCP. - A Sonnet-based agent first analyzed a pull request, including: - Technical stack and relevant documentation. - Code changes and repository context. - Security, performance, and code-quality concerns. - GPT-5 then validated the initial review, identifying missed issues and checking the prioritization of findings. - Using different models provided more varied and potentially objective perspectives on the same code. ## Results and Organizational Learning - Around 1,600 people attended the workshop in real time. - 31.5% had already applied related techniques before the event. - Another 55.7% planned to try them soon. - LY also created “Help LY MCP,” a GPTs-based tool that explains internal MCP rules and helps teams assess whether proposed uses are suitable, including for global subsidiaries. - The workshop’s broader purpose was to create a shared understanding of: - What AI and MCP can currently do. - What risks and pitfalls exist. - How to use the technology meaningfully. ## Continuing to Experiment The article concludes that rapidly changing AI technology makes shared experimentation more valuable than simply announcing new tools. MCP may eventually be surpassed by other approaches, such as skills, so teams should continually reassess the best solution. LY recommends creating a culture where employees can safely try small ideas, learn together, and adapt as new practices emerge.

Read original(opens in new tab)

GitDatabase DesignGithubClaude Code+4

cloudflare·Apr 20, 2026·3 min readCurated summary

Building the agentic cloud: everything we launched during Agents Week 2026

Cloudflare’s Agents Week 2026 introduced a broad set of infrastructure primitives for building and operating AI agents at scale. The company argues that agents require a new cloud model—“Cloud 2.0”—with elastic compute, built-in security, persistent state, specialized tools, and support for agent-driven web traffic. Its announcements span compute environments, identity and networking, developer tooling, inference, voice, email, and memory. ## Compute for Autonomous Agents - **Artifacts** provides Git-compatible, versioned storage for code and data. It supports tens of millions of repositories, remote forking, and access through standard Git clients. - **Cloudflare Sandboxes**, now generally available, give agents persistent isolated computers with shells, filesystems, and background processes. Environments can start on demand and resume where they left off. - **Outbound Workers for Sandboxes** act as programmable, zero-trust egress proxies. They let developers inject credentials and apply dynamic outbound security policies without exposing secrets to agent-generated code. - **Durable Object Facets** allow dynamically generated Workers to create isolated Durable Objects with their own SQLite databases, enabling stateful applications built on the fly. - **Workflows** was rearchitected to support up to 50,000 concurrent executions and a creation rate of 300, making it more suitable for durable, long-running background agents. ## Security, Identity, and Private Networking - **Cloudflare Mesh** provides private network access for users, infrastructure, Workers, and autonomous agents. Combined with Workers VPC, it enables scoped access to private databases and APIs without manually configured tunnels. - **Managed OAuth for Cloudflare Access** lets agents authenticate to internal applications on behalf of users using RFC 9728 rather than insecure shared service accounts. - New identity controls include scannable API tokens, improved OAuth visibility, and resource-scoped permissions to support least-privilege access and automated credential protection. - Cloudflare outlined an enterprise architecture for governing **MCP** deployments using Access, AI Gateway, and MCP server portals. - **Code Mode** reduces MCP token costs, while new Cloudflare Gateway rules help detect unauthorized or “Shadow MCP” usage. ## The Agent Toolbox - A new preview of the **Agents SDK**, called Project Think, aims to provide a more complete platform for agents that can reason, act, and persist. - An experimental **voice pipeline** supports real-time speech-to-text and text-to-speech over WebSockets, requiring roughly 30 lines of server-side code. - **Cloudflare Email Service** entered public beta, allowing agents to send, receive, and process email as a native communication channel. - Cloudflare’s AI platform is becoming a unified inference layer supporting models from more than 14 providers, including third-party model bindings for Workers and an expanded multimodal catalog. - Cloudflare also described a custom infrastructure stack for serving large language models efficiently on its global network. - **Unweight**, a lossless inference-time compression system, reduces model footprints by up to 22%, improving GPU memory efficiency and potentially lowering inference cost and latency. - **Agent Memory** was introduced as a managed service for giving agents persistent memory, though the provided article excerpt ends before detailing its full capabilities. Cloudflare’s announcements collectively position Workers and related services as a platform for the agentic cloud: one capable of running agents, securing their access, preserving their state, and supplying the models and communication tools they need to operate continuously at Internet scale.

Read original(opens in new tab)

GitCloudflareDocker & ContainersServerless+4

gitlab·Apr 20, 2026·2 min readCurated summary

What’s new in Git 2.54.0?

Git 2.54.0 introduces foundational changes to Git’s storage and history-editing capabilities. Its object database is now pluggable, making alternative storage formats more feasible, while the new `git history` command simplifies common commit-history edits that previously required interactive rebases. These changes are early milestones in longer-term efforts to improve repository performance and support stacked-diff workflows. ## Pluggable Object Databases - Git already supports interchangeable reference backends, including `files` and `reftable`. - Git 2.54 extends this abstraction to object databases, which store loose objects and packfiles under `.git/objects`. - The work began in Git 2.48 and involved nearly 400 upstream commits over almost two years. - Alternative object-storage implementations can now support meaningful local workflows, including: - Creating commits - Displaying commit graphs - Performing merges - Remote operations such as fetching and pushing are not yet supported through alternate backends. - Future storage formats could: - Handle large binary files more efficiently than packfiles - Be optimized for GitLab’s repository-serving infrastructure - The project was led by Patrick Steinhardt. ## Easier Commit-History Editing - Developers often rewrite history to produce small, atomic commits with clear messages, but interactive rebases can be difficult to learn. - Interactive rebases require users to choose a base commit, edit an instruction sheet, and understand Git’s stateful rebase process. - Git 2.54 introduces `git history`, inspired partly by Jujutsu’s simpler history-editing commands. - Initial subcommands include: - `git history reword`: change a commit message - `git history split`: divide one commit into two by selecting which changes belong in each - Planned commands include: - `git history fixup` - `git history drop` - `git history reorder` - `git history squash` - The command can automatically rebase local branches that contain the edited commit, including branches other than the current one. - This behavior supports Git’s broader effort to improve stacked-diff workflows, where dependent branches are reviewed independently. - The project was led by Patrick Steinhardt with support from Elijah Newren. The release points toward a more extensible Git: repository storage can eventually be optimized for different workloads, while history editing becomes more approachable than traditional interactive rebases. Since both features are still developing, users should expect broader backend support and additional history commands in future releases.

Read original(opens in new tab)

GitOpen SourceGit HistoryPluggable Object Databases+3