The `limitToFirst` method in Firebase is used to retrieve a specified number of items from the beginning of a query result. For example, `limitToFirst(10)` will return the first 10 items in the ordered data set.

The `limitToFirst` method in Firebase is used to retrieve a specified number of items from the beginning of a query result. For example, `limitToFirst(10)` will return the first 10 items in the ordered data set.
FCM stands for Firebase Cloud Messaging, and GCM stands for Google Cloud Messaging.
The types of Firebase Database Rules are:
1. **Read Rules** - Control who can read data.
2. **Write Rules** - Control who can write data.
3. **Validation Rules** - Ensure data meets certain criteria before being written.
The different types of event types for reading data in Firebase are:
1. `value`: Triggered once for the initial data and then again whenever the data changes.
2. `child_added`: Triggered for each child node when the listener is attached and for each new child added.
3. `child_changed`: Triggered when a child node is changed.
4. `child_removed`: Triggered when a child node is removed.
5. `child_moved`: Triggered when a child node changes its position in the list.
The `limitToLast` method in Firebase is used to retrieve a specified number of the last items from a query result. It allows you to limit the results to the last N children in a list, making it useful for displaying the most recent entries in a database.
Tags in Git are used to mark specific points in the repository's history, often to denote release versions. To create a tag, use the command `git tag <tag-name>`. To push tags to the remote repository, use `git push origin <tag-name>` or `git push –tags` to push all tags at once.
`git fetch` downloads changes from the remote repository to your local repository but does not merge them into your working directory. `git pull` does both: it fetches the changes and then merges them into your current branch.
Git cherry-pick is a command that allows you to apply the changes from a specific commit in one branch to another branch. You would use it when you want to selectively apply certain commits without merging the entire branch, such as when you need a bug fix or feature from another branch without bringing in all other changes.
A detached HEAD in Git occurs when the HEAD pointer is not pointing to a branch, but directly to a specific commit. This means you are not on a branch, and any new commits will not be associated with any branch until you create a new branch or switch back to an existing one.
You can check the status of your Git repository by running the command `git status` in your terminal.
The main branch is typically the default branch for development and contains the latest stable code, while the gh-pages branch is specifically used for hosting static websites directly from a GitHub repository.
You can secure secrets and environment variables in GitHub Actions by using GitHub Secrets. Store sensitive information in the repository settings under "Secrets" and reference them in your workflow files using the syntax `${{ secrets.SECRET_NAME }}`.
GitHub Actions is a feature that allows you to automate workflows directly in your GitHub repository. It enables you to create custom software development lifecycle workflows, such as building, testing, and deploying code, triggered by events like pushes, pull requests, or scheduled times.
To create a new repository on GitHub, follow these steps:
1. Log in to your GitHub account.
2. Click the "+" icon in the top right corner and select "New repository."
3. Enter a name for your repository and optional description.
4. Choose the repository visibility (public or private).
5. Optionally, initialize the repository with a README, .gitignore, or license.
6. Click the "Create repository" button.
To clone a GitHub repository, use the command:
“`
git clone <repository-url>
“`
Replace `<repository-url>` with the URL of the repository you want to clone.
In GitLab CI/CD, you can set environment variables in several ways:
1. π§ In the GitLab UI (recommended for secrets)
-
Go to:
Project
βSettings
βCI/CD
β ExpandVariables
-
Add key-value pairs (e.g.,
API_KEY = abc123
) -
You can mark them as protected or masked
2. π In .gitlab-ci.yml
3. π¦ In job definitions
β
Tip: Use UI for sensitive values (API keys, tokens) and .gitlab-ci.yml
for general config.
πΉ Key Features:
-
Code Review: Team members can review code, comment, and suggest changes.
-
Pipeline Integration: CI/CD pipelines automatically run (e.g. tests, builds) before merging.
-
Approvals: You can set required approvals before allowing merge.
-
Conflict Detection: GitLab checks for merge conflicts automatically.
-
Squash & Merge: Option to squash commits into a single commit on merge.
-
Merge Strategies: Merge commit, fast-forward, or squash merge.
β Summary: MRs ensure quality and collaboration by combining code review, automated testing, and controlled merging.
In GitLab CI/CD, you can trigger pipelines in several ways:
πΉ 1. Manually (From GitLab UI):
-
Go to CI/CD > Pipelines in your project.
-
Click the βRun pipelineβ button.
-
You can choose a branch and pass variables.
πΉ 2. On Specific Events:
-
push: Automatically triggered on code push.
-
merge_request_events: On merge requests.
-
schedule: Using CI/CD > Schedules to run periodically.
-
tags: Trigger when a tag is pushed.
πΉ 3. Via .gitlab-ci.yml
Rules:
Use rules
, only
, or except
to specify conditions:
πΉ 4. Trigger Token (API):
Use the GitLab API and a trigger token to start pipelines externally:
These options give you flexibility for automation and control over your CI/CD process.
In GitLab CI/CD, the needs
keyword defines job dependencies and allows jobs to run earlier by enabling parallel execution when possible.
β Purpose:
It tells GitLab that a job depends on the output of another job.
π§ Syntax:
π When to use:
-
To reduce pipeline time by skipping stage sequencing
-
When jobs in later stages need artifacts/results from earlier jobs
-
For creating DAG-style (Directed Acyclic Graph) pipelines
In GitLab, access control is managed using:
1. Project & Group Memberships:
-
Users are assigned roles at the project or group level.
2. Role-Based Permissions:
Common roles include:
-
Guest β limited access (issues, comments)
-
Reporter β can view and download code
-
Developer β can push code, create branches
-
Maintainer β full access, including CI/CD and settings
-
Owner (group level only) β manage everything, including members
3. Private, Internal, and Public Visibility:
-
Controls who can access the project/repo.
4. Protected Branches and Tags:
-
Limit who can push, merge, or delete branches/tags.
5. Access Tokens:
-
Personal, project, or group access tokens for CI/CD or API use.
These tools together help enforce secure and flexible access policies in GitLab.