FAANGineering - BlogFlock

Usability and safety updates to Google Auth Platform - Google Developers Blog

2025-04-28T19:29:01.000Z

Updates to the Google Auth Platform include changes to OAuth configuration, client secrets display, and automatic deletion of unused clients, making the platform more secure and easier to use.

How Meta understands data at scale - Engineering at Meta

2025-04-28T16:30:19.000Z

Managing and understanding large-scale data ecosystems is a significant challenge for many organizations, requiring innovative solutions to efficiently safeguard user data. Meta’s vast and diverse systems make it particularly challenging to comprehend its structure, meaning, and context at scale.
To address these challenges, we made substantial investments in advanced data understanding technologies, as part of our Privacy Aware Infrastructure (PAI). Specifically, we have adopted a “shift-left” approach, integrating data schematization and annotations early in the product development process. We also created a universal privacy taxonomy, a standardized framework providing a common semantic vocabulary for data privacy management across Meta’s products that ensures quality data understanding and provides developers with reusable and efficient compliance tooling.
We discovered that a flexible and incremental approach was necessary to onboard the wide variety of systems and languages used in building Meta’s products. Additionally, continuous collaboration between privacy and product teams was essential to unlock the value of data understanding at scale.
We embarked on the journey of understanding data across Meta a decade ago with millions of assets in scope ranging from structured and unstructured, processed by millions of flows across many of the Meta App offerings. Over the past 10 years, Meta has cataloged millions of data assets and is classifying them daily, supporting numerous privacy initiatives across our product groups. Additionally, our continuous understanding approach ensures that privacy considerations are embedded at every stage of product development.

At Meta, we have a deep responsibility to protect the privacy of our community. We’re upholding that by investing our vast engineering capabilities into building cutting-edge privacy technology. We believe that privacy drives product innovation. This led us to develop our Privacy Aware Infrastructure (PAI), which integrates efficient and reliable privacy tools into Meta’s systems to address needs such as purpose limitation—restricting how data can be used while also unlocking opportunities for product innovation by ensuring transparency in data flows

Data understanding is an early step in PAI. It involves capturing the structure and meaning of data assets, such as tables, logs, and AI models. Over the past decade, we have gained a deeper understanding of our data, by embedding privacy considerations into every stage of product development, ensuring a more secure and responsible approach to data management.

We embarked on our data understanding journey by employing heuristics and classifiers to automatically detect semantic types from user-generated content. This approach has evolved significantly over the years, enabling us to scale to millions of assets. However, conducting these processes outside of developer workflows presented challenges in terms of accuracy and timeliness. Delayed classifications often led to confusion and unnecessary work, while the results were difficult to consume and interpret.

Data understanding at Meta using PAI

To address shortcomings, we invested in data understanding by capturing asset structure (schematization), describing meaning (annotation), and inventorying it into OneCatalog (Meta’s system that discovers, registers, and enumerates all data assets) across all Meta technologies. We developed tools and APIs for developers to organize assets, classify data, and auto-generate annotation code. Despite significant investment, the journey was not without challenges, requiring innovative solutions and collaboration across the organization.

Challenge	Approach
*Understanding at scale* (lack of foundation) At Meta, we manage hundreds of data systems and millions of assets across our family of apps. Each product features its own distinct data model, physical schema, query language, and access patterns. This diversity created a unique hurdle for offline assets: the inability to reuse schemas due to the limitations of physical table schemas in adapting to changing definitions. Specifically, renaming columns or making other modifications had far-reaching downstream implications, rendering schema evolution challenging, thus propagation required careful coordination to ensure consistency and accuracy across multiple systems and assets.	We introduced a shared asset schema format as a logical representation of the asset schema that can be translated back and forth with the system-specific format. Additionally, it offers tools to automatically classify data and send out annotation changes to asset owners for review, effectively managing long-tail systems.
*Inconsistent definitions* (lack of shared understanding) We encountered difficulties with diverse data systems that store data in various formats, and customized data labels that made it challenging to recognize identical data elements when they are stored across multiple systems.	We introduced a unified taxonomy of semantic types, which are compiled into different languages. This ensured that all systems can share the same canonical set of labels.
*Missing annotations* (lack of quality) A solution that relied solely on data scanning and pattern matching was prone to false positives due to limited contextual information. For instance, a 64-bit integer could be misclassified as either a timestamp or a user identifier without additional context. Moreover, manual human labeling is not feasible at scale because it relies heavily on individual developers’ expertise and knowledge.	We shifted left by combining schematization together with annotations in code, in addition improving and utilizing multiple classification signals. Strict measurements provided precision/recall guarantees. Protection was embedded in everything we built, without requiring every developer to be a privacy expert.
*Organizational barriers* (lack of a unified approach) Meta’s data systems, with their bespoke schematization and practices, posed significant challenges in understanding data across the company. As we navigated complex interactions and with ever evolving privacy requirements, it became clear that fragmented approaches to data understanding hindered our ability to grasp data comprehensively.	By collaborating with asset owners to develop intuitive tooling and improve coverage, we tackled adoption barriers such as poor developer experience and inaccurate classification. This effort laid the groundwork for a unified data understanding foundation, which was seamlessly integrated into the developer workflow. As a result, we drove a cultural shift towards reusable and efficient privacy practices, ultimately delivering value to product teams and fostering a more cohesive approach to data management.

Walkthrough: Understanding user data for the “Beliefs” feature in Facebook Dating

To illustrate our approach and dive into the technical solution, let’s consider a scenario involving structured user data. When creating a profile on the Facebook Dating app, users have the option to include their religious views to help match with others who share similar values.

On Facebook Dating, religious views are subject to purpose limitation requirements. Our five-step approach to data understanding provides a precise, end-to-end view of how we track and protect sensitive data assets, including those related to religious views:

Even a simple feature can involve data being processed by dozens of heterogenous systems, making end-to-end data protection critical. To ensure comprehensive protection, it is essential to apply the necessary steps to all systems that store or process data, including distributed systems (web systems, chat, mobile and backend services) and data warehouses.

Consider the data flow from online systems to the data warehouse, as shown in the diagram below. To ensure that religious belief data is identified across all these systems, we have implemented measures to prevent its use for any purpose other than the stated one.

Step 1 – Schematizing

As part of the PAI initiative, Meta developed DataSchema, a standard format that is used to capture the structure and relationships of all data assets, independent of system implementation. Creating a canonical representation for compliance tools. Understanding DataSchema requires grasping schematization, which defines the logical structure and relationships of data assets, specifying field names, types, metadata, and policies.

Implemented using the Thrift Interface Description Language, DataSchema is compatible with Meta systems and languages. It describes over 100 million schemas across more than 100 data systems, covering granular data units like database tables, key-value stores, data streams from distributed systems (such as those used for logging), processing pipelines, and AI models. Essentially, a data asset is like a class with annotated attributes.

Let’s examine the source of truth (SoT) for a user’s dating profile schema, modeled in DataSchema. This schema includes the names and types of fields and subfields:

  - user_id (uint)
  - name (string)
  - age (uint)
  - religious_views (enum)
  - photos (array<struct>):
     - url (url)
     - photo (blob)
     - caption (string)
     - uploaded_date (timestamp)
Dating profile DataSchema

The canonical SoT schema serves as the foundation for all downstream representations of the dating profile data. In practice, this schema is often translated into system-specific schemas (source of record – “SoR”), optimized for developer experience and system implementation in each environment.

Step 2 – Predicting metadata at scale

Building on this schematization foundation, we used annotations to describe data, enabling us to quickly and reliably locate user data, such as religious beliefs, across Meta’s vast data landscape. This is achieved through a universal privacy taxonomy, a framework that provides a common semantic vocabulary for data privacy management across Meta’s apps. It offers a consistent language for data description and understanding, independent of specific programming languages or technologies.

The universal privacy taxonomy works alongside data classification, which scans systems across Meta’s product family to ensure compliance with privacy policies. These systems use taxonomy labels to identify and classify data elements, ensuring privacy commitments are met and data is handled appropriately according to its classification.

Privacy annotations are represented by taxonomy facets and their values. For example, an asset might pertain to an Actor.Employee, with data classified as SemanticType.Email and originating from DataOrigin.onsite, not a third party. The SemanticType annotation is our standard facet for describing the meaning, interpretation, or context of data, such as user names, email addresses, phone numbers, dates, or locations.

Below, we illustrate the semantic type taxonomy node for our scenario, Faith Spirituality:

As data models and collected data evolve, annotations can become outdated or incorrect. Moreover, new assets may lack annotations altogether. To address this, PAI utilizes various techniques to continuously verify our understanding of data elements and maintain accurate, up-to-date annotations:

Our classification system leverages machine learning models and heuristics to predict data types by sampling data, extracting features, and inferring annotation values. Efficient data sampling, such as Bernoulli sampling, and processing techniques enable scaling to billions of data elements with low-latency classifications.

Key components include:

Scheduling component: manages the set of data assets to scan, accommodating different data system architectures by either pulling data via APIs or receiving data pushed directly into the scanning service.
Scanning service: processes and analyzes data from various sources by accumulating samples in memory, deserializing rows (e.g., JSON) into fields and sub-fields, and extracting features using APIs available in multiple languages (C++, Python, Hack). It ensures comprehensive data capture, even for ephemeral data.
Classification service: utilizes heuristic rules and machine learning models to classify data types with high accuracy.
- Heuristic rules: handle straightforward, deterministic cases by identifying specific data formats like dates, phone numbers, and user IDs.
- Machine learning models: trained on labeled datasets using supervised learning and improved through unsupervised learning to identify patterns and anomalies in unlabeled data.
- Ground truth calibration and verification: ensures system accuracy and reliability, allowing for model fine-tuning and improved classification performance.
Lineage and propagation: We integrate classification rules with high-confidence lineage signals to ensure accurate data tracking and management. Our propagation mechanism enables the seamless annotation of data as needed, ensuring that exact copies of data across systems receive equivalent classification. This approach not only maintains data integrity but also optimizes the developer experience by streamlining the process of managing data classifications across our diverse systems.

Step 3 – Annotating

The integration of metadata predictions and developer input creates a comprehensive picture of a data asset’s structure (schema) and its meaning (annotation). This is achieved by attaching these elements to individual fields in data assets, providing a thorough understanding of the data.

Building on the predicting data at scale initiative (step 2), where we utilize the universal privacy taxonomy and classification systems to identify and classify data elements, the generated metadata predictions are then used to help developers annotate their data assets efficiently and correctly.

Portable annotation APIs: seamlessly integrate into developer workflows ensuring:

Consistent representation of data across all systems at Meta.
Accurate understanding of data, enabling the application of privacy safeguards at scale.
Efficient evidencing of compliance with regulatory requirements.

Metadata predictions and developer input: Two key components work together to create a comprehensive data asset picture:

Metadata predictions: Classifiers generate predictions to aid developers in annotating data assets efficiently and correctly. If the confidence score exceeds a certain threshold, assignment can be automated, saving developer time.
Developer input: Developers manually refine and verify annotations, ensuring that the data’s context and privacy requirements are accurately captured. Human oversight guarantees the accuracy and reliability of the data asset picture.

- user_id (enum) 		→ SemanticType::id_userID
  - name (string) 			→ SemanticType::identity_name
  - age (uint) 			→ SemanticType::age
  - religious_views (enum) 	→ SemanticType::faithSpirituality
  - photos (array<struct>):
     - url (url) 			→ SemanticType::electronicID_uri_mediaURI_imageURL
     - photo (blob) 		→ SemanticType::media_image
     - caption (string) 		→ SemanticType::media_text_naturalLanguageText
     - uploaded_date (timestamp) → SemanticType::uploadedTime

Ensuring complete schemas with annotations: To maintain a high standard of data understanding, we have integrated data understanding into our data model lifecycle. This includes auto-generating code to represent the schema of newly created assets when missing, ensuring that no new assets are created without a proper schema.

For example, in the context of our religious beliefs in Facebook Dating, we have defined its structure, including fields like ‘Name,’ ‘EmailAddress,’ and ‘Religion.’ Furthermore, we have annotated the asset with Actor::user(), signifying that the data pertains to a user of our products. This level of detail enables us to readily identify fields containing privacy-related data and implement appropriate protective measures, such as applying the applicable purpose limitation policy.

In the case of the “dating profile” data asset, we have defined its structure, including fields like ‘Name’:

final class DatingProfileSchema extends DataSchemaDefinition {

 <<__Override>>
 public function configure(ISchemaConfig $config): void {
   $config->metadataConfig()->description('Represents a dating profile);
   $config->annotationsConfig()->annotations(Actor::user());
 }

 <<__Override>>
 public function getFields(): dict<string, ISchemaField> {
   return dict[
     'Name' => StringField::create("name")
        ->annotations(SemanticType::identity_name())
        ->example('John Doe'),
     'Age' => StringInt::create('age')
        ->description(“The age of the user.”)
        ->annotations(SemanticType::age())
        ->example('24'),
     'ReligiousViews' => EnumStringField::create('religious_views')
        ->annotations(SemanticType::faithSpirituality())
        ->example('Atheist'),
   ];
 }
}

In order to optimize for developer experience, the details of the schema representation differ in each environment. For example, in the data warehouse, it’s represented as a Dataset – an in-code Python class capturing the asset’s schema and metadata. Datasets provide a native API for creating data pipelines.

Here is an example of such a schema:

@hive_dataset(
	"dim_all_dating_users", // table name
	"dating", // namespace
	oncall="dating_analytics",
	description="This is the primary Dating user dimension table containing one row per Dating user per day along with their profile, visitation, and key usage information.",
	metadata=Metadata(Actor.User),
)
class dim_all_dating_users(DataSet):
ds: Varchar = Partition("datestamp")
userid: DatingUserID = Column("User id of the profile")
email: EmailAddress = Column("User's email address"),
	age: PersonAge = Column("User's stated age on date ds")
	religious_views: ReligionOptions = Column("User's provided religious views")

Our warehouse schema incorporates rich types, a privacy-aware type system designed to enhance data understanding and facilitate effective data protection. Rich types, such as DatingUserID, EmailAddress, PersonAge, and ReligionOptions, are integrated into the schema, offering a comprehensive approach to data management while encoding privacy metadata. They provide a developer-friendly way to annotate data and enable the enforcement of data quality rules and constraints at the type level, ensuring data consistency and accuracy across the warehouse. For instance, they can detect issues like joining columns with different types of user IDs or mismatched enums before code execution.

Here is an example definition:

ReligionOptions = enum_from_items(
    "ReligionOptions",
    items=[
        EnumItem("Atheist", "Atheist"),
        EnumItem("Buddhist", "Buddhist"),
        EnumItem("Christian", "Christian"),
        EnumItem("Hindu", "Hindu"),
        EnumItem("Jewish", "Jewish"),
        EnumItem("Muslim", "Muslim"),
  ...
    ],
    annotations=(SemanticType.faithSpirituality,),
)

Step 4 – Inventorying assets and systems

A central inventory system is crucial for managing data assets and their metadata, offering capabilities like search and compliance tracking. Meta’s OneCatalog is a comprehensive system that discovers, registers, and enumerates all data assets across Meta’s apps, providing inventory for easier management and tracking.

Key functions of OneCatalog:

Registering all data systems: OneCatalog defines a data system as a logical abstraction over resources that persist data for a common purpose. It exhaustively examines resources across Meta’s environments to discover and register all data systems hosting data assets.
Enumerating all data assets: Eligible data systems must enumerate their assets through the asset enumeration platform, generating a comprehensive list of assets and their metadata in the central inventory. These assets are grouped by “asset classes” based on shared patterns, enabling efficient management and understanding of data assets.

Guarantees provided by OneCatalog:

Completeness: The system regularly checks for consistency between the data defined in its configuration and the actual data stored in the inventory. This ongoing comparison ensures that all relevant data assets are accurately accounted for and up-to-date.

Freshness: In addition to regularly scheduled pull-based enumeration, the system subscribes to changes in data systems and updates its inventory in real time.

Uniqueness of asset ID (XID): Each asset is assigned a globally unique identifier, similar to URLs, which facilitates coordination between multiple systems and the exchange of information about assets by providing a shared key. The globally unique identifier follows a human-readable structure, e.g., asset://[asset-class]/[asset-name].

Unified UI: On top of the inventory, OneCatalog provides a unified user interface that consolidates all asset metadata, serving as the central hub for asset information. This interface offers a single point of access to view and manage assets, streamlining the process of finding and understanding data.

For example, in the context of our “religious beliefs in the Dating app” scenario, we can use OneCatalog’s unified user interface to view the warehouse dating profile table asset, providing a comprehensive overview of its metadata and relationships.

Compliance and privacy assurance: OneCatalog’s central inventory is utilized by various privacy teams across Meta to ensure that data assets meet requirements. With its completeness and freshness guarantees, OneCatalog serves as a reliable source of truth for privacy and compliance efforts.

By providing a single view of all data assets, OneCatalog enables teams to efficiently identify and address potential risks or vulnerabilities, such as unsecured data or unauthorized access.

Step 5 – Maintaining data understanding

To maintain high coverage and quality of schemas and annotations across Meta’s diverse apps, we employed a robust process that involves measuring precision and recall for both predicted metadata and developer-provided annotations. This enables us to guide the implementation of our privacy and security controls and ensure their effectiveness.

By leveraging data understanding, tooling can quickly build end-to-end compliance solutions. With schema and annotations now front and center, we’ve achieved continuous understanding, enabling our engineers to easily track and protect user data, implement various security and privacy controls, and build new features at scale.

Our strategy for maintaining data understanding over time includes:

Shifting left on creation time: We provided intuitive APIs for developers to provide metadata at asset creation time, ensuring that schemas and annotations were applied consistently in downstream use cases.
Detecting and fixing annotation gaps: We surfaced prediction signals to detect coverage and quality gaps and evolved our prediction and annotation capabilities to ensure new systems and workflows were covered.
Collecting ground truth: We established a baseline to measure automated systems against, with the help of subject matter experts, to continuously measure and improve them.
Providing canonical consumption APIs: We developed canonical APIs for common compliance usage patterns, such as detecting user data, to ensure consistent interpretation of metadata and low entry barriers.

Putting it all together

Coming back to our scenario: As developers on the Facebook Dating team collect or generate new data, they utilize familiar APIs that help them schematize and annotate their data. These APIs provide a consistent and intuitive way to define the structure and meaning of the data.

When collecting data related to “Faith Spirituality,”the developers use a data classifier that confirms their semantic type annotations once the data is scanned during testing. This ensures that the data is accurately labeled and can be properly handled by downstream systems.

To ensure the quality of the classification system, ground truth created by subject matter experts is used to measure its accuracy. A feedback loop between the product and PAI teams keeps the unified taxonomy updated, ensuring that it remains relevant and effective.

By using canonical and catalogued metadata, teams across Meta can implement privacy controls that are consistent and effective. This enables the company to maintain user trust and meet requirements.

In this scenario, the developers on the Facebook Dating team are:

Schematizing and annotating their data using familiar APIs.
Using a data classifier to confirm semantic type annotations.
Leveragig ground truth to measure the quality of the classification system.
Utilizing a feedback loop to keep the unified taxonomy updated.
Implementing privacy controls using canonical and catalogued metadata.

Learnings and takeaways

Building an understanding of all data at Meta was a monumental effort that not only required novel infrastructure but also the contribution of thousands of engineers across all teams at Meta, and years of investment.

Canonical everything: Data understanding at scale relies on a canonical catalog of systems, asset classes, assets, and taxonomy labels, each with globally unique identifiers. This foundation enables an ecosystem of compliance tooling, separating the concerns of data understanding from consuming canonical metadata.
Incremental and flexible approach: To tackle the challenge of onboarding hundreds of systems across Meta, we developed a platform that supports pulling schemas from existing implementations. We layered solutions to enhance existing untyped APIs, meeting developers where they are—whether in code, configuration, or a UI defining their use case and data model. This incremental and flexible approach delivers value at every step.
Collaborating for data classification excellence: Building the platform was just the beginning. The infrastructure and privacy teams also collaborated with subject matter experts to develop best-in-class classifiers for our data, addressing some of the most challenging problems. These include detecting user-generated content, classifying data embedded in blobs, and creating a governed taxonomy that allows every developer to describe their data with the right level of detail.
Community engagement with a tight feedback loop: Our success in backfilling schemas and integrating with the developer experience was made possible by a strong partnership with product teams. By co-building solutions and establishing an immediate feedback loop, we refined our approach, addressed misclassifications, and improved classification quality. This collaboration is crucial to our continued evolution and refinement of data understanding.

The future of data understanding

Data understanding has become a crucial component of Meta’s PAI initiative, enabling us to protect user data in a sustainable and effective manner. By creating a comprehensive understanding of our data, we can address privacy challenges durably and more efficiently than traditional methods.

Our approach to data understanding aligns closely with the developer workflow, involving the creation of typed data models, collection of annotated data, and processing under relevant policies. At Meta’s scale, this approach has saved significant engineering effort by automating annotation on millions of assets (i.e., fields, columns, tables) with specific labels from an inventory that are deemed commitment-critical. This automation has greatly reduced the manual effort required for annotation, allowing teams to focus on higher-priority tasks.

As data understanding continues to evolve, it is expected to have a significant impact on various aspects of operations and product offerings. Here are some potential future use cases:

Improved AI and machine learning: leveraging data understanding to improve the accuracy of AI-powered content moderation and recommendation systems.
Streamlined developer workflows: integrating data understanding into Meta’s internal development tools to provide clear data context and reduce confusion.
Operational and developer efficiency: By automating data classification and annotation for millions of assets across Meta’s platforms, we can significantly improve operational efficiency. This automation enables us to leverage metadata for various use cases, such as accelerating product innovation. For instance, we’re now utilizing this metadata to help developers efficiently find the right data assets, streamlining their workflow and reducing the time spent on manual searches.
Product innovation: With a comprehensive understanding of data, Meta can drive product innovation by leveraging insights to create personalized and engaging user experiences.

While there is still more work to be done, such as evolving taxonomies to meet future compliance needs and developing novel ways to schematize data, we are excited about the potential of data understanding. By harnessing canonical metadata, we can deepen our shared understanding of data, unlocking unprecedented opportunities for innovation not only at Meta, but across the industry.

Acknowledgements

The authors would like to acknowledge the contributions of many current and former Meta employees who have played a crucial role in developing data understanding over the years. In particular, we would like to extend special thanks to (in alphabetical order) Adrian Zgorzalek, Alex Gorelik, Alex Uslontsev, Andras Belokosztolszki, Anthony O’Sullivan, Archit Jain, Aygun Aydin, Ayoade Adeniyi, Ben Warren, Bob Baldwin, Brani Stojkovic, Brian Romanko, Can Lin, Carrie (Danning) Jiang, Chao Yang, Chris Ventura, Daniel Ohayon, Danny Gagne, David Taieb, Dong Jia, Dong Zhao, Eero Neuenschwander, Fang Wang, Ferhat Sahinkaya, Ferdi Adeputra, Gayathri Aiyer, George Stasa, Guoqiang Jerry Chen, Haiyang Han, Ian Carmichael, Jerry Pan, Jiang Wu, Johnnie Ballentyne, Joanna Jiang, Jonathan Bergeron, Joseph Li, Jun Fang, Kaustubh Karkare, Komal Mangtani, Kuldeep Chaudhary, Matthieu Martin, Marc Celani, Max Mazzeo, Mital Mehta, Nevzat Sevim, Nick Gardner, Lei Zhang, Luiz Ribeiro, Oliver Dodd, Perry Stoll, Prashanth Bandaru, Piyush Khemka, Rahul Nambiar, Rajesh Nishtala, Rituraj Kirti, Roger (Wei) Li, Rujin Cao, Sahil Garg, Sean Wang, Satish Sampath, Seth Silverman, Shridhar Iyer, Sriguru Chakravarthi, Sushaant Mujoo, Susmit Biswas, Taha Bekir Eren, Tony Harper, Vineet Chaudhary, Vishal Jain, Vitali Haravy, Vlad Fedorov, Vlad Gorelik, Wolfram Schuttle, Xiaotian Guo, Yatu Zhang, Yi Huang, Yuxi Zhang, Zejun Zhang and Zhaohui Zhang. We would also like to express our gratitude to all reviewers of this post, including (in alphabetical order) Aleksandar Ilic, Avtar Brar, Brianna O’Steen, Chloe Lu, Chris Wiltz, Imogen Barnes, Jason Hendrickson, Rituraj Kirti, Xenia Habekoss and Yuri Claure. We would like to especially thank Jonathan Bergeron for overseeing the effort and providing all of the guidance and valuable feedback, and Ramnath Krishna Prasad for pulling required support together to make this blog post happen.

The post How Meta understands data at scale appeared first on Engineering at Meta.

GitHub for Beginners: Building a REST API with Copilot - The GitHub Blog

2025-04-28T13:00:42.000Z

Welcome to the next episode in our GitHub for Beginners series, where we’re diving into the world of GitHub Copilot. This is our fifth episode, and we’ve already talked about Copilot in general, some of its essential features, how to write good prompts, and a bit about security best practices. We have all the previous episodes on our blog and available as videos.

Today we’re diving a little deeper—we’re using GitHub Copilot to help us build a backend REST API. We’ll walk through how to build the backend for Planventure, a travel itinerary builder that helps users plan their trips. You can find a full description of what we’ll be building in this repository.

What you’ll need and what we’re building

Before we get started, here’s what you’ll need to install:

A code editor like VS Code
Python
SQLite Viewer to view database tables
An API client like Bruno to test your routes
Access to GitHub Copilot — sign up for free!

What we’re building:

We’re creating a minimum viable product (MVP) for Planventure’s backend API. In the next episode, we’ll build the frontend to connect to the API.

Here’s what we’ll include:

REST API built with Flask
Database support using SQLAlchemy
User authentication (with password hashing and JWTs)
Full CRUD functionality for trips

Each trip will include:

Destination
Start and end dates
A basic itinerary with location coordinates (perfect for maps)

At the end of this, we want to have a working API that handles user authentication and basic trip management.

Step 1: Setting up the environment

Fork and clone the planventure repository.

Once you’ve done that, cd into the planventure-api directory in your code editor.

git clone https://github.com/github-samples/planventure
cd planventure-api

Open up your terminal and run the following commands to create and activate a virtual environment.

python3 -m venv venv
source venv/bin/activate

Assuming you’re using VS Code, you’ll see venv in the status bar at the bottom. If you’re using another editor, be sure to verify that you’re in your virtual environment.

Staying in your terminal, run this command to install dependencies:

pip install -r requirements.txt

Run the following command in your terminal to start the server:

flask run --debug

You should see your server running on 127.0.0.1:5000. Use Bruno to make a GET request to that URL and you should see the following welcome message:

Remember to add venv/ to your .gitignore!

Step 2: Create the Database

Now that you’ve got your environment created, it’s time to start using Copilot to generate some code. We’ll use Copilot Chat and Copilot Edits to generate our database setup.

Open the app.py file and Copilot Chat, choose the Ask option, and enter the following prompt:

@workspace Update the Flask app with SQLAlchemy and basic configurations

At the bottom of the chat window, click the model selector and select the Claude 3.5 Sonnet model and send the prompt.

Copilot will provide a plan, a code block, and a summary of suggested changes.

Whenever you receive code suggestions from Copilot, it’s important to review them and understand the changes it’s suggesting. After reviewing the changes, hover over the code block and click the Apply in editor button—the first button in the top-right of the suggested code.

Select the option to apply the changes into the active editor. Copilot will make these updates in the open file. Click Accept to add those changes.

https://github.blog/wp-content/uploads/2025/04/apply_in_editor_vid.mp4#t=0.001

If Copilot provided suggestions that need to be in a new file, hover over the change and select the three dots, then select Insert into New File and save.

https://github.blog/wp-content/uploads/2025/04/insert_new_file.mp4#t=0.001

Now we need to update our dependencies. Go back to Copilot Chat and enter the following prompt:

@workspace update requirements.txt with the necessary packages for Flask API with SQLAlchemy and JWT

Open the requirements.txt file. Hover over the suggested changes, click the Apply in editor button, and once again select the option to apply the changes into the active editor. Just like before, accept the changes and save the file.

Step 3: Time to create some models

Now it’s time to create our User and Trip models. This GitHub issue describes our requirements. According to the issue, the User model needs an email, a password, and must include password hashing and timestamps. The Trip model needs to have a destination, start and end dates, coordinates, and an itinerary with a user relationship.

To do all of this, we’re going to use Copilot Edits.

Click on the chat icon in your editor, and from the dropdown, select Edits.

Open your app.py and requirements.txt file and drag them into the chat window. Then choose the Claude 3.5 Sonnet model from the model picker.

Now send the following prompt to Copilot Edits:

Create SQLAlchemy User model with email, password_hash, and timestamps. Add code in new files.

Copilot Edits will then create a plan to do what you asked. It creates some new files and folders, as well as updates existing files. Accept the changes, review the code, and make any corrections necessary before saving the files.

https://github.blog/wp-content/uploads/2025/04/edits_prompt_flow.mp4#t=0.001

Check the video for examples of things to look for, but remember that your changes might be different. Copilot can provide different suggestions for the same prompts.

Now create a python script to create the database tables. Send Copilot Edits the following prompt:

Update code to be able to create the db tables with a python shell script.

As before, Copilot Edits will go to work and create or edit files as necessary. Accept the code and review the changes, making sure these changes address your needs. After saving the reviewed changes, go back to your terminal and initialize the database by running:

python3 init_db.py

If Copilot Edits created a different filename than init_db.py, use the filename in your project.

After the script runs, you’ll see a new planventure.db file in your project. However, you need to install an extension in order to see the tables. Navigate to the extensions tab and search for “SqLite viewer”. Click Install, and then click on planventure.db to get a look at the table.

Now that you’ve created the User model, you need the Trip model. Navigate back to Copilot Edits and send:

Create SQLAlchemy Trip model with user relationship, destination, start date, end date, coordinates, and itinerary

By now you can probably guess what you need to do. It’s time to accept the changes and review them, making sure to correct anything that wasn’t exactly what you needed. Go ahead and save the files after you’re satisfied with the updates.

Go back to your terminal and initialize the database again to add the trips table:

python3 init_db.py

Open planventure.db in your editor and verify that the trips table exists.

https://github.blog/wp-content/uploads/2025/04/init_db.mp4#t=0.001

With both of these models added, it seems like a good time to commit these changes before moving on to the next step. Click the source control button in the left-hand bar in your editor. Hover over the Changes row, and click the plus icon to stage your changes for all of the files below.

https://github.blog/wp-content/uploads/2025/04/stage_commit.mp4#t=0.001

In the box for a commit message, click the sparkles button. Copilot will then generate a commit message for you in the box, describing all of the changes! Don’t forget to click the Commit button to commit your changes and update your repository.

Step 4: Adding authentication

We all know that security is important, so it’s time to start talking about adding some authentication to our API. This issue lays out our authentication requirements. According to the issue, we want to make sure we include password hashing and salt for extra security. To get started, we’re once again going to count on Copilot Edits.

Navigate back to Edits and send it the following prompt:

Create password hasing and salt utility functions for the User model.

As always, read the summary of what Copilot did and make sure to review each individual file for the relevant changes. Once you’re satisfied with the updates, save the files.

Next, you need to set up the JWT token and validation. Send the following prompt to Copilot Edits:

Setup JWT token generation and validation functions.

Review the changes, make any adjustments as necessary, and then save the files. Remember that we can’t predict what tweaks might be necessary. This is because Copilot might not give the exact same response to the same prompt. That’s part of the nature of any generative AI, and part of what makes them so versatile. It’s also why you always need to carefully review the suggestions and make sure you understand them.

Now you need to create the actual route so that we can register a new user. Copilot Edits come to our aid again here. Send it the following prompt:

Create auth routes for user registration with email validation.

Go ahead and accept and review these changes. Don’t forget to read the summary that Copilot provides in the Copilot Edits window to help with understanding the updates. Save the files.

https://github.blog/wp-content/uploads/2025/04/register_route.mp4#t=0.001

And now you have enough code to go ahead and test the route! Head back to Bruno and create a POST request. You’ll start with the same URL you used earlier, back when you sent the GET request to verify the server was up and running. Paste that URL into the POST box, and then add /auth/register to the end. So if your URL was 127.0.0.1:5000, the full URL would be 127.0.0.1:5000/auth/register. Click the Body tab and select JSON from the pull down menu at the top. Enter the following text into the large box for the body.

{
  "email": "test@email.com",
  "password": "test1234"
}

Such a secure password! Obviously, this is just for the demo. When you’re creating actual accounts, make sure to use a stronger, more secure password. Note that you don’t need to set up an auth token yet because you’ll get that access token from the server when you register.

Continuing with setting up our test, click the Headers tab. Add a header with the name Content-Type and a value of application/JSON.

Now it’s time to test the connection. Click the arrow at the end of the POST row. If everything is working and set up correctly, you’ll receive a 200 response.

Once you get that response, go back to VS Code and open the planventure.db file. Refresh the file and select the users table. The user you just added will be represented in the table.

With this piece complete, you now need to add the login route. In order to do this, you’re going to keep using our good friend Copilot Edits. Send it the following prompt:

Create login route with JWT token generation.

Copilot will make suggestions to give you the full route that you can accept and test right away in Bruno. Switch back to Bruno, and hover over the POST register request in the left-hand window under Planventure. Click the ... to show the context menu, and select Clone. Change the request name to login and click Clone. Click the arrow to send the command, and you should receive a message that the login was successful.

Congratulations, your login route is working! Users can now register and log in successfully.

The next thing you need to do is add an auth middleware to protect your routes. Head back to Copilot Edits to continue coding using natural language and send it this prompt:

Create auth middleware to protect routes.

Review and accept the changes, then head back to Bruno to test the routes again. Navigate back to your POST login request, and click the arrow once again to send the command. If you receive a message that the login was successful, everything’s working perfectly.

Now that you’ve finished adding authentication to your code, make sure to commit your changes and push them up to GitHub. Remember that you can use the sparkles button to have Copilot create a commit description for you! Just remember to review it before submitting.

Step 5: Adding trips

You’ve got the users, but in order to use Planventure, users need to be able to add trips. The scope of this work is captured in this issue. In order to cover our needs, the trip route needs full CRUD operations with a default itinerary template. Since we’ve had so much success with it so far, let’s keep using Copilot Edits.

Send it the following prompt to get started:

Create Trip routes blueprint with CRUD operations.

The expectation is that you’ll get the CREATE, READ, UPDATE, and DELETE routes with this prompt. Just like you did before when adding authentication, make sure to review the changes and that you understand what changed. Make any necessary adjustments, and then save the files.

Once you’ve accepted these changes, use Copilot Chat to generate some sample data. It’s much easier to have Copilot create it than to do so manually. Open up your chat window and send it the following prompt:

Create example json to test the trips route

Copilot will create some sample data that you can use to test your routes. Hover over the supplied JSON code and click the Copy button.

Go back to Bruno, and clone the POST login request. Change the name to CREATE trip and click the Clone button. Change the POST address from <IP>/auth/login to <IP>/api/trips. Click the Body tab and replace the body with the JSON you copied to the clipboard in the previous step.

https://github.blog/wp-content/uploads/2025/04/cloning_post_request.mp4#t=0.001

Before sending this request, we need to add our authorization token. Navigate to the POST login request by clicking that tab at the top of the window. Click the arrow to send the command, and then copy the token value. Click the POST CREATE trip tab at the top, and then the Auth tab underneath the POST address. Make sure that the type of authorization is Bearer Token, and then replace any text in the Token field with the token you copied from the login request.

If you run into an error, copy the error message and head back to VS Code to get Copilot’s help debugging the error. Use the /fix slash command in the Copilot Chat window, and then paste the error message. To watch a demo of this process, you can check the video version of this GitHub for Beginners episode.

After performing any necessary debugging, you should receive a response that the trip was successfully created. You can verify this by going back to VS Code, opening the planventure.db file, refreshing it, and looking at the trips table.

https://github.blog/wp-content/uploads/2025/04/post_debugging.mp4#t=0.001

You can now add trips to your database! Now it’s time to test getting a trip id.

Go back to Bruno and clone the POST CREATE trip request. Rename it to GET trip id and click Clone. Click POST at the top to open a dropdown menu, and select GET to change the request to a GET request. Click the Body tab and delete the current body. Update the URL to include the ID of the trip you want to fetch. For example, 127.0.0.1:5000/api/trips/1. Click the arrow to send the command, and the response should include all of the trip data in the database that matches that trip id. Just like before, if you run into any errors, you can use Copilot Chat to help you debug them until you’re able to successfully receive a response.

With this working, it’s time to add the default itinerary template. If you guessed that you’d be using Copilot Edits to help you out here, you’d be right! Go ahead and send it the following prompt:

Create function to generate default itinerary template.

As always, give the code changes a review and make sure you know what the code does. Save the files, and give it a test. Go back to Bruno, and select the POST CREATE trip request. Change something in the body, such as the destination, and send the request by clicking the arrow icon. If you run into any errors, use Copilot Chat to help you debug them and suggest code changes to address them.

https://github.blog/wp-content/uploads/2025/04/debugging_copilot_edited.mp4#t=0.001

When you successfully add a new trip, you then want to verify that it uses the default itinerary. Select the GET GET trip id request, and update the URL to match the id of the trip you just created. For example, if this was the second trip you added, change the last part of the URL to /2. Check the response, and verify that it’s using the default itinerary. If it is, well done! You’ve now addressed the requested changes for this issue! That means it’s time to commit these changes.

Don’t forget about CORS

There’s a lot more we can add to this API, but for now this is getting good enough for an MVP. Before declaring it done, let’s add a basic health check endpoint. Head over to Copilot Edits, and send it the following prompt:

Setup CORS configuration for React frontend.

Review the changes, then go ahead and accept them.

With this, you’ve completed the MVP of the API. That means you just created an API with GitHub Copilot!

Some finishing touches

Before declaring this MVP complete, you should add some documentation to the README. Luckily, Copilot Chat helps speed up this process. Open up Copilot Chat and send it the following prompt:

@workspace create a detailed README about the Planventure API

Copilot will generate a README for you, describing how the API works. Hover over the text, select the ... button, and select Insert into New File. Save the file as README.md, and you now have a valid README file for your project. Simple and easy! With this, there’s no reason for anyone to have empty README files in their projects.

https://github.blog/wp-content/uploads/2025/04/readme_copilot.mp4#t=0.001

You should also write some tests and include them in your project before declaring this fully complete, but that’s beyond the scope of this episode. Just remember that it’s something you should do, and you can use Copilot Chat to help you do it! Especially if you use the /tests slash command. Spoiler alert: we’ll be covering this in a future episode!

Your next steps

That was a lot! But, you have now built an entire API and used the power of Copilot to do it. Not only that, but you used Copilot to help create documentation, making it easier for others to pick up, use, and contribute to your project.

Check out the repo so you can build this project from scratch, and be sure to read the README so you know which branch to start from.

Don’t forget that you can use GitHub Copilot for free! If you have any questions, pop them in the GitHub Community thread, and we’ll be sure to respond. Join us for the next part in this series, where we’ll build a full app using this API we created.

Happy coding!

The post GitHub for Beginners: Building a REST API with Copilot appeared first on The GitHub Blog.

How the GitHub CLI can now enable triangular workflows - The GitHub Blog

2025-04-25T16:00:37.000Z

Most developers are familiar with the standard Git workflow. You create a branch, make changes, and push those changes back to the same branch on the main repository. Git calls this a centralized workflow. It’s straightforward and works well for many projects.

However, sometimes you might want to pull changes from a different branch directly into your feature branch to help you keep your branch updated without constantly needing to merge or rebase. However, you’ll still want to push local changes to your own branch. This is where triangular workflows come in.

It’s possible that some of you have already used triangular workflows, even without knowing it. When you fork a repo, contribute to your fork, then open a pull request back to the original repo, you’re working in a triangular workflow. While this can work seamlessly on github.com, the process hasn’t always been seamless with the GitHub CLI.

The GitHub CLI team has recently made improvements (released in v2.71.2) to better support these triangular workflows, ensuring that the gh pr commands work smoothly with your Git configurations. So, whether you’re working on a centralized workflow or a more complex triangular one, the GitHub CLI will be better equipped to handle your needs.

If you’re already familiar with how Git handles triangular workflows, feel free to skip ahead to learn about how to use gh pr commands with triangular workflows. Otherwise, let’s get into the details of how Git and the GitHub CLI have historically differed, and how four-and-a-half years after it was first requested, we have finally unlocked managing pull requests using triangular workflows in the GitHub CLI.

First, a lesson in Git fundamentals

To provide a framework for what we set out to do, it’s important to first understand some Git basics. Git, at its core, is a way to store and catalog changes on a repository and communicate those changes between copies of that repository. This workflow typically looks like the diagram below:

Figure 1: A typical git branch setup

The building blocks of this diagram illustrate two important Git concepts you likely use every day, a ref and push/pull.

Refs

A ref is a reference to a repository and branch. It has two parts: the remote, usually a name like origin or upstream, and the branch. If the remote is the local repository, it is blank. So, in the example above, origin/branch in the purple box is a remote ref, referring to a branch named branch on the repository name origin, while branch in the green box is a local ref, referring to a branch named branch on the local machine.

While working with GitHub, the remote ref is usually the repository you are hosting on GitHub. In the diagram above, you can consider the purple box GitHub and the green box your local machine.

Pushing and pulling

A push and a pull refer to the same action, but from two different perspectives. Whether you are pushing or pulling is determined by whether you are sending or receiving the changes. I can push a commit to your repo, or you can pull that commit from my repo, and the references to that action would be the same.

To disambiguate this, we will refer to different refs as the headRef or baseRef, where the headRef is sending the changes (pushing them) and the baseRef is receiving the changes (pulling them).

Figure 2: Disambiguating headRef and baseRef for push/pull operations

When dealing with a branch, we’ll often refer to the headRef of its pull operations as its pullRef and the baseRef of its push operations as its pushRef. That’s because, in these instances, the working branch is the pull’s baseRef and the push’s headRef, so they’re already disambiguated.

The `@{push}` revision syntax

Turns out, Git has a handy built-in tool for referring to the pushRef for a branch: the @{push} revision syntax. You can usually determine a branch’s pushRef by running the following command:

git rev-parse --abbrev-ref @{push}

This will result in a human-readable ref, like origin/branch, if one can be determined.

Pull Requests

On GitHub, a pull request is a proposal to integrate changes from one ref to another. In particular, they act as a simple “pause” before performing the actual integration operation, often called a merge, when changes are being pushed from ref to another. This pause allows for humans (code reviews) and robots (GitHub Copilot reviews and GitHub Actions workflows) to check the code before the changes are integrated. The name pull request came from this language specifically: You are requesting that a ref pulls your changes into itself.

Figure 3: Demonstrating how GitHub Pull Requests correspond to pushing and pulling

Common Git workflows

Now that you understand the basics, let’s talk about the workflows we typically use with Git every day.

A centralized workflow is how most folks interact with Git and GitHub. In this configuration, any given branch is pushing and pulling from a remote ref with the same branch name. For most of us, this type of configuration is set up by default when we clone a repo and push a branch. It is the situation shown in Figure 1.

In contrast, a triangular workflow pushes to and pulls from different refs. A common use case for this configuration is to pull directly from a remote repository’s default branch into your local feature branch, eliminating the need to run commands like git rebase <default> or git merge <default> on your feature branch to ensure the branch you’re working on is always up to date with the default branch. However, when pushing changes, this configuration will typically push to a remote ref with the same branch name as the feature branch.

Figure 4: juxtaposing centralized workflows from triangular workflows.

We complete the triangle when considering pull requests: the headRef is the pushRef for the local ref and the baseRef is the pullRef for the local branch:

Figure 5: a triangular workflow

We can go one step further and set up triangular workflows using different remotes as well. This most commonly occurs when you’re developing on a fork. In this situation, you usually give the fork and source remotes different names. I’ll use origin for the fork and upstream for the source, as these are common names used in these setups. This functions exactly the same as the triangular workflows above, but the remotes and branches on the pushRef and pullRef are different:

Figure 6: juxtaposing triangular workflows and centralized workflows with different remotes such as with forks

Using a Git configuration file for triangular workflows

There are two primary ways that you can set up a triangular workflow using the Git configuration – typically defined in a `.git/config` or `.gitconfig` file. Before explaining these, let’s take a look at what the relevant bits of a typical configuration look like in a repo’s `.git/config` file for a centralized workflow:

[remote “origin”] 
    url = https://github.com/OWNER/REPO.git 
    fetch = +refs/heads/*:refs/remotes/origin/*  
[branch “default”]
    remote = origin  
    merge = refs/heads/default  
[branch “branch”]
    remote = origin 
    merge = refs/heads/branch

Figure 7: A typical Git configuration setup found in .git/config

The [remote “origin”] part is naming the Git repository located at github.com/OWNER/REPO.git to origin, so we can reference it elsewhere by that name. We can see that reference being used in the specific [branch] configurations for both the default and branch branches in their remote keys. This key, in conjunction with the branch name, typically makes up the branch’s pushRef: in this example, it is origin/branch.

The remote and merge keys are combined to make up the branch’s pullRef: in this example, it is origin/branch.

Setting up a triangular branch workflow

The simplest way to assemble a triangular workflow is to set the branch’s merge key to a different branch name, like so:

[branch “branch”]
    remote = origin
    merge = refs/heads/default

Figure 8: a triangular branch’s Git configuration found in .git/config

This will result in the branch pullRef as origin/default, but pushRef as origin/branch, as shown in Figure 9.

Figure 9: A triangular branch workflow

Setting up a triangular fork workflow

Working with triangular forks requires a bit more customization than triangular branches because we are dealing with multiple remotes. Thus, our remotes in the Git config will look different than the one shown previously in Figure 7:

[remote “upstream”]
    url = https://github.com/ORIGINALOWNER/REPO.git 
    fetch = +refs/heads/*:refs/remotes/upstream/* 
[remote “origin”]
    url = https://github.com/FORKOWNER/REPO.git  
    fetch = +refs/heads/*:refs/remotes/origin/*

Figure 10: a Git configuration for a multi-remote Git setup found in .git/config

Upstream and origin are the most common names used in this construction, so I’ve used them here, but they can be named anything you want¹.

However, toggling a branch’s remote key between upstream and origin won’t actually set up a triangular fork workflow—it will just set up a centralized workflow with either of those remotes, like the centralized workflow shown in Figure 6. Luckily, there are two common Git configuration options to change this behavior.

Setting a branch’s `pushremote`

A branch’s configuration has a key called pushremote that does exactly what the name suggests: configures the remote that the branch will push to. A triangular fork workflow config using pushremote may look like this:

[branch “branch”]
    remote = upstream  
    merge = refs/heads/default  
    pushremote = origin

Figure 11: a triangular fork’s Git config using pushremote found in .git/config

This assembles the triangular fork repo we see in Figure 12. The pullRef is upstream/default, as determined by combining the remote and merge keys, while the pushRef is origin/branch, as determined by combining the pushremote key and the branch name.

Figure 12: A triangular fork workflow

Setting a repo’s `remote.pushDefault`

To configure all branches in a repository to have the same behavior as what you’re seeing in Figure 12, you can instead set the repository’s pushDefault. The config for this is below:

[remote] 
    pushDefault = origin 
[branch “branch”]
    remote = upstream 
    merge = refs/heads/default

Figure 13: a triangular fork’s Git config using remote.pushDefault found in .git/config

This assembles the same triangular fork repo as shown in Figure 12 above, however this time the pushRef is determined by combining the remote.pushDefault key and the branch name, resulting in origin/branch.

When using the branch’s pushremote and the repo’s remote.pushDefault keys together, Git will preferentially resolve the branch’s configuration over the repo’s, so the remote set on pushremote supersedes the remote set on remote.pushDefault.

Updating the `gh pr` command set to reflect Git

Previously, the gh pr command set did not resolve pushRefs and pullRefs in the same way that Git does. This was due to technical design decisions that made this change both difficult and complex. Instead of discussing that complexity—a big enough topic for a whole article in itself—I’m going to focus here on what you can now do with the updated gh pr command set.

If you set up triangular Git workflows in the manner described above, we will automatically resolve gh pr commands in accordance with your Git configuration.

To be slightly more specific, when trying to resolve a pull request for a branch, the GitHub CLI will respect whatever @{push} resolves to first, if it resolves at all. Then it will fall back to respect a branch’s pushremote, and if that isn’t set, finally look for a repo’s remote.pushDefault config settings.

What this means is that the CLI is assuming your branch’s pullRef is the pull request’s baseRef and the branch’s pushRef is the pull requests headRef. In other words, if you’ve configured git pull and git push to work, then gh pr commands should just work.² The diagram below, a general version of Figure 5, demonstrates this nicely:

Figure 14: the triangular workflow supported by the GitHub CLI with respect to a branch’s pullRef and pushRef. This is the generalized version of Figure 5

Conclusion

We’re constantly working to improve the GitHub CLI, and we’d like the behavior of the GitHub CLI to reasonably reflect the behavior of Git. This was a team effort—everyone contributed to understanding, reviewing, and testing the code to enable this enhanced gh pr command set functionality.

It also couldn’t have happened without the support of our contributors, so we extend our thanks to them:

@Frederick888 for opening the original pull request
@benknoble for his support with pull request review and feedback
@phil-blain for highlighting the configurations we’ve talked about here on the original issue
@neutrinoceros and @rd-yan-farba for reporting a couple of bugs that the team fixed in v2.66.1
@pdunnavant for reporting the bug that we fixed in v2.71.1
@cs278 for reporting the bug that we fixed in v2.71.2.

CLI native support for triangular workflows was 4.5 years in the making, and we’re proud to have been able to provide this update for the community.

The GitHub CLI Team
@andyfeller, @babakks, @bagtoad, @jtmcg, @mxie, @RyanHecht, and @williammartin

Some commands in gh are opinionated about remote names and will resolve remotes in this order: upstream, github, origin, <other remotes unstably sorted>. There is a convenience command you can run to supersede this:* gh repo set-default [<repository>] to override the default behavior above and preferentially resolve <repository> as the default remote repo. ↩
If you find a git configuration that doesn’t work, please open an issue in the OSS repo so we can fix it. ↩

The post How the GitHub CLI can now enable triangular workflows appeared first on The GitHub Blog.

A guide to deciding what AI model to use in GitHub Copilot - The GitHub Blog

2025-04-24T16:00:51.000Z

To ensure that you have access to the best technology available, we’re continuously adding support for new models to GitHub Copilot. That being said, we know it can be hard to keep up with so many new models being released all the time.

All of this raises an obvious question: Which model should you use?

You can read our recent blog post for an overview of the models currently available in Copilot and their strengths, or check out our documentation for a deep dive comparing different models and tasks. But the AI landscape moves quickly. In this article we’ll explore a framework—including a few strategies—for evaluating whether any given AI model is a good fit for your use, even as new models continue to appear at a rapid pace.

It’s hard to go wrong with our base model, which has been fine-tuned specifically for programming-related tasks. But depending on what you’re working on, you likely have varying needs and preferences. There’s no single “best” model. Some may favor a more verbose model for chat, while others prefer a terse one, for example.

We spoke with several developers about their model selection process. Keep reading to discover how to apply their strategies to your own needs.

💡 Watch the video below for tips on prompt engineering to get the best results.

Why use multiple models?

There’s no reason you have to pick one model and stick with it. Since you can easily switch between models for both chat and code completion with GitHub Copilot, you can use different models for different use cases.

It's kind of like dogfooding your own stack: You won’t know if it really fits your workflow until you've shipped some real code with it.

- Anand Chowdhary, FirstQuadrant CTO and co-founder

Chat vs. code completion

Using one model for chat and another for autocomplete is one of the most common patterns we see among developers. Generally, developers prefer autocompletion models because they’re fast and responsive, which they need if they’re looking for suggestions as they think and type. Developers are more tolerant of latency in chat, when they’re in more of an exploratory state of mind (like considering a complex refactoring job, for instance).

Reasoning models for certain programming tasks

Reasoning models like OpenAI o1 often respond slower than traditional LLMs such as GPT-4o or Claude Sonnet 3.5. That’s in large part because these models break a prompt down into parts and consider multiple approaches to a problem. That introduces latency in their response times, but makes them more effective at completing complex tasks. Many developers prefer these more deliberative models for particular tasks.

For instance, Fatih Kadir Akın, a developer relations manager, uses o1 when starting new projects from scratch. “Reasoning models better ‘understand’ my vision and create more structured projects than non-reasoning models,” he explains.

FirstQuadrant CTO and co-founder Anand Chowdhary favors reasoning models for large-scale code refactoring jobs. “A model that rewrites complex backend code without careful reasoning is rarely accurate the first time,” he says. “Seeing the thought process also helps me understand the changes.”

When creating technical interview questions for her newsletter, GitHub Senior Director of Developer Advocacy, Cassidy Williams mixes models for certain tasks. When she writes a question, she uses GPT-4o to refine the prose, and then Claude 3.7 Sonnet Thinking to verify code accuracy. “Reasoning models help ensure technical correctness because of their multi-step process,” she says. “If they initially get something wrong, they often correct themselves in later steps so the final answer is more accurate.”

There’s some subjectivity, but I compare model output based on the code structure, patterns, comments, and adherence to best practices.

- Portilla Edo, cloud infrastructure engineering lead

What to look for in a new AI model

Let’s say a new model just dropped and you’re ready to try it out. Here are a few things to consider before making it your new go-to.

Recentness

Different models use different training data. That means one model might have more recent data than another, and therefore might be trained on new versions of the programming languages, frameworks, and libraries you use.

“When I’m trying out a new model, one of the first things I do is check how up to date it is,” says Xavier Portilla Edo, a cloud infrastructure engineering lead. He typically does this by creating a project manifest file for the project to see what version numbers Copilot autocomplete suggests. “If the versions are quite old, I’ll move on,” he says.

Speed and responsiveness

As mentioned, developers tend to tolerate more latency in a chat than in autocomplete. But responsiveness is still important in chat. “I enjoy bouncing ideas off a model and getting feedback,” says Rishab Kumar, a staff developer evangelist at Twilio. “For that type of interaction, I need fast responses so I can stay in the flow.”

Accuracy

Naturally, you need to evaluate which models produce the best code. “There’s some subjectivity, but I compare model output based on the code structure, patterns, comments, and adherence to best practices,” Portilla Edo says. “I also look at how readable and maintainable the code is—does it follow naming conventions? Is it modular? Are the comments helpful or just restating what the code does? These are all signals of quality that go beyond whether the code simply runs.”

How to test an AI model in your workflow

OK, so now you know what to look for in a model. But how do you actually evaluate it for responsiveness and correctness? You use it, of course.

Start with a simple app

Akın will generally start with a simple todo app written in vanilla JavaScript. “I just check the code, and how well it’s structured,” he says. Similarly, Kumar will start with a websocket server in Python. The idea is to start with something that you understand well enough to evaluate, and then layer on more complexity. “Eventually I’ll see if it can build something in 3D using 3js,” Akın says.

Portilla Edo starts by prompting a new model he wants to evaluate in Copilot Chat. “I usually ask it for simple things, like a function in Go, or a simple HTML file,” he says. Then he moves on to autocompletion to see how the model performs there.

Use it as a “daily driver” for a while

Chowdhary prefers to just jump in and start using a model. “When a new model drops, I swap it into my workflow as my daily driver and just live with it for a bit,” he says. “Available benchmarks and tests only tell you part of the story. I think the real test is seeing if it actually improves your day to day.”

For example, he checks to see if it actually speeds up his debugging jobs or produces cleaner refactors. “It’s kind of like dogfooding your own stack: You won’t know if it really fits your workflow until you’ve shipped some real code with it,” he says. “After evaluating it for a bit, I decide whether to stick with the new model or revert to my previous choice.”

Take this with you

What just about everyone agrees on is that the best way to evaluate a model is to use it.

The important thing is to keep learning. “You don’t need to be switching models all the time, but it’s important to know what’s going on,” Chowdhary says. “The state of the art is moving quickly. It’s easy to get left behind.”

Additional resources

Learn more about AI models.

The post A guide to deciding what AI model to use in GitHub Copilot appeared first on The GitHub Blog.

Achieve real-time interaction: Build with the Live API - Google Developers Blog

2025-04-23T21:24:02.000Z

Explore real world applications for the Live API for Gemini models, now updated to include enhanced features for real-time audio, video, and text processing, improved session management, control over interactions, and richer output options.

Get ready for Google I/O: Program lineup revealed - Google Developers Blog

2025-04-23T17:04:04.000Z

Google I/O's agenda is live, with keynotes and sessions scheduled for May 20-21, focusing on AI advancements, Android development, and web technologies. Register now to explore the full program, join us during the event for livestreams, on-demand sessions, and codelabs.

From prompt to production: Building a landing page with Copilot agent mode - The GitHub Blog

2025-04-23T16:06:05.000Z

GitHub Copilot has quickly become an integral part of how I build. Whether I’m exploring new ideas or scaffolding full pages, using Copilot’s agent mode in my IDE helps me move faster—and more confidently—through each step of the development process.

GitHub Copilot agent mode is an interactive chat experience built right into your IDE that turns Copilot into an active participant in your development workflow. After you give it a prompt, agent mode streamlines complex coding tasks by autonomously iterating on its own code, identifying and fixing errors, suggesting and executing terminal commands, and resolving runtime issues with self-healing capabilities.

And here’s the best part: You can attach images, reference files, and give natural language instructions, and Copilot will generate and modify code directly in your project!

In this post, I’ll walk you through how I built a developer-focused landing page—from product requirements to code—using GitHub Copilot agent mode and the Claude 3.5 Sonnet model. This kind of build could easily take a few hours if I did it all by myself. But with Copilot, I had a working prototype in under 30 minutes! You’ll see how I used design artifacts, inline chat, and Copilot’s awareness of context to go from idea → design → code, with minimal friction.

You can also watch the full build in the video above!

Designing with AI: From PRD to UI

Before I wrote a single line of code, I needed a basic product vision. I started by using GitHub Copilot on GitHub.com to generate a lightweight product requirements document (PRD) using GPT-4o. Here was my prompt:

> “Describe a landing page for developers in simple terms.”

Copilot returned a structured but simple outline of a PRD for a developer-focused landing page. I then passed this PRD into Claude 3.5 Sonnet and asked it to generate a design based on that prompt.

Claude gave me a clean, organized layout with common landing page sections: a hero, feature list, API examples, a dashboard preview, and more. This was more than enough for me to get started.

You can explore the full design that Claude built here; it’s pretty cool.

Setting up the project

For the tech stack, I chose Astro because of its performance and flexibility. I paired it with Tailwind CSS and React for styling and component architecture. I started in a blank directory and ran the following commands:

npm create astro@latest
npx astro add react
npx astro add tailwind

I initialized the project, configured Tailwind, and opened it in VS Code with GitHub Copilot agent mode enabled (learn how to enable it with our docs!). Once the server was running, I was ready to start building.

Building section by section with Copilot agent mode

Copilot agent mode really shines when translating visual designs into production-ready code because it understands both image and code context in your project. By attaching a screenshot and specifying which file to edit, I could prompt it to scaffold new components, update layout structure, and even apply Tailwind styles—all without switching tabs or writing boilerplate manually.

For our project here, this meant I could take screenshots of each section from Claude’s design and drop them directly into Copilot’s context window.

💡 Pro tip: When building from a visual design like this, I recommend working on one section at a time. This not only keeps the context manageable for the model, but also makes it easier to debug if something goes off track. You’ll know exactly where to look!

I opened index.astro, attached the design screenshot, and typed the following prompt:

> “Update index.astro to reflect the attached design. Add a new navbar and hero section to start the landing page.”

Copilot agent mode then returned the following:

Created Navbar.astro and Hero.astro
Updated index.astro to render them
Applied Tailwind styling based on the visual layout

And here’s what I got:

https://github.blog/wp-content/uploads/2025/04/dev-flow-final-landing.mp4#t=0.001

Now, this is beautiful! Though it doesn’t have the image on the right per the design, it did a very good job of getting the initial design down. We’ll go back in later to update the section to be exactly what we want.

Commit early and often

💡 Pro tip: When building with AI tools, commit early and often. I’ve seen too many folks lose progress when a prompt goes sideways.

And in case you didn’t know, GitHub Copilot can help here too. After staging your changes in the Source Control panel, click the ✨ sparkles icon to automatically generate a commit message. It’s a small step that can save you a lot of time (and heartache).

https://github.blog/wp-content/uploads/2025/04/dev-flow-commit-code.mp4#t=0.001

Improve accuracy with Copilot custom instructions

One of the best ways to improve the quality of GitHub Copilot’s suggestions—especially in multi-file projects—is by providing it with custom instructions. These are short, structured notes that describe your tech stack, project structure, and any conventions or tools you’re using.

Instead of repeatedly adding this contextual detail to your chat questions, you can create a file in your repository that automatically adds this information for you. The additional information won’t be displayed in the chat, but is available to Copilot—allowing it to generate higher-quality responses.

To give Copilot better context, I created a CopilotInstructions.md file describing my tech stack:

Astro v5
Tailwind CSS v4
React
TypeScript

When Copilot agent mode referenced this file when making suggestions, I noticed the results became more accurate and aligned with my setup.

Here’s what some of the file looked like:

# GitHub Copilot Project Instructions

## Project Overview
This is an Astro project that uses React components and Tailwind CSS for styling. When making suggestions, please consider the following framework-specific details and conventions.

## Tech Stack
- Astro v5.x
- React as UI library
- Tailwind CSS for styling (v4.x)
- TypeScript for type safety

## Project Structure
```
├── src/
│   ├── components/     # React and Astro components
│   ├── layouts/        # Astro layout components
│   ├── pages/          # Astro pages and routes
│   ├── styles/         # Global styles
│   └── utils/          # Utility functions
├── public/             # Static assets
└── astro.config.mjs    # Astro configuration
```

## Component Conventions

### Astro Components
- Use `.astro` extension
- Follow kebab-case for filenames
- Example structure:

```astro
---
// Imports and props
interface Props {
  title: string;
}

const { title } = Astro.props;
---

<div class="component-wrapper">
  <h1>{title}</h1>
  <slot />
</div>

<style>
  /* Scoped styles if needed */
</style>
```

You can explore the full instructions file in my repo, along with the full code, setup instructions, and a link to the deployed landing page.

Iterating on your designs by prompting Copilot

I then repeated the same process to build each new section. Here’s what this looked like in practice:

“Built by Developers” section

> “Add a new section to the landing page called ‘By Developers’ and follow the attached design.”

Copilot generated a reusable component with feature cards structured in a Tailwind-styled grid.

“API development” section

> “Add the API development section based on the design.”

This section featured interactive code samples in tabs. Copilot interpreted that from the screenshot and added UI logic to switch between examples—without me asking.

https://github.blog/wp-content/uploads/2025/04/api-design-section.mp4#t=0.001

“Dashboard preview” section

> “Now add the dashboard management section on the landing page based on the design.”

I uploaded a screenshot of my editor as a placeholder image, and Copilot added it seamlessly to the new component.

It’s so amazing how fast we’re building this landing page. Look at the progress we’ve already made!

Smart suggestions, fast results

Even with sections like “Trusted by Developers” and “Try it Yourself,” Copilot created placeholder images, added semantic HTML, and applied Tailwind styling—all based on a single image and prompt. 🤯

When I updated the final hero section to match the layout more closely, Copilot flagged and fixed TypeScript issues without being prompted.

That might sound small, but it’s a big deal. It means Copilot agent mode wasn’t just taking instructions—it was actively understanding my codebase, looking at my terminal, identifying problems, and resolving them in real time. This reduced my need to context switch, so I could focus on shipping!

This wasn’t just a series of generated components. It was a fully structured, landing page built with modern best practices baked in. And I didn’t have to build it alone!

Wrapping up:

With GitHub Copilot agent mode and Claude working together, I was able to:

Generate a usable PRD and design mockup with a single prompt
Build a responsive Astro-based landing page in less than thirty minutes
Scaffold, test, and iterate on each section with minimal manual coding
Use natural language to stay in the flow as I developed

https://github.blog/wp-content/uploads/2025/04/dev-flow-final-landing_64d2b2.mp4#t=0.001

What’s next?

To complete this project, I updated the README with a clear project structure, added instructions for getting started, and staged it for deployment. From here, you can:

Deploy it with GitHub Pages, Netlify, or your host of choice
Set up GitHub Actions for CI/CD
Add unit tests or accessibility checks
Replace placeholder content with real data (like logos, dashboard, and profile images)
Add new pages based on the Navbar

Want to explore it yourself?

Take this with you

AI tools like GitHub Copilot agent mode are transforming how we build, but like any tool, their power depends on how well we use them. Adding context, being explicit, and committing often made building this web page smooth and successful.

If you’re thinking about building with GitHub Copilot, give this workflow a try:

Start with a PRD using Copilot on GitHub.com
Generate a design from your PRD with Claude
Use Copilot Agent in your IDE to code it, step by step.

Until next time, happy coding!

The post From prompt to production: Building a landing page with Copilot agent mode appeared first on The GitHub Blog.

Exploring GitHub CLI: How to interact with GitHub’s GraphQL API endpoint - The GitHub Blog

2025-04-22T16:00:01.000Z

You might have heard of the GitHub CLI and all of the awesome things you can do with it. However, one of its hidden superpowers is the ability to execute complex queries and mutations through GitHub’s GraphQL API. This post will walk you through what GitHub’s GraphQL API endpoint is and how to query it with the GitHub CLI.

What is GraphQL?

Let’s start with the basics: GraphQL is a query language for APIs and a runtime for executing those queries against your data. Unlike traditional REST APIs that provide fixed data structures from predefined endpoints, GraphQL allows clients to request exactly the data they need in a single request. This single-request approach reduces network overhead, speeds up application performance, and simplifies client-side logic by eliminating the need to reconcile multiple API responses—a capability that has been openly available since the specification was open sourced in 2015.

GraphQL operations come in two primary types: queries and mutations. Queries are read-only operations that retrieve data without making any changes—similar to GET requests in REST. Mutations, on the other hand, are used to modify server-side data (create, update, or delete)—comparable to POST, PATCH, PUT, and DELETE in REST APIs. This clear separation between reading and writing operations makes GraphQL interactions predictable while maintaining the flexibility to precisely specify what data should be returned after a change is made.

How is GraphQL used at GitHub?

GitHub implemented GraphQL in 2016 to address limitations of RESTful APIs. This adoption has significantly enhanced the developer experience when working with GitHub data. With the GraphQL endpoint, you can retrieve a repository’s issues, its labels, assignees, and comments with a single GraphQL query. Using our REST APIs, this would have otherwise taken several sets of nested calls.

Some GitHub data and operations are only accessible through the GraphQL API (such as discussions, projects, and some enterprise settings), others exclusively through REST APIs (such as querying actions workflows, runners, or logs), and some using either endpoint (such as repositories, issues, pull requests, and user information). GitHub’s GraphQL endpoint is accessible at api.github.com/graphql and you can explore the full schema in our GraphQL documentation or through the interactive GraphQL Explorer.

A key consideration when choosing between the REST API and the GraphQL API is how the rate limits are calculated. As a quick summary for how this is implemented:

REST API: Limited by number of requests (typically 5,000 requests per hour for authenticated users and up to 15,000 for GitHub Apps installed in an Enterprise)
GraphQL API: Limited by “points” (typically 5,000 points per hour for authenticated users but can go up to 10,000-12,500 points per hour for GitHub Apps)

Each GraphQL query costs at least one point, but the cost increases based on the complexity of your query (number of nodes requested, connections traversed, etc.). The GraphQL API provides a rateLimit field you can include in your queries to check your current limit status.

For scenarios where you need to fetch related data that would otherwise require multiple REST calls, GraphQL is often more rate limit friendly because:

One complex GraphQL query might cost 5-10 points but replace 5-10 separate REST API calls.
You avoid “over-fetching” data you don’t need, which indirectly helps with rate limits.
The GraphQL API allows for more granular field selection, potentially reducing the complexity and point cost.

However, poorly optimized GraphQL queries that request large amounts of nested data could potentially use up your rate limit faster than equivalent REST requests—and quickly run into secondary rate limit issues.

A quick rule of thumb on deciding between which to use:

For querying relational objects, such as GitHub Projects and their issues, GraphQL is often more effective, especially if it’s a discrete number of items.
For bulk data of one type or single data points, such as pulling in a list of repository names in an organization, the REST API is often preferred.

Sometimes there isn’t a right or wrong answer; so as long as the object exists, try one out!

Why use GitHub CLI for GraphQL?

While many developers start with GitHub’s GraphQL Explorer on the web, curl, or other API querying tools, there’s a more streamlined approach: using built-in GraphQL support in the GitHub CLI. Before diving into the how-to, let’s understand why GitHub CLI is often my go-to tool for GraphQL queries and mutations:

Authentication is handled automatically: No need to manage personal access tokens manually.
Streamlined syntax: Simpler than crafting curl commands.
Local development friendly: Run queries and mutations right from your terminal.
JSON processing: Built-in options for filtering and formatting results.
Pagination support: Ability to work with cursor-based pagination in GraphQL responses.
Consistent experience: Same tool you’re likely using for other GitHub tasks.

How to get started with `gh api graphql`

First, ensure you have GitHub CLI installed and authenticated with gh auth login. The basic syntax for making a GraphQL query with gh api graphql is:

gh api graphql -H X-Github-Next-Global-ID:1 -f query='
  query {
    viewer {
      login
      name
      bio
    }
  }
'

This simple query returns your GitHub username, the name you have defined in your profile, and your bio. The -f flag defines form variables, with query= being the GraphQL query itself.

Here’s our example output:

{
  "data": {
    "viewer": {
      "login": "joshjohanning",
      "name": "Josh Johanning",
      "bio": "DevOps Architect | GitHub"
    }
  }
}

Running queries and mutations

Basic query example

Let’s try something more practical—fetching information about a repository. To get started, we’ll use the following query:

gh api graphql -H X-Github-Next-Global-ID:1 -f query='
  query($owner:String!, $repo:String!) {
    repository(owner:$owner, name:$repo) {
      name
      description
      id
      stargazerCount
      forkCount
      issues(states:OPEN) {
        totalCount
      }
    }
  }
' -F owner=octocat -F repo=Hello-World

The -F flag sets variable values that are referenced in the query with $variable.

Here’s our example output:

{
  "data": {
    "repository": {
      "name": "Hello-World",
      "description": "My first repository on GitHub!",
      "id": "R_kgDOABPHjQ",
      "stargazerCount": 2894,
      "forkCount": 2843,
      "issues": {
        "totalCount": 1055
      }
    }
  }
}

💡 Tip: The -H X-Github-Next-Global-ID:1 parameter sets an HTTP header that instructs GitHub’s GraphQL API to use the new global node ID format rather than the legacy format. While your query will function without this header, including it prevents deprecation warnings when referencing node IDs (such as when passing repository.ID in subsequent operations). GitHub recommends adopting this format for all new integrations to ensure long-term compatibility.

Running mutations

Mutations work similarly. Here’s how to create a new issue:

gh api graphql -H X-Github-Next-Global-ID:1 -f query='
  mutation($repositoryId:ID!, $title:String!, $body:String) {
    createIssue(input:{repositoryId:$repositoryId, title:$title, body:$body}) {
      issue {
        url
        number
        title
        body
        state
      }
    }
  }
' -F repositoryId="R_kgDOABPHjQ" -F title="Creating issue with GraphQL" -F body="Issue body created via GraphQL\!"

Make sure to update the repositoryId parameter with the actual repository’s GraphQL ID (an example of returning a repository’s ID is shown in the basic query above!).

Here’s our example output:

{
  "data": {
    "createIssue": {
      "issue": {
        "url": "https://github.com/octocat/Hello-World/issues/3706",
        "number": 3706,
        "title": "Creating issue with GraphQL",
        "body": "Issue body created via GraphQL!",
        "state": "OPEN"
      }
    }
  }
}

Filtering GraphQL results

GitHub CLI supports JQ-style filtering for extracting specific parts of the response, which is invaluable when you need to parse just the repository names or URLs from a query for use in automation scripts. Here is an example of using the --jq flag:

gh api graphql -H X-Github-Next-Global-ID:1 -f query='
  query($owner:String!, $repo:String!) {
    repository(owner:$owner, name:$repo) {
      issues(first:3, states:OPEN) {
        nodes {
          number
          title
          url
        }
      }
    }
  }
' -F owner=octocat -F repo=Hello-World --jq '.data.repository.issues.nodes[]'

The --jq flag accepts JQ expressions to process JSON output. This query returns just the array of issues, without the surrounding GraphQL response structure.

Here’s our example output:

{
  "number": 26,
  "title": "test issue",
  "url": "https://github.com/octocat/Hello-World/issues/26"
}
{
  "number": 27,
  "title": "just for test",
  "url": "https://github.com/octocat/Hello-World/issues/27"
}
{
  "number": 28,
  "title": "Test",
  "url": "https://github.com/octocat/Hello-World/issues/28"
}

We could have modified the --jq flag to just return the issue URLs, like so:

gh api graphql -H X-Github-Next-Global-ID:1 -f query='
  query($owner:String!, $repo:String!) {
    repository(owner:$owner, name:$repo) {
      issues(first:3, states:OPEN) {
        nodes {
          number
          title
          url
        }
      }
    }
  }
' -F owner=octocat -F repo=Hello-World --jq '.data.repository.issues.nodes[].url'

Here’s our example output:

https://github.com/octocat/Hello-World/issues/26
https://github.com/octocat/Hello-World/issues/27
https://github.com/octocat/Hello-World/issues/28

Handling pagination

GitHub’s GraphQL API limits results to a maximum of 100 items per page, which means you’ll need pagination to retrieve larger datasets.

Pagination in GraphQL works by returning a “cursor” with each page of results, which acts as a pointer to where the next set of results should begin. When you request the next page, you provide this cursor to indicate where to start.

The easiest way to handle this pagination in the GitHub CLI is with the --paginate flag, which automatically collects all pages of results for you by managing these cursors behind the scenes. Here’s what that looks like in a query:

gh api graphql --paginate -H X-Github-Next-Global-ID:1 -f query='
  query($owner:String!, $repo:String!, $endCursor:String) {
    repository(owner:$owner, name:$repo) {
      issues(first:100, after:$endCursor, states:OPEN, orderBy:{field:CREATED_AT, direction:DESC}) {
        pageInfo {
          hasNextPage
          endCursor
        }
        nodes {
          number
          title
          createdAt
        }
      }
    }
  }
' -F owner=octocat -F repo=Hello-World

The pageInfo object with its hasNextPage and endCursor fields is essential for pagination. When you use the --paginate flag, GitHub CLI automatically uses these fields to fetch all available pages for your query, combining the results into a single response.

Here’s our example output:

{
  "data": {
    "repository": {
      "issues": {
        "pageInfo": {
          "hasNextPage": true,
          "endCursor": "Y3Vyc29yOnYyOpK5MjAyNC0xMi0zMFQxNDo0ODo0NC0wNjowMM6kunD3"
        },
        "nodes": [
          {
            "number": 3708,
            "title": "Creating issue with GraphQL once more",
            "createdAt": "2025-04-02T18:15:11Z",
            "author": {
              "login": "joshjohanning"
            }
          },
          {
            "number": 3707,
            "title": "Creating issue with GraphQL again",
            "createdAt": "2025-04-02T18:15:02Z",
            "author": {
              "login": "joshjohanning"
            }
          },
          {
            "number": 3706,
            "title": "Creating issue with GraphQL",
            "createdAt": "2025-04-02T18:14:37Z",
            "author": {
              "login": "joshjohanning"
            }
          },
          … and so on
        ]
      }
    }
  }
}

This approach works great for moderate amounts of data, but keep in mind that GitHub’s GraphQL API has rate limits, so extremely large queries might need to implement delays between requests.

💡 Important limitation: The --paginate flag can only handle pagination for a single connection at a time. For example, when listing repository issues as shown above, it can paginate through all issues, but cannot simultaneously paginate through each issue’s comments. For nested pagination, you’ll need to implement custom logic.

Building complex scripts: Chaining GraphQL queries together

When working with GitHub’s GraphQL API, you often need to connect multiple queries to accomplish a complex task. Let’s look at how to chain GraphQL calls together using the GitHub CLI:

ISSUE_ID=$(gh api graphql -H X-Github-Next-Global-ID:1 -f query='
  query($owner: String!, $repo: String!, $issue_number: Int!) {
    repository(owner: $owner, name: $repo) {
      issue(number: $issue_number) {
        id
      }
    }
  }
' -F owner=joshjohanning -F repo=graphql-fun -F issue_number=1 --jq '.data.repository.issue.id') 
gh api graphql -H GraphQL-Features:sub_issues -H X-Github-Next-Global-ID:1 -f query='
query($issueId: ID!) {
  node(id: $issueId) {
    ... on Issue {
      subIssuesSummary {
        total
        completed
        percentCompleted
      }
    }
  }
}' -F issueId="$ISSUE_ID"

Here’s what this shell script is doing:

The first query captures an issue’s ID using the repository name and issue number
The --jq flag extracts just the ID value and stores it in a variable
The second query passes this ID to retrieve a summary of sub-issues

Here’s our example output:

{
  "data": {
    "node": {
      "subIssuesSummary": {
        "total": 3,
        "completed": 1,
        "percentCompleted": 33
      }
    }
  }
}

Take this with you

The gh api graphql command provides a convenient way to interact with GitHub’s GraphQL API directly from your terminal. It eliminates the need for token management, simplifies query syntax and formatting, and handles basic pagination that would otherwise be complex to implement. Whether you’re running complex queries or simple mutations, this approach offers a streamlined developer experience.

Next time you need to interact with GitHub’s GraphQL API, skip the GraphQL Explorer on the web and try the GitHub CLI approach. It might just become your preferred method for working with GitHub’s powerful GraphQL API capabilities.

The post Exploring GitHub CLI: How to interact with GitHub’s GraphQL API endpoint appeared first on The GitHub Blog.

Racing into 2025 with new GitHub Innovation Graph data - The GitHub Blog

2025-04-21T17:00:13.000Z

We launched the GitHub Innovation Graph to give developers, researchers, and policymakers an easy way to analyze trends in public software collaboration activity around the world. With today’s quarterly¹ release, updated through December 2024, we now have five full years of data.

To help us celebrate, we’ve created some animated bar charts showcasing the growth in developers and pushes of some of the top economies around the world over time. Enjoy!

Animated bar charts

https://github.blog/wp-content/uploads/2025/04/bar_chart_race_global_with_eu_git_pushes_desktop.mp4#t=0.001

What a photo finish! The European Union surpassing the United States in cumulative git pushes was certainly a highlight, but we’d also note the significant movements of Brazil and Korea in climbing up the rankings.

https://github.blog/wp-content/uploads/2025/04/bar_chart_race_global_with_eu_repositories_desktop.mp4#t=0.001

Another close race, this time showing India outpacing the European Union in repositories between Q2 and Q3 2024.

https://github.blog/wp-content/uploads/2025/04/bar_chart_race_apac_developers_desktop.mp4#t=0.001

Zooming into economies in APAC, we can appreciate the speed of developer growth in India, more than quadrupling in just 5 years.

https://github.blog/wp-content/uploads/2025/04/bar_chart_race_emea_developers_desktop.mp4#t=0.001

Flying over to EMEA, we saw very impressive growth from Nigeria, which rose up from rank 20 in Q1 2020 to rank 11 in Q4 2024.

https://github.blog/wp-content/uploads/2025/04/bar_chart_race_latam_developers_desktop.mp4#t=0.001

Finally, in LATAM, it was exciting to see how close most of the economies are in developer counts (with the exception of Brazil), with frequent back-and-forth swaps in rankings between economies like Argentina and Colombia, or Guatemala and Bolivia.

Want to explore more? Dive into the datasets yourself. We can’t wait to check out what you build.

Global line charts

We’ve also made a feature update that will enable you to quickly understand the global scale of some of the metrics we publish, including the numbers of public git pushes, repositories, developers, and organizations on GitHub worldwide.

Simply follow the installation steps for our newly released GitHub MCP Server, and you’ll be able to prompt GitHub Copilot in agent mode within VS Code to retrieve the CSVs from the data repo using the get_file_contents tool. Then, you can have the agent sum up the latest values for you.

Afterward, you can double-check its results with these handy charts that we’ve added to their respective global metrics pages for git pushes, repositories, developers, and organizations. Check them out below.

Click to view slideshow.

The GitHub Innovation Graph reports metrics according to calendar year quarters, which correspond to the following: Q1: January 1 to March 31; Q2: April 1 to June 30; July 1 to September 30; and Q4: October 1 to December 31. ↩

The post Racing into 2025 with new GitHub Innovation Graph data appeared first on The GitHub Blog.

How to take climate action with your code - The GitHub Blog

2025-04-21T13:00:35.000Z

Climate change is one of the most pressing issues of this century. We are working with developers to leverage technology to create a greener world. So, this Earth Day, we’re excited to launch the Climate Action Plan for Developers.

We’ve curated tools and projects to help you kick-start your climate action journey and contribute to achieving net zero carbon emissions. Explore over 60,000 green software and climate-focused repositories on GitHub.

Not sure where to start? Take a look below at a few highlights that can help you start to green your code today.

🚀 Speed & Scale

Speed & Scale is a global initiative to move leaders to act on the climate crisis. Their team has developed a net zero action plan, with 10 objectives and 49 key results that track yearly progress.

Learn about their action plan

⚡️ Electricity Maps

Electricity Maps is the leading electricity grid API, offering a single source for accessing carbon intensity and energy mix globally. As a developer you can go beyond just viewing the maps to pull data from their API, download data files, and even contribute to their open source project.

Access the Electricity Maps API

🖥️ CodeCarbon

CodeCarbon is a lightweight software package that allows for integration into any Python project to track and reduce CO2 emissions from your computing. Get started with using the software package and check out the opportunities to help support this open source project.

Get started with the software package

🌳 ClimateTriage, by OpenSustain.Tech

ClimateTriage helps developers discover a meaningful way to contribute to open source projects focused on climate technology and sustainability. Harness the power of open source collaboration to tackle environmental challenges such as climate change, clean energy, biodiversity, and natural resource conservation. Whether you’re an experienced developer, a scientist, or a newcomer looking to contribute, connect you with opportunities to use your skills to create a sustainable future.

Get started with a Good First Issue

💪 Use GitHub Copilot and CodeCarbon for greener code

Computational tasks, especially in AI, have a growing carbon footprint. Learn how CodeCarbon, an open-source Python library, helps measure CO2 emissions from your code. Together with GitHub Copilot, integrate CodeCarbon into your projects, allowing you to track energy use and optimize for sustainability.

Get started with GitHub Copilot for free today

Learn more about how you can take climate action today.

The post How to take climate action with your code appeared first on The GitHub Blog.

How to make your images in Markdown on GitHub adjust for dark mode and light mode - The GitHub Blog

2025-04-18T19:30:46.000Z

GitHub supports dark mode and light mode, and as developers, we can make our README images look great in both themes. Here’s a quick guide to using the <picture> element in your GitHub Markdown files to dynamically switch images based on the user’s color scheme.

When developers switch to GitHub’s dark mode (or vice versa), standard images can look out of place, with bright backgrounds or clashing colors.

Instead of forcing a one-size-fits-all image, you can tailor your visuals to blend seamlessly with the theme. It’s a small change, but it can make your project look much more polished.

One snippet, two themes!

Here’s the magic snippet you can copy into your README (or any Markdown file):

<picture>
  <source media="(prefers-color-scheme: dark)" srcset="dark-mode-image.png">
  <source media="(prefers-color-scheme: light)" srcset="light-mode-image.png">
  <img alt="Fallback image description" src="default-image.png">
</picture>

Now, we say it’s magic, but let’s take a peek behind the curtain to show how it works:

The <picture> tag lets you define multiple image sources for different scenarios.
The <source media="..."> attribute matches the user’s color scheme.
- When media="(prefers-color-scheme: dark)", the browser loads the srcset image when GitHub is in dark mode.
- Similarly, when media="(prefers-color-scheme: light)", the browser loads the srcset image when GitHub is in light mode.
If the browser doesn’t support the <picture> element, or the user’s system doesn’t match any defined media queries, the fallback <img> tag will be used.

You can use this approach in your repo README files, documentation hosted on GitHub, and any other Markdown files rendered on GitHub.com!

Demo

What’s better than a demo to help you get started? Here’s what this looks like in practice:

https://github.blog/wp-content/uploads/2025/04/Toggle-Dark-and-Light-Mode-on-GitHub-.mp4#t=0.001

The post How to make your images in Markdown on GitHub adjust for dark mode and light mode appeared first on The GitHub Blog.

Cracking the code: How to wow the acceptance committee at your next tech event - The GitHub Blog

2025-04-18T16:48:20.000Z

GitHub Universe returns to San Francisco on October 28 and 29—bringing together the builders, dreamers, and changemakers shaping the future of software. From first-time speakers with big ideas to DevRel pros with demos to share and business leaders rethinking workflows with AI, we believe that a diverse range of voices belong on our stage.

But writing a compelling conference session submission can feel like decoding a complex algorithm. What makes your idea stand out? How do you grab the content committee’s attention? And what if you’ve never done this before?

Good news: we’ve cracked the code, and we’re sharing it with you.

Here are four proven tips to help you put together a proposal that’s clear, compelling, and uniquely you.

Apply to speak or nominate a speaker to take the stage at GitHub Universe by Friday, May 2 at 11:59 pm PT to be considered.

1. Find something you’re truly passionate about 💡

Here’s the truth: passion is magnetic. If you’re excited about your topic, it shows. It pulses through your proposal, powers your delivery onstage, and pulls in your audience—content committee included.

Instead of chasing the latest trends, talk about something that lights you up. Maybe it’s a story from building an open source project in your off-hours. Maybe it’s how your team shipped something new using GitHub Copilot. Or maybe it’s the unexpected way you quickly scaled developer experience across a global org. Your unique perspective is your superpower.

Content committees can sense authenticity. They’re not just looking for polished buzzwords. They’re looking for people who care deeply and can teach others something meaningful.

🎤 Pro tip: If it’s a topic you’d talk about over lunch with a teammate or geek out about on a podcast, it’s probably a great fit.

2. Write a title they can’t ignore ✍️

Think of your session title like an email subject line—it’s your chance to make a strong first impression, and it needs to do the heavy lifting for you. A strong title shouldn’t just sound good. It should clearly communicate what your talk is about and why it matters.

Let’s take our title as an example:

✅ Engaging: “Cracking the Code” suggests there’s an inside strategy, and it sparks curiosity.
✅ Clear: “How to wow the acceptance committee at your next tech event” leaves no doubt about the topic.
✅ Action-oriented: It promises practical takeaways, not just theory.
✅ Balanced: It walks the line between fun and professional.

Avoid vague titles (“A new approach to software”) or clickbait (“This one trick will fix your codebase”). Instead, aim for clarity with flair. Give the content committee a reason to want to learn more along with the confidence that your talk can deliver.

🎤 Pro tip: After you write your title, ask yourself—would I attend this session? Would I understand what I’m getting from it in five seconds?

3. Make it easy for the content committee to say yes ✅

The content committee is rooting for you, but you’ve got to help them out. The best submissions remove all ambiguity and make a strong case for why this session matters.

Here’s how:

Be specific about your audience: Who is this for? Senior engineers? OSS maintainers? Platform teams? Product leads?
Spell out the takeaways: What will people learn? Tools, frameworks, fresh mindsets?
Tie it to the event: Why does this belong at GitHub Universe? How does it support the event’s themes?

Also, show that your content has a life beyond the stage:

Can your session be turned into a blog, case study, or video?
Is your abstract compelling enough to be featured in a marketing email or keynote recap?
Will attendees be able to apply what they learned the next day?

🎤 Hot tip: Think beyond the talk itself. That’s pure gold for event organizers.

4. Seal the deal with your online presence 🌐

Yes, your session submission is the star, but reviewers on the content committee can also look you up. Your online presence helps us understand:

Your credibility and expertise
Your speaking experience (or potential!)
How easy it will be to promote you as a speaker

You don’t need a massive following. But you do want a strong, relevant footprint. Here are a few tips to consider:

On LinkedIn:

Use a headline that highlights your expertise, not just your title.
Make your “About” section shine with links to talks, blogs, and projects.
Add speaking experience under “Experience” or “Featured.”

On GitHub:

Update your profile README with your focus areas and links.
Pin key repos or projects you’ve contributed to.
Be active in discussions, even if most of your code is private.

🎤 Hot tip: Post about your submission journey! Sharing your process helps you engage with the community and might even inspire someone else to apply.

Ready to take the stage?

You’ve got the ideas. Now you’ve got the blueprint. If you’ve made it this far, we hope you feel ready—and excited—to throw your hat in the ring. Let’s recap:

Lead with passion to find a topic you care deeply about.
Craft a clear, compelling title that grabs attention and gives the content committee an immediate idea of your session topic and takeaways.
Make your submission a no-brainer by showing how it aligns with the event and adds value.
Polish your online presence—it might just tip the scale in your favor.

Whether you’re a seasoned speaker or stepping into the spotlight for the first time, we can’t wait to hear from you. And if you don’t have a session idea this year, you can also nominate a speaker who deserves to take the stage. Submit a session proposal or a speaker nomination from now until Friday, May 2 at 11:59 pm PT to be considered!

Let’s build the future together—one session at a time. 💫

The post Cracking the code: How to wow the acceptance committee at your next tech event appeared first on The GitHub Blog.

Gemma 3 QAT Models: Bringing state-of-the-Art AI to consumer GPUs - Google Developers Blog

2025-04-18T13:34:01.000Z

The release of int4 quantized versions of Gemma 3 models, optimized with Quantization Aware Training (QAT) brings significantly reduced memory requirements, allowing users to run powerful models like Gemma 3 27B on consumer-grade GPUs such as the NVIDIA RTX 3090.

Which AI model should I use with GitHub Copilot? - The GitHub Blog

2025-04-17T21:19:31.000Z

This was originally published on our developer newsletter, GitHub Insider, which offers tips and tricks for devs at every level. If you’re not subscribed, go do that now—you won’t regret it (we promise).

If you’ve ever wondered which AI model is the best fit for your GitHub Copilot project, you’re not alone. Since each model has its own strengths, picking the right one can feel somewhat mysterious.

With models that prioritize speed, depth, or a balance of both, it helps to know what each one brings to the table. Let’s break it down together. 👇

The TL;DR

💳 Balance between cost and performance: Go with GPT-4.1, GPT-4o, or Claude 3.5 Sonnet.
🪙 Fast, lightweight tasks: o4-mini or Claude 3.5 Sonnet are your buddies.
💎 Deep reasoning or complex debugging: Think Claude 3.7 Sonnet, o3, or GPT 4.5.
🖼️ Multimodal inputs (like images): Check out Gemini 2.0 Flash or GPT-4o.

Your mileage may vary and it’s always good to try things yourself before taking someone else’s word for it, but this is how these models were designed to be used. All that being said…

Let’s talk models.

🏎️ AI models designed for coding speed

o4-mini and o3-mini: The speed demons 😈

Fast, efficient, and cost-effective, o4-mini and o3-mini are ideal for simple coding questions and quick iterations. If you’re looking for a no-frills model, use these.

✅ Use them for:

Quick prototyping.
Explaining code snippets.
Learning new programming concepts.
Generating boilerplate code.

👀 You may prefer another model: If your task spans multiple files or calls for deep reasoning, a higher‑capacity model such as GPT‑4.5 or o3 can keep more context in mind. Looking for extra expressive flair? Try GPT‑4o.

⚖️ AI models designed for balance

Claude 3.5 Sonnet: The budget-friendly helper 😊

Need solid performance but watching your costs? Claude 3.5 Sonnet is like a dependable sidekick. It’s great for everyday coding tasks without burning through your monthly usage.

✅ Use it for:

Writing documentation.
Answering language-specific questions.
Generating code snippets.

👀 You may prefer another model: For elaborate multi‑step reasoning or big‑picture planning, consider stepping up to Claude 3.7 Sonnet or GPT‑4.5.

GPT-4o and GPT-4.1: The all-rounders 🌎

These are your go-to models for general tasks. Need fast responses? Check. Want to work with text *and* images? Double check. GPT-4o and GPT-4.1 are like the Swiss Army knives of AI models: flexible, dependable, and cost-efficient.

✅ Use them for:

Explaining code blocks.
Writing comments or docs.
Generating small, reusable snippets.
Multilingual prompts.

👀 You may prefer another model: Complex architectural reasoning or multi‑step debugging may land more naturally with GPT‑4.5 or Claude 3.7 Sonnet.

🧠 AI models designed for deep thinking and big projects

Claude 3.7 Sonnet: The architect 🏠

This one’s the power tool for large, complex projects. From multi-file refactoring to feature development across front end and back end, Claude 3.7 Sonnet shines when context and depth matter most.

✅ Use it for:

Refactoring large codebases.
Planning complex architectures.
Designing algorithms.
Combining high-level summaries with deep analysis.

👀 You may prefer another model: For quick iterations or straightforward tasks, Claude 3.5 Sonnet or GPT‑4o may deliver results with less overhead.

Gemini 2.5 Pro: The researcher 🔎

Gemini 2.5 Pro is the powerhouse for advanced reasoning and coding. It’s built for complex tasks (think: deep debugging, algorithm design, and even scientific research). With its long-context capabilities, it can handle extensive datasets or documents with ease.

✅ Use it for:

Writing full functions, classes, or multi-file logic.
Debugging complex systems.
Analyzing scientific data and generating insights.
Processing long documents, datasets, or codebases.

👀 You may prefer another model: For cost-sensitive tasks, o4-mini or Gemini 2.0 Flash are more budget-friendly options.

GPT-4.5: The thinker 💭

Got a tricky problem? Whether you’re debugging multi-step issues or crafting full-on systems architectures, GPT-4.5 thrives on nuance and complexity.

✅ Use it for:

Writing detailed README files.
Generating full functions or multi-file solutions.
Debugging complex errors.
Making architectural decisions.

👀 You may prefer another model: When you just need a quick iteration on something small—or you’re watching tokens—GPT‑4o can finish faster and cheaper.

o3 and o1: The deep diver 🥽

These models are perfect for tasks that need precision and logic. Whether you’re optimizing performance-critical code or refactoring a messy codebase, o3 and o1 excel in breaking down problems step by step.

✅ Use them for:

Code optimization.
Debugging complex systems.
Writing structured, reusable code.
Summarizing logs or benchmarks.

👀 You may prefer another model: During early prototyping or lightweight tasks, a nimble model such as o4‑mini or GPT‑4o may feel snappier.

🖼️ Multimodal AI models designed to handle it all

Gemini 2.0 Flash: The visual thinker 🤔

Got visual inputs like UI mockups or diagrams? Gemini 2.0 Flash lets you bring images into the mix, making it a great choice for front-end prototyping or layout debugging.

✅ Use it for:

Analyzing diagrams or screenshots.
Debugging UI layouts.
Generating code snippets.
Getting design feedback.

👀 You may prefer another model: If the job demands step‑by‑step algorithmic reasoning, GPT‑4.5 or Claude 3.7 Sonnet will keep more moving parts in scope.

So… which model do I choose?

Here’s the rule of thumb: Match the model to the task. Practice really does make perfect, and as you work with different models, it’ll become clearer which ones work best for different tasks. The more I’ve personally used certain models, the more I’ve learned, “oh, I should switch for this particular task,” and “this one will get me there.”

And because I enjoy staying employed, I would love to cheekily mention that you can (and should!) use these models with…

Good luck, go forth, and happy coding!

Learn more about AI models.

The post Which AI model should I use with GitHub Copilot? appeared first on The GitHub Blog.

Start building with Gemini 2.5 Flash - Google Developers Blog

2025-04-17T19:09:03.000Z

Gemini 2.5 Flash is in preview, offering improved reasoning capabilities through a "thinking" process that developers can control for cost and latency tradeoffs. This updated version aims to provide a cost-effective solution for complex tasks, balancing performance and price.

Making it easier to build with the Gemini API in Google AI Studio - Google Developers Blog

2025-04-16T22:34:01.000Z

Google AI Studio now has an expanded gallery of starter apps, and other updates including more intuitive prompting experience, native code editing, and various interactive examples demonstrating Gemini model capabilities, plus a refreshed UI – so you can continue building with the Gemini API.

GitHub Availability Report: March 2025 - The GitHub Blog

2025-04-16T21:02:57.000Z

In March, we experienced one incident that resulted in degraded performance across GitHub services.

March 29 7:00 UTC (lasting 58 hours)

Between March 29 7:00 UTC and March 31 17:00 UTC, GitHub experienced service degradation due to two separate, but related incidents. On March 29, users were unable to unsubscribe from GitHub marketing email subscriptions due to a service outage. Additionally, on March 31, 2025 from 7:00 UTC to 16:40 UTC users were unable to submit ebook and event registration forms on resources.github.com, also due to a service outage.

The March 29 incident occurred due to expired credentials used for an internal service, preventing customers from being able to unsubscribe directly from marketing/sales topics through github.com/settings/emails UI and from performing the double opt-in step required by some countries. A similar credential expiry on March 31 resulted in users experiencing degradation accessing resources.github.com.

The cause of the incident was traced to an issue in the automated alerting for monitoring upcoming credential expirations. The bug in alerting resulted in the invalid credentials being discovered after they had expired. This resulted in two incidents before we could deploy a durable fix. We mitigated it by renewing the credentials and redeploying the affected services.

To improve future response times and prevent similar issues, we have enhanced our credential expiry detection, alerting, and rotation processes, and are working on improving on-call observability.

Please follow our status page for real-time updates on status changes and post-incident recaps. To learn more about what we’re working on, check out the GitHub Engineering Blog.

The post GitHub Availability Report: March 2025 appeared first on The GitHub Blog.

Three MarTech solutions putting generative AI in marketing - Google Developers Blog

2025-04-16T17:09:02.000Z

Three generative AI-powered MarTech solutions from Google designed to help developers streamline marketing material creation, personalize campaigns, and enhance ad performance. Discover ViGenAiR for video ad creation, Adios for image asset management and generation, and Copycat for on-brand ad copy generation.

Bring your ideas to life: Veo 2 video generation available for developers - Google Developers Blog

2025-04-15T21:39:02.000Z

Generate high-quality videos from text and image prompts with Veo 2, a video generation model, now generally available in the Gemini API and Google AI Studio to enhance your content creation and marketing efforts.

FAANGineering - BlogFlock

Usability and safety updates to Google Auth Platform - Google Developers Blog

How Meta understands data at scale - Engineering at Meta

Data understanding at Meta using PAI

Walkthrough: Understanding user data for the “Beliefs” feature in Facebook Dating

Step 1 – Schematizing

Step 2 – Predicting metadata at scale

Step 3 – Annotating

Step 4 – Inventorying assets and systems

Step 5 – Maintaining data understanding

Putting it all together

Learnings and takeaways

The future of data understanding

Acknowledgements

GitHub for Beginners: Building a REST API with Copilot - The GitHub Blog

What you’ll need and what we’re building

Step 1: Setting up the environment

Step 2: Create the Database

Step 3: Time to create some models

Step 4: Adding authentication

Step 5: Adding trips

Don’t forget about CORS

Some finishing touches

Your next steps

How the GitHub CLI can now enable triangular workflows - The GitHub Blog

First, a lesson in Git fundamentals

Refs

Pushing and pulling

The @{push} revision syntax

Pull Requests

Common Git workflows

Using a Git configuration file for triangular workflows

Setting up a triangular branch workflow

Setting up a triangular fork workflow

Setting a branch’s pushremote

Setting a repo’s remote.pushDefault

Updating the gh pr command set to reflect Git

Conclusion

A guide to deciding what AI model to use in GitHub Copilot - The GitHub Blog

Why use multiple models?

Chat vs. code completion

Reasoning models for certain programming tasks

What to look for in a new AI model

Recentness

Speed and responsiveness

Accuracy

How to test an AI model in your workflow

Start with a simple app

Use it as a “daily driver” for a while

Take this with you

Additional resources

Achieve real-time interaction: Build with the Live API - Google Developers Blog

Get ready for Google I/O: Program lineup revealed - Google Developers Blog

From prompt to production: Building a landing page with Copilot agent mode - The GitHub Blog

Designing with AI: From PRD to UI

Setting up the project

Building section by section with Copilot agent mode

Creating the hero and navigation section

Commit early and often

Improve accuracy with Copilot custom instructions

Iterating on your designs by prompting Copilot

“Built by Developers” section

“API development” section

“Dashboard preview” section

Smart suggestions, fast results

Wrapping up:

What’s next?

Take this with you

Exploring GitHub CLI: How to interact with GitHub’s GraphQL API endpoint - The GitHub Blog

What is GraphQL?

How is GraphQL used at GitHub?

Why use GitHub CLI for GraphQL?

How to get started with gh api graphql

Running queries and mutations

Basic query example

Running mutations

Filtering GraphQL results

Handling pagination

Building complex scripts: Chaining GraphQL queries together

Take this with you

The `@{push}` revision syntax

Setting a branch’s `pushremote`

Setting a repo’s `remote.pushDefault`

Updating the `gh pr` command set to reflect Git

How to get started with `gh api graphql`