githubJul 15, 2026

GitHub for Beginners: Your roadmap to mastering the GitHub essentials (opens in new tab)

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.

version-controlopen-sourcegithubgit+3

gitlabJun 29, 2026

What's new in Git 2.55.0? (opens in new tab)

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.

version-controlrustgitlinux+2

githubJun 26, 2026

Transitioning as a hubber (opens in new tab)

Arthur Searle describes transitioning at GitHub as a largely smooth experience, enabled by an inclusive, remote-first culture and strong workplace support. Using handles, written communication, flexible avatars, and gender-affirming benefits reduced many common sources of stress. His experience shows that transition can involve both bureaucratic challenges and profound joy when colleagues respond with acceptance and care. ## A Career Built at GitHub - Searle began in IT support and operations before teaching himself to code. - He joined GitHub’s IT Engineering team after a colleague’s referral and moved to Enterprise Security six months later. - His work has included: - Helping migrate GitHub’s main SaaS platform to infrastructure as code. - Speaking at Oxford University about version control. - Throughout his transition, his handle—“gleeblezoid”—remained constant, providing continuity at work. ## How GitHub’s Culture Supported Transition - GitHub’s remote-first structure reduced anxiety around appearance, commuting, and in-person interactions. - Much of Searle’s work happened through written communication in Slack and GitHub, limiting the pressure of speaking while undergoing voice training and hormone-related voice changes. - Employees commonly use handles and informal avatars, making gender assumptions based on appearance less central. - Searle was able to update his name and pronouns in internal systems, with colleagues consistently using them. ## Gender-Affirming Benefits - GitHub covered gender-affirming healthcare for employees. - Benefits included reimbursement for: - Voice training. - Hormone replacement therapy prescriptions. - Therapy. - The main remaining difficulty was ordinary administrative friction, such as changing his legal name in payroll systems. ## Acceptance, Joy, and Belonging - Searle contrasts his experience with people who remain closeted, repeatedly come out to new coworkers, or face extensive bureaucracy. - Colleagues treated his transition as a normal part of his life and expressed genuine happiness for him. - Small gestures had a major emotional impact, including hearing his name and pronouns used at work for the first time and receiving a shaving kit from a teammate. - He emphasizes that being trans is not defined only by hardship; there is also joy in living openly and being supported by others. GitHub’s example suggests that inclusive policies, flexible communication practices, and everyday respect can make workplace transition significantly safer and more affirming. For organizations, support should extend beyond formal benefits to the culture and systems employees use every day.

version-controlgithubslackinfrastructure-as-code+3

githubJun 16, 2026

What are git worktrees, and why should I use them? (opens in new tab)

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.

version-controlgithub-copilotgitai-assisted-development+1

githubJun 8, 2026

GitHub for Beginners: Answers to some common questions (opens in new tab)

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.

version-controlgithubgitssh+2

figmaMay 28, 2026

Figma Make, Now on Your Local Code | Figma Blog (opens in new tab)

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.

version-controlai-agentcollaborationfigma-make+3

githubMay 25, 2026

GitHub for Beginners: Getting started with Git and GitHub in VS Code (opens in new tab)

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.

version-controlgithubgitvisual-studio-code+3

gitlabApr 29, 2026

Teaching software development the easy way using GitLab (opens in new tab)

GitLab for Education can turn the administrative work of teaching software development into a scalable, professional workflow. University of Washington lecturer Stephen G. Dame uses GitLab groups, controlled permissions, merge requests, and inline comments to distribute materials, protect solutions, and provide contextual feedback. The approach helps students build real-world version-control and code-review habits while reducing instructor overhead. ## Building a Course Structure with Groups - Dame organizes the university in a root group such as `UWTeaching`, with one subgroup per course, such as `css430`. - Course subgroups contain: - Private lecture materials and code repositories - Student subgroups - Grader subgroups - Permissions inherit through the hierarchy, allowing instructors to control access centrally. - Students receive Reporter access with an expiration date tied to the academic quarter. - They can clone and pull assignment repositories but cannot push to instructor-controlled repositories. - Students use SSH keys across local machines, cloud shells, and virtual machines, then copy code into private repositories for their own version history. ## Automating Enrollment for Large Classes - Manually creating student accounts and permissions becomes impractical for large cohorts. - GitLab’s REST API can automate: - Creating personal subgroups for students - Looking up GitLab users - Assigning Reporter permissions - Setting membership expiration dates - GitLab also provides an open source class-management project with additional automation tools. ## Feedback Through Merge Requests - Students submit assignments by opening merge requests in their repositories. - Instructors immediately see a complete diff of the student’s work. - Comments can be attached directly to individual lines of code. - Inline feedback lets instructors explain both what is wrong and why, while directing students toward the next step. - Because feedback appears beside the relevant code, it is more actionable than comments on a separate document. ## Starting with GitLab for Education - The initial setup requires planning, but the workflow becomes largely self-sustaining once established. - GitLab for Education provides qualifying institutions with GitLab Ultimate features, including expanded storage, compute minutes, and merge-request capabilities. - Instructors are advised to begin with one course group, one assignment template, and a basic pipeline before expanding. A simple GitLab structure can make course administration more efficient while giving students practical experience with the collaborative development tools used in industry.

version-controldatabase-designgitlabopen-source+3

figmaJan 6, 2026

Issue No.14: Software Is Culture | Figma Blog (opens in new tab)

Software increasingly shapes how people communicate, play, create, eat, and connect. Figma’s January 2026 newsletter argues that as AI evolves from tool to teammate, software will become more responsive to human needs—and its cultural influence will grow. The issue explores this idea through design, language, gaming, food, and physical fabrication. ## Design Is Culture - Familiar interactions such as pinch-to-zoom, infinite scroll, and tap-to-like were once novel inventions. - These interface patterns have had a major influence on how an entire generation thinks and feels. - The newsletter highlights 10 iconic interactions to examine their broader cultural impact. ## Language Is Culture - Social media and recommendation algorithms help new slang spread rapidly, including expressions such as “6-7,” “aura,” and “rizz.” - Linguist Adam Aleksic explains that algorithms influence not only how people speak, but also how they think and relate to one another. - “Algospeak” has become a measure of virality and a distinctive feature of online communication. ## Gaming Is Culture - Video games have grown from simple experiences like Pong into a $184 billion industry built around expansive worlds, characters, game modes, and side quests. - Despite this complexity, players often navigate games through a small set of controller inputs. - Epic Games UX designer Aashrey Sharma examines how these simple controls enable rich interactions and what they suggest about the future of interfaces. ## Food Is Culture - British Columbia’s small farms are under pressure from factory farming and rising costs, with farmers reportedly leaving the industry at an alarming rate. - Entrepreneur Aaron Veale used Figma Make to build a marketplace connecting local growers with restaurants. - By prompting the AI tool, he produced a working minimum viable product in less than three weeks, demonstrating how AI can help individuals address urgent community problems. ## Fabrication Is Culture - Designer Kelsey Fairhurst combines digital design with hands-on manufacturing to create “softline brutalist” stainless-steel flatware. - Her Forks Plus project grew through years of research and work between a Brooklyn studio and a Cleveland fabrication shop. - The story presents software and design tools as companions to physical making rather than replacements for it. The newsletter’s central recommendation is implicit: treat software as a cultural force, not merely a productivity tool. Designers and builders should consider how the interfaces and AI systems they create will shape behavior, language, creativity, and everyday life.

version-controlfigmaaiuser-interface-design+4

figmaNov 18, 2024

Why Devs Should Play an Active Role in Design | Figma Blog (opens in new tab)

Developers should participate actively in design rather than treating design files as read-only specifications. Nicholas Villapiano argues that Figma’s Dev Mode reduces friction, improves confidence, and creates a shared workflow between designers and developers. Teams should advocate for these tools because they understand day-to-day collaboration problems better than management often does. ## Shared Tools Create a Common Language - Dev Mode gives developers a dedicated space within Figma instead of forcing them to work cautiously in designer-oriented files. - It treats developers as contributors to the product process, not merely implementers of finished designs. - Figma’s Auto Layout offered an early example of shared understanding by resembling CSS Flexbox and making designs behave more like responsive web layouts. - Dev Mode extends that connection into a broader framework for collaboration between design and engineering. ## Developers Should Advocate for Better Workflows - Managers may not see the practical pain points developers encounter when translating designs into code. - Developers already advocate for change through GitHub issues, pull requests, and technical discussions, so they should apply the same behavior to design and collaboration tools. - Useful opportunities to raise these needs include one-on-ones, sprint retrospectives, and team meetings. ## Exploring Designs Without Fear - Dev Mode is read-only by default, preventing accidental edits or deleted work. - This works much like branch protection on `main`: developers can investigate freely without risking the source file. - Greater confidence encourages developers to explore designs instead of avoiding or cautiously navigating them. ## Comparing Design Changes Clearly - Dev Mode provides version history and visual comparisons similar to Git commit history and pull requests. - Developers can see what changed, when it changed, and who made the change. - Differences become an actionable checklist, such as updating copy, adjusting margins, or adding a component variant. ## Reducing Context Switching - Developers often lose time switching between design files, documentation, and code. - Dev Mode and related tools such as Code Connect aim to bring implementation details closer to the design workflow. - Centralizing relevant information can reduce the “tab-switching tax” and make design-to-code work more efficient. ## Practical Recommendation Developers should actively evaluate and promote shared design-development tools like Dev Mode. By creating safer exploration, clearer change tracking, and a common language around implementation, teams can improve productivity, collaboration, and morale.

version-controlfigmadesign-systemsgithub+3

figmaOct 11, 2021

How (and why) we built branching | Figma Blog (opens in new tab)

Figma built branching to preserve the benefits of real-time collaboration without letting unfinished or experimental work disrupt approved designs. Branches provide isolated spaces for exploration while keeping the main file a reliable source of truth. The design prioritizes simplicity, familiar multiplayer behavior, and protection against data loss. ## The Need for Branching at Scale - Figma’s real-time multiplayer model usually helps teams work in one shared file. - As organizations grow, however, design workflows become harder to manage: - Unapproved changes can reach production code. - Work may be overwritten. - Teams may struggle to distinguish work in progress from approved designs. - Branches let designers experiment, iterate, contribute to libraries, or preview work without changing the main file. - Changes can be incorporated into the main file only after review and approval. ## Balancing Freedom and Structure - Growing design teams increasingly requested stronger version-control workflows. - Traditional branching comes from software development, where files and changes are stored locally. - Figma had to adapt the concept for cloud-based files, asking: - Whether people should continue editing the main file simultaneously. - How collaboration should work within branches. - How to introduce version control without overwhelming designers with complexity. ## Designing Around Figma’s Multiplayer Model - Figma chose a purpose-built approach rather than copying existing development tools. - Simplicity and consistency became core principles: - The main file remains multiplayer. - A branch behaves like a regular Figma file. - Existing editor and viewer permissions continue to apply. - The system emphasizes data safety so users’ changes remain protected. - Figma intentionally limited complexity, including preventing branches from being created from other branches. ## The Complexity of Merging - Merging involved more than simply resolving conflicting edits. - Figma also had to handle operational problems such as: - The file changing while someone reviews a merge. - A user losing their connection midway through the process. - These cases required safeguards to ensure merges remain understandable, recoverable, and safe. Branching is therefore presented as a structured layer on top of Figma’s collaborative model: teams can explore freely in branches while maintaining a dependable, approved main file.

version-controlfigmareal-time-collaborationcloud-computing+2

figmaApr 26, 2021

Introducing branching: space to iterate and explore freely | Figma Blog (opens in new tab)

Figma introduced branching in beta to help large design teams experiment without risking changes to shared files. The feature combines the freedom of isolated exploration with Figma’s multiplayer collaboration, while keeping the main file as the approved source of truth. Branches are auto-saved and can later be merged into the main file by editors. ## The challenge of decentralized design systems - Design systems were spread across teams and tools, creating inconsistencies and forcing designers to switch contexts. - Centralized systems improved reuse and efficiency but introduced governance challenges. - In large systems such as Netflix’s Hawkins, many contributors may update files, even when the latest changes are not approved for production. - Teams needed a way to protect shared libraries while still allowing designers to explore new ideas. ## Branching built around simplicity - Figma considered traditional workflows involving commits and nested branches too complex. - The product adopted two principles: simplicity and consistency. - Branches work within Figma’s existing multiplayer model, retaining real-time collaboration. - Work is automatically saved, eliminating the need for explicit commits. - Designers can create a branch from any file, experiment safely, and merge approved updates into the main file. ## Future plans and availability - Figma planned to expand branching with features such as reviews. - The company was also exploring a unified approach to versioning across branching and multiplayer workflows. - The beta initially launched for Organization-plan customers, with access granted gradually. Branching is intended to let organizations centralize their design systems without limiting experimentation. Teams managing shared libraries should use branches for exploratory work and merge only reviewed, approved changes into the main file.

version-controlfigmadesign-systemscollaboration+2

figmaJul 31, 2018

How Kiwi.com handles project structure, versioning & components in Figma | Figma Blog (opens in new tab)

Kiwi.com’s small mobile design team uses Figma to bring design collaboration, prototyping, versioning, and handoff into one shared environment. Their previous Sketch workflow depended on Sketch, Zeplin, Abstract, Marvel, and Dropbox Paper, creating frequent synchronization problems. Figma became attractive because it could centralize these activities and support contributions from around twenty collaborators. ## A Small Team with Many Contributors - Kiwi.com’s mobile design team consists of only two people. - Around twenty others contribute through: - Commenting on design iterations - Correcting copy - Designing cross-platform features - The broader front end and Orbit design system were built in Sketch. - Because Orbit’s mobile components differ visually, the team decided to explore building the mobile system in Figma. ## Problems with a Multi-tool Sketch Workflow - Sketch was used alongside: - Zeplin for developer handoff - Abstract for version control - Marvel for static prototypes - Dropbox Paper for embedded PNGs - These tools frequently fell out of sync: - Prototypes could reflect older tested versions. - Designers might forget to commit changes to Abstract. - Zeplin might not contain the latest approved visuals. - Documentation images could be weeks out of date. - The workflow required constant manual coordination between separate sources of truth. ## Why the Team Chose Figma - Figma offered a way to consolidate design work, collaboration, prototyping, and version history. - Its value became clearer in a team where many people needed access to current designs. - The author initially resisted Figma, preferring a native design application over a browser-based tool. - As Kiwi.com’s collaborative needs grew, the advantages of a shared, synchronized workspace outweighed that hesitation.

version-controlfigmadesign-systemsprototyping+2

figmaJun 12, 2018

A Sketch user's perspective on switching to Figma | Figma Blog (opens in new tab)

After using Figma for a month, Marco Pacifico argues that Sketch teams—especially distributed product teams—could gain substantially by switching. Figma combines Sketch-like design capabilities with prototyping, collaboration, developer handoff, version control, and cloud storage in one web-based tool. Its central advantage is reducing the syncing, uploading, and coordination overhead that slows design iteration. ## Web-Based Design and Real-Time Collaboration - Figma runs in browsers, with native apps available for offline work. - Work is automatically saved to a shared cloud space, eliminating manual file organization and updates. - A single URL serves as the source of truth for designers, developers, and stakeholders. - Teams no longer need to repeatedly upload screens, sync files, or distribute PNGs. - The author reports that Figma feels at least as performant as Sketch, including with large files. ## A Replacement for the Sketch Ecosystem The article presents Figma as combining the capabilities of several tools traditionally used alongside Sketch: - Sketch-like drawing tools and interface. - Clickable prototyping comparable to Craft and InVision. - Built-in comments, tagging, resolution tracking, and Slack integration. - Developer handoff with dimensions, styles, and downloadable assets. - Version history that allows users to restore or fork earlier designs. - Multiplayer editing with visible cursors and real-time drawing. - Live viewing of another collaborator’s screen and cursor. - Flexible components, intuitive constraints, and shared team libraries. - Dropbox Paper embedding. ## Faster Design Iteration - Designers can conduct reviews, make changes, and receive immediate feedback in the same file. - Iteration can shrink from days to minutes because teams avoid: - Re-uploading screens to InVision. - Reordering prototype screens after synchronization. - Waiting for teammates in other time zones to commit or upload work. - Recovering from broken third-party plugins after software updates. - Changes are visible immediately, so there is no separate synchronization step between the design file and prototype. ## A More Inclusive Design Process - The design file becomes a shared space where team members and stakeholders can discuss work directly. - Anyone with the link can participate through comments and collaborative review. - Real-time access makes design discussions more seamless and reduces barriers between distributed teammates. ## Practical Recommendation For teams currently assembling Sketch, Abstract, InVision, Craft, Zeplin, and collaboration tools into one workflow, the author recommends evaluating Figma as a unified alternative—particularly when rapid iteration and distributed collaboration are priorities.

version-controlfigmadesign-systemsprototyping+3

figmaNov 1, 2017

Introducing: Figma Pages | Figma Blog (opens in new tab)

Figma Pages adds an organizational layer within a single design file, letting designers separate brainstorming, wireframes, iterations, and final assets without creating separate documents. The feature supports multiple workflows, including platform-specific designs, shared component libraries, and multiple prototypes. Figma emphasizes that Pages are for organization—not version control—and warns that duplicating large files across Pages may hurt performance. ## Organizing Designs with Pages - Pages can be added, switched, or deleted from the file’s left-hand panel. - The Pages menu collapses after use but can be kept open with a control-click. - Sketch imports preserve the original document’s pages and symbols. - There is no limit to the number of Pages in a file. ## Common Uses - Separate brainstorming, wireframing, and polished designs. - Organize iOS and Android screens on different Pages. - Store shared components, icons, or other interface elements separately. - Choose the first Page to control which design appears as the file thumbnail. - Create separate prototypes within one file. ## Collaboration and Moving Components - Sharing one Page grants access to the entire file containing it. - Components can be moved between Pages by right-clicking and choosing **“Move to Page.”** ## Pages Versus Version Control - Pages should not be used to create copies of designs as a version-control system. - Figma already provides version history for tracking changes. - Repeatedly duplicating large designs across Pages can negatively affect performance. Figma Pages is best used to structure related design work within one accessible file, while Figma’s version history should handle historical snapshots and revisions.

version-controlfigmaprototypingui-ux-design+2