2025 09 30 week 2 - Session 3 TDS Sep 2025#

2025 09 30 week 2 - Session 3 TDS Sep 2025

Duration: 1h 45m

Here’s an FAQ based on the live tutorial:

GitHub CodeSpaces & Actions FAQ#

Q1: What’s the difference between using CLI and a desktop application (like GitHub Desktop) to connect my local machine to GitHub? Does it matter which one I use for the course content?

A1: The Command Line Interface (CLI) is one way to connect and interact with GitHub (e.g., cloning, pushing, pulling). A desktop application like GitHub Desktop offers a graphical user interface for similar functionalities. I haven’t personally used GitHub Desktop, but it should be capable of performing these tasks. For the course content, it doesn’t matter which method you choose.

Q2: I’m confused about managing branches in GitHub (main vs. second branch), deleting branches, and setting them as public or private. Are branches required for this course?

A2: Branches are essential when you’re collaborating with multiple people on a project or when you’re working on different features simultaneously. For this specific course, whether you need to use branches depends on if you plan to collaborate with others or work on the project alone. The course content will work either way.

Q3: If I pull a GitHub repository to my local machine using WSL and open that folder in VS Code, will Git commands and installations work seamlessly in VS Code without re-configuring? What if I start working in VS Code first and then open the project in WSL?

A3: Yes, they will work seamlessly. VS Code acts primarily as an editor. If your Git environment is configured within your WSL terminal (e.g., Ubuntu), then when you open a folder in VS Code and select the WSL terminal, all your Git configurations and installations from WSL will be active and accessible. The same applies if you start in VS Code and then open the project in WSL. There’s also a dedicated WSL extension for VS Code that provides even more seamless integration.

Q4: When I open a new terminal within VS Code, which underlying terminal environment am I using (e.g., PowerShell or WSL)?

A4: You will be using the WSL terminal. If it doesn’t default to WSL, you can make it do so by closing all existing terminals in VS Code, opening a new one, and then explicitly selecting the WSL option from the available terminal types.

Q5: Is using a virtual environment (like venv in Python) required or considered a best practice? What are the storage limitations for repositories and individual files on GitHub?

A5: Using a virtual environment is considered a best practice because it helps isolate your project’s dependencies, preventing conflicts with other projects or your system’s global environment. Regarding storage: GitHub provides a total of 15GB of storage across all your repositories. Individual files larger than 100MB are generally restricted. For GitHub CodeSpaces, while the general storage limit is higher, it’s recommended to keep repository sizes below 1GB for optimal performance.

Q6: What exactly is GitHub CodeSpaces, and is it similar to services like Replit? Why would I use CodeSpaces if I can do all my development locally?

A6: GitHub CodeSpaces is a cloud-hosted development environment. It’s essentially like running VS Code in a web browser, but the underlying machine is a powerful server in the cloud. It allows you to create customizable development machines with specified CPU and RAM configurations, typically using an Ubuntu Linux image. Yes, it’s similar to Replit in that it provides a cloud-based development platform. You’d use CodeSpaces to quickly spin up a consistent development environment without needing to install everything locally, making it ideal for collaboration or working on projects with specific, complex dependencies. While you can do everything locally, CodeSpaces offers convenience, consistency, and access to powerful hardware.

Q7: Does using GitHub CodeSpaces cost money?

A7: GitHub CodeSpaces offers a free tier that includes 120 compute hours per month. There’s also a Pro tier that provides 180 compute hours. The rate at which these hours are consumed depends on the hardware configuration you choose for your CodeSpace (e.g., a 2-core machine will consume hours twice as fast as a 1-core machine for the same duration).

Q8: Why should I choose a CodeSpaces region (location) that is geographically closer to me?

A8: Choosing a CodeSpaces region closer to your physical location reduces network latency. This means that interactions with your CodeSpace (like typing, running code, or navigating files) will feel faster and more responsive, improving your overall development experience.

Q9: Can you recap how CodeSpaces is configured and how it works with specific files?

A9: CodeSpaces environments are highly customizable, primarily through a .devcontainer.json file located in your repository. This file allows you to:

  1. Specify Base Image: Define the base Docker image (e.g., a specific Python version or Linux distribution).
  2. Install Dependencies: Include postCreateCommand scripts to automatically install required OS packages, Python libraries (via requirements.txt), or other tools.
  3. Add Extensions: Recommend or pre-install VS Code extensions. When you create a CodeSpace, it reads this file to set up the environment automatically, ensuring consistency for all contributors.

Q10: What are GitHub Actions?

A10: GitHub Actions is GitHub’s continuous integration/continuous deployment (CI/CD) service. It allows you to automate various tasks in your software development workflow directly within your GitHub repository. This includes things like running tests, building code, deploying applications, or even automating code reviews.

Q11: How do GitHub Actions relate to CodeSpaces?

A11: You can use GitHub Actions within your CodeSpaces environment. This means you can develop your project in CodeSpaces and then use GitHub Actions to automate tasks specific to that project (like deploying it or running tests) based on events in your repository.

Q12: What are some common use cases for GitHub Actions?

A12: GitHub Actions are versatile and can automate many parts of your workflow:

  • Automated Testing: Run unit, integration, or end-to-end tests whenever new code is pushed.
  • Continuous Deployment (CD): Automatically deploy your application to a hosting service (e.g., Hugging Face Spaces, Vercel) after successful tests.
  • Code Quality Checks: Run linters, formatters, or security scans.
  • Pull Request Management: Automate assigning reviewers, adding labels, or validating code standards.
  • Scheduled Tasks: Run scripts at specific intervals (e.g., daily documentation updates).
  • Documentation Generation: Automatically generate and update project documentation.

Q13: How do you configure GitHub Actions?

A13: You configure GitHub Actions by creating YAML files within a .github/workflows directory in your repository. Each YAML file defines a specific workflow, including:

  • Events: What triggers the workflow (e.g., on: push, on: pull_request, on: schedule).
  • Jobs: A set of steps that run on a runner (a virtual machine).
  • Steps: Individual commands or actions to execute (e.g., checkout code, run a script, install dependencies).

Q14: How does Git LFS (Large File Storage) help manage large files in GitHub repositories (including CodeSpaces)?

A14: Git LFS is a Git extension that helps manage large files (like datasets, images, or executables) that exceed Git’s typical size recommendations (often 100MB per file). Instead of storing the full file content directly in the Git repository, Git LFS stores pointers to the files, while the actual file content is stored on a remote Git LFS server. This keeps your Git repository lean, saves space, and improves cloning/fetching performance.

Q15: What is Hugging Face Spaces?

A15: Hugging Face Spaces is a platform that provides an easy way to build, deploy, and share machine learning models and interactive demos. It’s similar to CodeSpaces but specifically tailored for ML. You can host your models there, integrate them with user interfaces, and allow others to interact with them. Hugging Face also provides a vast repository of pre-trained models.

Q16: What are some examples of models available on Hugging Face Spaces?

A16: Hugging Face hosts a wide array of machine learning models. Examples include large language models (LLMs) with hundreds of millions or even billions of parameters. These models often involve very large files (in GBs) because they store complex tensor data (matrices) representing their learned knowledge.

Q17: What is a “token” used for in GitHub or Hugging Face?

A17: A token, specifically a Personal Access Token (PAT), is an alternative to using your password for authentication when performing Git operations (like pushing code) or interacting with APIs. It’s a more secure practice as you can grant specific permissions to a token and revoke it without changing your main account password. You generate PATs in your user settings on GitHub or Hugging Face.

Q18: Can I use the same SSH key for both GitHub and Hugging Face?

A18: Yes, you can generally use the same SSH key across multiple platforms like GitHub and Hugging Face. However, for enhanced security, some users prefer to generate and use different SSH keys for each distinct platform.

Q19: How do CodeSpaces and GitHub Actions differ from each other?

A19:

  • CodeSpaces: Provides a development environment. It’s where you write, debug, and test your code in a cloud-hosted VS Code instance.
  • GitHub Actions: Provides automation. It’s a CI/CD service that runs predefined scripts automatically based on events (like a code push) or on a schedule. You can use GitHub Actions within your CodeSpace to automate tasks related to your development, like testing or deployment, once your code is ready.

Q20: Could you provide a brief summary of what was covered in this session?

A20: In this session, we explored GitHub CodeSpaces as a cloud-based development environment and GitHub Actions for automating various tasks like testing and deployment (CI/CD). We also looked at Hugging Face Spaces for deploying machine learning models. We covered configurations for integrating these tools, including using .devcontainer.json for CodeSpaces customization, setting up GitHub Actions workflows, and managing large files with Git LFS. We also discussed SSH keys and Personal Access Tokens for authentication across platforms.