Comprehensive Analysis of MySQL CRUD: A Quick Guide for Beginners to Master Data Insert, Update, Delete, and Query
This article introduces MySQL CRUD operations (Create, Read, Update, Delete), which are fundamental to data management. The four core operations correspond to: Create (insertion), Read (query), Update (modification), and Delete (removal). First, the preparation work: create a `students` table (with auto-incrementing primary key `id`, `name`, `age`, and `class` fields) and insert 4 test records. **Create (Insert)** : Use the `INSERT` statement, which supports single-row or batch insertion. Ensure field and value correspondence; strings should be enclosed in single quotes, and auto-incrementing primary keys can be specified as `NULL` (e.g., `INSERT INTO students VALUES (NULL, 'Xiao Fang', 15, 'Class 4')`). **Read (Query)** : Use the `SELECT` statement. The basic syntax is `SELECT 字段 FROM 表`, supporting conditional filtering (`WHERE`), sorting (`ORDER BY`), fuzzy queries (`LIKE`), etc. For example: `SELECT * FROM students WHERE age > 18`. **Update (Update)** : Use the `UPDATE` statement with syntax `UPDATE 表 SET 字段=值 WHERE 条件`. **Without a `WHERE` clause, the entire table will be modified** (e.g., `UPDATE students SET age=18 WHERE name='Xiao Gang'`). **Delete (Delete)** :
Read MoreMySQL Installation and Environment Configuration: A Step-by-Step Guide to Setting Up a Local Database
This article introduces basic information about MySQL and a guide to its installation and usage. MySQL is an open-source relational database management system (RDBMS) known for its stability and ease of use, making it suitable for local practice and small project development. Before installation, the operating system (Windows/Linux) should be confirmed, and the community edition installation package should be downloaded from the official website. The minimum hardware requirement is 1GB of memory. For Windows installation: Download the community edition installer, choose between typical or custom installation. During configuration, set a root password (at least 8 characters), and select the utf8mb4 character set (to avoid Chinese garbled characters). Verify the version using `mysql -V` and log in with `mysql -u root -p`. For Linux (Ubuntu), install via `sudo apt`, followed by executing the security configuration (changing the root password). Common issues include port conflicts (resolve by closing conflicting services), incorrect passwords (root password can be reset on Windows), and Chinese garbled characters (check character set configuration). It is recommended to use tools like Navicat or the command line to practice SQL, and regularly back up data using `mysqldump`. After successful installation, users can proceed to learn SQL syntax and database design.
Read MoreMySQL Primary Key and Foreign Key: Establishing Table Relationships in Simple Terms for Beginners
This article explains the necessity of primary keys and foreign keys for database orderliness. A primary key is a field within a table that uniquely identifies data (e.g., `class_id` in a class table), ensuring data uniqueness and non-nullability, similar to an "ID card." A foreign key is a field in a child table that references the primary key of a parent table (e.g., `class_id` in a student table), establishing relationships between tables and preventing invalid child table data (e.g., a student belonging to a non-existent class). The core table relationship is **one-to-many**: a class table (parent table) corresponds to multiple student records (child table), with the foreign key dependent on the existence of the parent table's primary key. Key considerations: foreign keys must have the same data type as primary keys, the InnoDB engine must be used, and data in the parent table must be inserted first. Summary: Primary keys ensure data uniqueness within a table, while foreign keys maintain relationships between tables. In a one-to-many relationship, the parent table's primary key and the child table's foreign key are central, resulting in a clear and efficient database structure.
Read MoreDetailed Explanation of MySQL Data Types: Basic Type Selection for Beginners
Data types are fundamental in MySQL; choosing the wrong one can lead to issues like data overflow or wasted space, making it crucial for writing effective SQL. This article explains from three aspects: importance, type classification, and selection principles. **Numeric Types**: Integers (TINYINT/SMALLINT/INT/BIGINT, with increasing ranges; use UNSIGNED to avoid negative value waste); Floats (FLOAT/DOUBLE, low precision, suitable for non-financial scenarios); Fixed-point numbers (DECIMAL, high precision, for exact calculations like amounts). **String Types**: Fixed-length CHAR(M) (suitable for short fixed text but space-wasting); Variable-length VARCHAR(M) (space-efficient but requires extra length storage); TEXT (stores ultra-long text, no default values allowed). **Date and Time**: DATE (date only); DATETIME (full date and time); TIMESTAMP (4 bytes, short range but auto-updates, suitable for time-sensitive data). **Other Types**: TINYINT(1) as a boolean alternative; ENUM (single selection from predefined values); SET (multiple selections from predefined values). **Selection Principles**: Prioritize the smallest appropriate type; choose based on requirements (e.g., VARCHAR for phone numbers, DECIMAL for amounts); avoid overusing NULL; strictly prohibit incorrect use of INT for phone numbers, etc.
Read MoreLearning MySQL from Scratch: Mastering Data Extraction with Query Statements
This article introduces the basics of MySQL. First, it explains that MySQL is an open-source relational database used for storing structured data (such as users, orders, etc.). Before use, it needs to be installed and run, and then connected through graphical tools or command lines. Data is stored in the form of "tables", which are composed of "fields" (e.g., id, name). For example, a student table includes fields like student ID and name. Core query operations include: basic queries (`SELECT * FROM table_name` to retrieve all columns, `SELECT column_name` to specify columns, `AS` to set aliases); conditional queries (`WHERE` combined with comparison operators, logical operators, and `LIKE` for fuzzy matching to filter data); sorting (`ORDER BY`, default ascending `ASC`, descending with `DESC`); limiting results (`LIMIT` to control the number of returned rows); and deduplication (`DISTINCT` to exclude duplicates). It also provides comprehensive examples and practice suggestions, emphasizing familiarizing oneself with query logic through table creation testing and combined conditions. The core of MySQL queries: clarify requirements → select table → specify columns → add conditions → sort/limit. With more practice, one can master query operations proficiently.
Read MoreSQL Introduction: How to Create and Manipulate Data Tables in MySQL?
A data table is a "table" for storing structured data in a database, composed of columns (defining data types) and rows (recording specific information). For example, a "student table" contains columns such as student ID and name, with each row corresponding to a student's information. To create a table, use the `CREATE TABLE` statement, which requires defining the table name, column names, data types, and constraints (e.g., primary key `PRIMARY KEY`, non-null `NOT NULL`, default value `DEFAULT`). Common data types include integer `INT`, string `VARCHAR(length)`, and date `DATE`. Constraints like auto-increment primary key `AUTO_INCREMENT` ensure uniqueness. To view the table structure, use `DESCRIBE` or `SHOW COLUMNS`, which display column names, types, and whether null values are allowed. Operations include: - Insertion: `INSERT INTO` (specify column names to avoid order errors), - Query: `SELECT` (`*` for all columns, `WHERE` for conditional filtering), - Update: `UPDATE` (must include `WHERE` to avoid full-table modification), - Deletion: `DELETE` (similarly requires `WHERE`, otherwise the entire table is cleared). Notes: Strings use single quotes; `UPDATE`/`DELETE` must include `WHERE`; primary keys are unique and non-null.
Read MoreGit Version Control: Understanding the Underlying Logic of Snapshots and Version Evolution
This article introduces the core knowledge of version control and Git. Version control is used to securely preserve code history, enabling backtracking, collaboration, and experimentation, while resolving code conflicts in multi - person collaboration. Git is a distributed version control system where each developer has a complete local copy of the code history, eliminating the need for continuous internet connection and enhancing development flexibility. Git's core design consists of "snapshots" (each commit is a complete copy of the code state for easy backtracking) and "branches" (managing development in parallel through pointers, such as the main branch and feature branches). Its three core areas are the working directory (where code is modified), the staging area (temporarily storing changes to be committed), and the local repository (storing snapshots). The operation process is "writing code → adding to the staging area → committing to the repository". Basic operations include initialization (git init), status checking (status), committing (add + commit), history viewing (log), branch management (branch + checkout + merge), version rollback using reset, and collaboration through remote repositories (push/pull). Essentially, Git is "snapshots + branches". By understanding the core areas and basic operations, one can master Git, which supports clear code evolution and team collaboration.
Read MoreGit Common Commands Quick Reference: A Collection for Beginners
This quick reference is a beginner's guide to Git, covering the following core content: basic configuration (`git config --global user.name/email` to set identity, `git init` to initialize a repository); workspace and staging area operations (`git status` to check status, `git add [file/.]` to stage changes, `git commit -m "description"` to commit); branch operations (`git branch` to create, `git checkout -b` to create and switch, `git merge` to merge, `git branch` to list branches); remote repository (`git remote add origin [URL]` to associate, `git pull` to fetch and merge, `git push -u origin [branch]` to push); undo and recovery (`git reset HEAD` to unstage, `reset --soft/hard` to roll back, `checkout -- [file]` to discard modifications, `git stash` to save changes); viewing history (`git log --oneline` for simplified output); and common issues (manual resolution of conflicts by editing files followed by `add+commit`, and `stash` for incomplete work). The core is the basic workflow of `add→commit`, while branch and remote operations are key for collaboration, requiring practice to master.
Read MoreGit Repository Size Optimization: Techniques for Cleaning Large Files and History
The main reasons for a growing Git repository are committing large files (e.g., logs, videos), leftover large files in historical records, and unoptimized submodules. This leads to slow cloning/downloads, time-consuming backup transfers, and local operation lag. Cleanup methods: For recently committed but un-pushed large files, use `git rm --cached` to remove cached files, then re-commit and push. For large files in historical records, rewrite history with `git filter-repo` (install the tool, filter large files, and force push updates). After cleanup, verify with `git rev-list` to check for omissions. Ultimate solution: Batch cleanup can use `--path-glob` to match files. Large submodule files require prior cleanup before updating. Long-term optimization recommends Git LFS for managing large files (track large file types after installation to avoid direct commits). Always back up the repository before operations. Use force pushes cautiously in collaborative environments; ensure team confirmation before execution. Develop the habit of committing small files and using LFS for large files to keep the repository streamlined long-term.
Read MoreGit Submodule Update: Methods to Keep Dependencies in Sync
Git submodules are used to address the trouble of code reuse and avoid repeated pasting. The main repository only records the version and location of the sub-repositories, while the sub-repositories store the actual code. Their uses include team sharing of components, version control of third-party dependencies, and code isolation. Usage steps: To clone a repository with nested submodules, use `git clone --recursive`. To initialize and update submodules, use `git submodule update --init --recursive` (to recursively update nested submodules). To update submodules and pull the latest versions, execute `git submodule update --recursive`. After modifying a submodule, first commit within the submodule, then return to the main project, execute `git add <submodule directory>` and `git commit` to update the main project's reference. After pulling updates to the main project, synchronize the submodules. Common issues: If the directory is empty, initialize it. If the version is incorrect, perform a recursive update. If changes were made without syncing the main project, add and commit the reference. Submodules are like Lego parts—independent and reusable. The key points to remember are "clone with --recursive, update and sync with --recursive, and sync references after modifications."
Read MoreSummary of Git Undo Operations: Differences Between reset, revert, and restore
Git provides three undo tools: `reset`, `revert`, and `restore`. They have similar functions but different scenarios, so you need to choose based on the situation: - **git reset**: Adjusts the branch pointer and discards partial commits. There are three modes: `--mixed` (default, reverts the pointer and staging area, preserves the working directory), `--soft` (only reverts the pointer, preserves changes), and `--hard` (complete rollback, most dangerous). It is suitable for quick rollbacks of local unpushed changes. `--hard` is strictly prohibited for already pushed branches. - **git revert**: Creates a new commit to reverse the changes, preserving the original history. It has a simple syntax (e.g., `git revert HEAD~1`). It safely rolls back pushed branches without destroying the team's history. - **git restore**: Precisely restores files without affecting the branch. It can undo staging (`git restore --staged <file>`) or restore a single file to a historical version (`git restore --source=HEAD~1 <file>`). It replaces the old `git checkout --` and has a clearer semantic meaning. **Differences**: `reset` adjusts the branch pointer (risky), `revert` adds undo commits (safe), and `restore` restores individual files (precise). Decision mnemonic: For local unpushed changes... (Note: The original Chinese ends with "决策口诀：本地未推用" which is incomplete; the translation assumes the intended context of "For local unpushed changes, use...".)
Read MoreGit Commit Message Template: Standardizing Team Collaboration Submission Norms
### Why Unified Commit Specification is Needed? A unified commit specification addresses issues like difficult code reviews, chaotic version iterations, and failed automation tools. It ensures clarity on the purpose and content of each change, facilitating team collaboration. ### Specification Format (Conventional Commits) - **Type** (Required): E.g., `feat` (new feature), `fix` (bug fix), `docs` (documentation). Incorrect types mislead version management. - **Description** (Required): Concise (≤50 characters), verb-starting (e.g., "optimize", "fix"), avoiding ambiguity. - **Body** (Optional): After a blank line, detail the reason for the change, implementation details, or problem-solving process. - **Footer** (Optional): Link to issues (e.g., `Closes #123`) or note breaking changes. ### How to Create a Commit Template? - **Global Template**: Create `.gitmessage` in the user’s root directory and configure Git with `git config --global commit.template ~/.gitmessage`. - **Project-level Template**: Create `.gitmessage` in the project root and run `git config commit.template .gitmessage`. ### Tool Assistance for Enforcing the Specification - **Commit
Read MoreGit Remote Repository Migration: A Practical Guide to Migrating from SVN to Git
### Why Migrate: SVN, as a centralized tool, has limitations (requires network for commits, inflexible branch management, frequent conflicts). Git, a distributed version control system, supports local repositories, parallel multi-branching, and offline operations, improving team collaboration efficiency. ### Preparation: Install Git, SVN, and `svn2git` (via RubyGems, requires Ruby environment); create an empty Git repository on platforms like GitHub/GitLab; configure Git identity (`user.name` and `user.email`). ### Migration Steps (Taking GitHub as an Example): 1. **Export SVN History**: Use `svn2git` to convert, specifying the SVN repository URL and branch/tag paths (e.g., `--trunk=trunk --branches=branches --tags=tags`). An `authors.txt` file can map SVN authors to Git users. 2. **Push to Remote**: Navigate to the generated Git repository, link the remote address, then push all branches (`git push -u origin --all`) and tags (`git push -u origin --tags`). 3. **Verify Results**: Check branch lists, commit history, and file integrity. ### Common Issues:
Read MoreGit Repository Permission Management: How to Set Access Permissions for Team Members
Git repository permission management serves as the "access control system" for team collaboration, with the core goal of ensuring code security and preventing unauthorized modifications or leaks, while adhering to the principle of least privilege (allocating only the necessary permissions). Common permission categories include: Read (read-only access, suitable for new team members or documentation authors), Write (ability to commit code, for regular developers), and Admin (highest privileges, for project leads). Taking GitHub as an example, the setup steps are as follows: Navigate to the repository → Settings → Manage access → Add collaborator to assign permissions (select Write for regular members, Read for those needing only access, and Admin for project leads). For advanced management, branch protection rules can be configured (e.g., requiring PR reviews and CI tests before merging). Guidelines: Avoid overuse of high-privilege accounts, regularly revoke access for departing members, and use team groups for batch permission management. The core principle is to clarify responsibilities, apply the least privilege, and enforce branch protection, ensuring permissions are "just sufficient."
Read MoreGit and Code Review: Complete Process and Guidelines for Pull Requests
The article focuses on the key roles of Git and Pull Requests (PRs) in team collaborative development. Git enables version management through branches (parallel development), commits (saving code snapshots), and pushes (sharing code). As a collaboration bridge, the PR process includes: synchronizing the main branch to ensure the latest code, creating a PR after pushing the branch (with clear descriptions of the modification purpose, test results, etc.), waiting for code review (identifying issues and ensuring quality), and merging and cleaning up. Key specifications: making small, incremental commits to avoid large PRs, having clear commit messages, timely communication of feedback, and respecting review comments. Git and PRs facilitate efficient collaboration, improving code quality and team efficiency.
Read MoreGit Branch Renaming: Steps to Safely Modify Local and Remote Branch Names
### Guide to Renaming Git Branches Renaming branches is necessary to improve code structure clarity due to early naming inconsistencies, collaboration requirements, or logical adjustments. Ensure no uncommitted changes exist locally (`git status` for verification) and notify the team to avoid conflicts before proceeding. **Renaming a Local Branch**: Execute `git branch -m old_branch_name new_branch_name`, e.g., `git branch -m dev_old dev`. Verify with `git branch`. **Renaming a Remote Branch**: Since Git does not support direct renaming, follow these steps: ① Delete the remote old branch (`git push origin --delete old_branch_name`; irreversible, confirm content first); ② Push the local new branch (`git push origin new_branch_name`); ③ Optionally set upstream tracking (`git branch --set-upstream-to origin/new_branch_name`). Verification: Check remote branches with `git branch -r` and switch to test the new branch. **Notes**: Synchronize with the team when working collaboratively, rename after merging, and back up remote branches before deletion.
Read MoreGit Version Control Basics: Core Differences Between Distributed and Centralized Systems
Version control is a core tool for managing code changes in software development, addressing issues such as multi-person collaboration and version rollback. This article compares centralized and distributed version control: Centralized version control systems (e.g., SVN) rely on a central repository, where all code must be uploaded and downloaded through a central server. They depend on network connectivity, have weak offline capabilities, and often lead to file conflicts when multiple users modify the same file simultaneously, which require manual resolution. In distributed version control systems (e.g., Git), each developer maintains a complete local repository, while the central server merely acts as a data synchronization hub. Git supports robust offline operations, enabling local commits and branching. It facilitates flexible collaboration, with conflicts marked by the system for autonomous merging, and ensures high data security due to multiple local backups. Key differences: Centralized systems depend on a central repository, whereas distributed systems feature local independence; centralized systems are constrained by network connectivity, while distributed systems allow seamless offline work; centralized collaboration requires central coordination, whereas distributed systems offer greater flexibility. As a mainstream distributed tool, Git excels with its local repository, offline functionality, and flexible collaboration, making it a standard in development. Beginners should master its basic operations.
Read MoreGit Submodules: The Proper Way to Incorporate Third-Party Code into Your Project
Git submodules are used to address issues such as version control loss, collaborative chaos, and code redundancy when a parent project reuses third-party code. The core idea is to embed an independent sub-repository within the parent project, which only records the location and version information of the submodule, facilitating independent tracking of updates. Basic usage: After initializing the parent project, use `git submodule add` to add a third-party repository as a submodule (generating the `.gitmodules` file to record configurations). When cloning a parent project containing submodules, use `--recursive` or manually execute `git submodule update` to pull the submodule code. Submodules can be modified and updated independently, while the parent project needs to commit new references to the submodule to synchronize versions. Note: Submodules do not update automatically; you need to manually enter the submodule directory, execute `git pull`, and then commit the parent project. For multi-person collaboration, `.gitmodules` and submodule versions must be shared to ensure consistent paths and versions. Submodules differ from subtree merging, where the former is maintained independently, while the latter merges code into the parent project.
Read MoreGit stash: Scenarios and Operations for Temporarily Saving Uncommitted Code
Git stash is used to temporarily save uncommitted work progress, solving code management issues when switching branches or handling other tasks. Common scenarios include when an urgent repair for an online bug is needed during development, or when temporarily dealing with a simple task, allowing the current modifications to be safely saved. Core operations: Use `git stash save "message"` to save uncommitted changes; use `git stash list` to view the list of saved stashes; use `git stash pop` (restore and delete) or `git stash apply` (restore and keep) to restore the most recent stash; use `git stash drop` to delete a specific stash, and `git stash clear` to delete all stashes. The `-u` parameter can save untracked files. Note: Stash does not save untracked files; for long-term work progress, it is recommended to use `git commit` to avoid relying on stash. Mastering these operations allows flexible management of the development process and ensures code safety.
Read MoreGit Commit Message Specification: Enhancing Team Collaboration Efficiency
In daily development, standardized Git commit messages are crucial for team collaboration and issue tracking, as non-standardized messages can lead to version history chaos. The current mainstream specification is Conventional Commits, with the following structure: mandatory type (e.g., `feat` for new features, `fix` for bug fixes, `docs` for documentation), optional scope (limiting module scope, e.g., `user module`), brief description (core content), optional body (detailed explanation), and optional footer (linking to issues or indicating breaking changes). Tools can help develop this habit: `commitizen` (interactive tool) or `commitlint + husky` (automatic pre-commit checks). The benefits of standardization include improved collaboration efficiency, automated version log generation, clear issue tracking, and early warning of breaking changes, making it worthwhile for teams to adopt.
Read MoreGit Quick Start: Master Basic Operations in 30 Minutes
Git is a distributed version control system (VCS) used to record file modification history, enabling team collaboration and personal history回溯 (retrospection). Its core advantages include version rollback (to prevent accidental modifications), multi - person collaboration (code merging), and local security management (operations first local, then cloud - based). Basic concepts are metaphorized by "areas": Working Directory (drafts), Staging Area (items to be committed), Local Repository (file cabinet), and Remote Repository (cloud - based shared library). Basic operations are divided into five steps: 1. Initialize the repository (`git init`); 2. Configure user information (`config`); 3. Track and commit changes (`status` to check status, `add` to stage, `commit` to save); 4. Version management (`log` to view history, `reset` to roll back); 5. Branch operations (`checkout - b` to create a branch, `merge` to combine branches); 6. Remote repository operations (`clone`, `push`, `pull`). The core principles are "timely commits, branch management, and version rollback", with a key command chain: `init→add→commit→log/reset→branch→push/pull`. Basic operations can be mastered in 30 minutes. For common issues like modifying commit messages, use `--amend`.
Read MoreGit Ignore Files: Other Exclusion Methods Besides .gitignore
Git, besides `.gitignore`, offers multiple ways to ignore files for different scenarios. `.git/info/exclude` is only for the local repository and its rules are not shared; directly add ignore rules here (e.g., personal IDE configurations). `git update-index --assume-unchanged` is used for tracked files to prevent Git from checking modifications (e.g., local configuration files). `--skip-worktree` is stricter, prohibiting Git from tracking sensitive files (e.g., passwords). `git rm --cached` can remove a tracked file from the repository while keeping it locally. Selection guide: Use `.gitignore` for daily general rules to share them, use `.git/info/exclude` for local personal needs, apply the above two for ignoring already tracked files, and use `git rm --cached` to remove files. Mastering these allows flexible management of the tracking scope, avoiding repository bloat or information leakage.
Read MoreGit Repository Backup: A Comprehensive Plan for Regular Backups and Restorations
Git repository backup is crucial for ensuring code security, as it encompasses code, historical records, and branch information. Local corruption, accidental deletion by remote users, or platform failures can all lead to code loss, making regular backups essential. The core principles include multiple backups (local + remote), regular execution, and verification of recovery. For local backups: Copy the repository folder (using `cp -r` for Linux/Mac and direct copying for Windows), with regular updates. For remote backups: Utilize multi-platform backup strategies (e.g., associating two remote addresses) and export using `git bundle` to mitigate platform-specific risks. Automated backups are more reliable: Use `crontab` for Linux/Mac to schedule scripts, and Task Scheduler for Windows. In case of recovery, local corruption can be addressed by overwriting with backups, while remote corruption can be resolved by cloning or using `bundle` files. Key considerations: Separate backup paths, retain the `.git` directory, and conduct regular recovery tests. Adopting the habit of "regular local copying + multi-platform remote backups" ensures code security.
Read MoreGit Log Viewing: log Command Parameters and Commit History Analysis
This article introduces the importance and usage of Git logs. Viewing Git logs allows you to understand commit records (who, when, and what was modified), project iteration trajectories, and also helps in locating issues. The basic command `git log` displays commit IDs, authors, times, and commit messages. Common parameters include: `--oneline` for simplified display, showing one commit per line; `-p` to display code differences (diff); `-n` to limit the number of commits (e.g., `-n 3`); `--graph` for graphical representation of branch merges; `--author` to filter by author, `--since`/`--before` to filter by time range; and `--color` for colored output. When analyzing logs, you can quickly pinpoint issues and understand branch logic. Clear commit messages (e.g., "Fix login button") can enhance collaboration efficiency. Mastering these parameters is key to efficient version control.
Read MoreDetailed Explanation of Git Workflow: Complete Process from Feature Branches to Main Branch
Git workflow serves as the "traffic rules" for team collaboration, stipulating code submission, merging, and version management rules to ensure orderly collaboration. A simplified Git Flow strategy is recommended: the main branch (`main`) stores stable deployable code, feature branches (e.g., `feature/xxx`) are developed independently, and merged into the main branch after completion and testing. Essential basic commands include cloning, creating a branch (`git checkout -b`), staging (`git add .`), committing (`git commit`), pulling (`git pull`), merging (`git merge`), and pushing (`git push`). Taking the development of the login feature as an example, the complete workflow steps are: 1. Ensure the main branch (`main`) is up-to-date (`git checkout main` + `git pull`); 2. Create a feature branch (`git checkout -b feature/login`); 3. After development, commit (`git status` + `add` + `commit`); 4. Synchronize with main branch updates (pull main branch and merge); 5. Push the feature branch to the remote; 6. Merge into the main branch (via PR if applicable) and clean up the branch. When conflicts occur, manually edit the conflict file (remove `<<<<<<<`
Read More