Django 初学者指南：使用 GitHub 管理项目 – wiki基地

作者： /

Django 初学者指南：使用 GitHub 管理项目

作为一名 Django 初学者，你可能正沉浸在模型、视图、模板的世界里，享受着构建第一个 Web 应用的乐趣。但随着项目代码的不断增长，你很快会遇到一个问题：如何有效地跟踪代码的变更？如何回溯到之前的版本？如果和他人协作，又该如何协调工作？

答案是：使用版本控制系统（Version Control System, VCS）。而 Git 是目前最流行、最强大的分布式版本控制系统，GitHub 则是基于 Git 的、全球最大的代码托管平台，为开发者提供了强大的协作和项目管理工具。

对于 Django 初学者而言，掌握 Git 和 GitHub 不仅能解决代码管理问题，更是迈向专业开发者的重要一步。它能帮助你：

  1. 保存历史记录： 随时查看、比较、甚至回退到项目历史上的任何一个版本。
  2. 协作开发： 与团队成员高效地共同开发一个项目。
  3. 备份代码： 代码安全地存储在云端，不怕本地硬盘损坏。
  4. 展示作品： GitHub 是展示你项目和技能的最佳平台。
  5. 学习与成长： 通过查看他人的开源项目代码，学习最佳实践。

本文将手把手地带领 Django 初学者，从零开始学习如何将你的 Django 项目纳入 Git 版本控制，并推送到 GitHub 进行管理。我们将详细讲解每一步的操作和背后的原理。

第一部分：准备工作 – Git 的安装与配置

在开始之前，你需要确保你的电脑上已经安装了 Git。

1. 安装 Git

Git 的安装非常简单，根据你的操作系统选择相应的方法：

  • Windows:
    • 访问 Git 官网 (https://git-scm.com/download/win) 下载安装包。
    • 运行安装程序，大部分选项保持默认即可。建议选择在命令行中使用 Git，以及选择一个你习惯的文本编辑器（例如 VS Code, Sublime Text 等）。
  • macOS:
    • 最简单的方法是安装 Homebrew（如果你还没有的话）：/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
    • 然后使用 Homebrew 安装 Git：brew install git
    • 或者，安装 Xcode Command Line Tools 也会包含 Git：在终端中运行 xcode-select --install。
  • Linux (Debian/Ubuntu):
    • 打开终端，运行：sudo apt update
    • 然后运行：sudo apt install git
  • Linux (Fedora):
    • 打开终端，运行：sudo dnf install git

安装完成后，打开你的终端或命令提示符，输入以下命令来验证 Git 是否安装成功：

bash
git --version

如果输出了 Git 的版本号，说明安装成功。

2. 配置 Git

在使用 Git 之前，你需要设置你的用户名和邮箱地址。这些信息会关联到你的每一次提交（commit），方便追溯是谁做了哪些修改。

在终端中运行以下命令，将 你的名字 和 你的邮箱 替换为你自己的信息：

bash
git config --global user.name "你的名字"
git config --global user.email "你的邮箱"

--global 参数表示这些设置将应用于你系统上的所有 Git 仓库。如果你想为某个特定的项目使用不同的名字或邮箱，可以在该项目目录下执行同样的命令，但不带 --global 参数。

3. 注册 GitHub 账号

如果你还没有 GitHub 账号，现在是时候注册一个了。访问 GitHub 官网 (https://github.com/)，点击 “Sign up” 按钮，按照提示填写信息完成注册。GitHub 提供了免费的个人账号，对于初学者管理个人项目完全足够。

第二部分：将现有的 Django 项目纳入 Git 管理

假设你已经有一个本地的 Django 项目（例如，你跟着官方教程创建的 mysite 项目），现在我们来看如何把它变成一个 Git 仓库并推送到 GitHub。

1. 初始化本地 Git 仓库

打开你的终端或命令提示符，导航到你的 Django 项目的根目录。这个目录通常是包含 manage.py 文件的那个目录。

bash
cd path/to/your/django/project

然后，在这个目录下运行以下命令来初始化一个本地 Git 仓库：

bash
git init

执行这个命令后，Git 会在当前目录下创建一个名为 .git 的隐藏文件夹。这个文件夹包含了 Git 仓库的所有信息，包括版本历史、配置等。请不要手动修改或删除这个文件夹。

运行 git init 后，Git 会显示类似这样的信息：

Initialized empty Git repository in /path/to/your/django/project/.git/

2. 检查工作区状态 (git status)

初始化仓库后，你可以使用 git status 命令来查看当前工作区的状态。

bash
git status

第一次运行 git status，你会看到 Git 告诉你有很多 “Untracked files”（未跟踪的文件），这些就是你项目中的所有文件和文件夹。

“`
On branch master

No commits yet

Untracked files:
(use “git add …” to include in what will be committed)
.gitignore
db.sqlite3
manage.py
mysite/
requirements.txt
… (your project files)

nothing added to commit but untracked files present (use “git add” to track)
“`

这说明 Git 已经知道这些文件的存在，但还没有将它们添加到版本控制中。

3. 创建 .gitignore 文件

这一步对于 Django 项目至关重要！有些文件或目录我们不应该添加到 Git 仓库中，例如：

  • 虚拟环境目录: 通常命名为 venv, env 等。这些包含了特定于你环境的 Python 库，不同开发者环境可能不同，不应共享。
  • 数据库文件: 如 db.sqlite3。这个文件存储了你的本地开发数据，通常不需要版本控制，而且可能会包含敏感信息。
  • 本地设置文件: 如果你有单独的本地设置文件（如 settings_local.py），可能包含数据库密码、密钥等敏感信息，不应添加到仓库。即使没有单独文件，主 settings.py 中的 SECRET_KEY 也不应直接暴露在公开仓库中（稍后解释如何处理）。
  • 编译生成的文件: 如 .pyc 文件，静态文件收集后的目录（staticfiles），媒体文件目录（mediafiles）。
  • IDE 配置文件: 编辑器或 IDE 可能会生成一些项目配置或用户设置文件。

为了告诉 Git 忽略这些文件和目录，我们需要在项目根目录创建一个名为 .gitignore 的文件。

在项目根目录创建 .gitignore 文件（注意文件名开头的点），然后用文本编辑器打开它，添加以下常见于 Django 项目的忽略规则：

“`gitignore

Byte-code files

*.pyc

Directories

venv/
env/
pycache/
staticfiles/
media/

Database

db.sqlite3

Django specific files

.log
.pot
*.mo

Sensitive settings (if you have a local settings file)

settings_local.py

如果你的 settings.py 直接包含 SECRET_KEY，考虑将其移到环境变量或单独的文件

或使用其他安全方式处理。如果只是初学，确保不上传包含真实密钥的公开仓库。

For production, move SECRET_KEY to environment variables or a separate file not tracked by Git.

IDE-specific files (examples for popular IDEs)

.vscode/
.idea/
.iml
.swp # Vim swap files

OS temporary files

.DS_Store # macOS
Thumbs.db # Windows
“`

解释：
* # 开头的行是注释。
* 直接写文件名或目录名表示忽略该文件或目录（及其内容）。
* / 结尾表示只忽略目录。
* * 是通配符。

保存 .gitignore 文件后，再次运行 git status：

bash
git status

你会发现 .gitignore 文件现在显示为 “Untracked files”（因为它是一个新创建的文件），而你刚才添加到 .gitignore 中的文件（如 db.sqlite3, venv/ 等）应该已经不再出现在未跟踪文件列表中了。这是一个好迹象！

4. 将文件添加到暂存区 (git add)

现在，我们需要告诉 Git 哪些文件是你想要纳入版本控制的。这个操作叫做将文件添加到“暂存区”（staging area）。暂存区是下一次提交的准备区域。

你可以逐个添加文件，或者添加整个目录，或者添加所有修改过的文件。

为了添加项目中的所有文件（除了 .gitignore 中指定的），可以在项目根目录运行：

bash
git add .

注意命令最后的点 . 表示当前目录。这个命令会递归地将当前目录下的所有未忽略的文件和目录添加到暂存区。

再次运行 git status：

bash
git status

你会看到文件的状态从 “Untracked files” 变成了 “Changes to be committed”（将要被提交的更改），并且文件名前面是绿色的。这说明这些文件已经成功添加到了暂存区。.gitignore 文件也应该在暂存区列表中。

“`
On branch master

No commits yet

Changes to be committed:
(use “git rm –cached …” to unstage)
new file: .gitignore
new file: manage.py
new file: mysite/init.py
new file: mysite/asgi.py
new file: mysite/settings.py
new file: mysite/urls.py
new file: mysite/wsgi.py
new file: requirements.txt
… (other project files)
“`

5. 提交更改 (git commit)

文件进入暂存区后，就可以进行提交了。提交（commit）是将暂存区的所有文件快照永久地保存在 Git 仓库的历史记录中，形成一个版本。每一次提交都应该代表一个完整、独立的逻辑变更单元。

使用以下命令进行提交：

bash
git commit -m "Initial commit of Django project"

-m 参数用于直接在命令行提供提交信息（commit message）。提交信息非常重要，应该清晰、简洁地描述本次提交做了什么。对于第一次提交，通常使用 “Initial commit” 或类似的描述。

执行 git commit 后，Git 会显示本次提交的详细信息，例如提交的哈希值、作者、日期以及提交信息，并告诉你有多少文件被改变，多少行被插入或删除。

[master (root-commit) 1234567] Initial commit of Django project
25 files changed, 875 insertions(+)
create mode 100644 .gitignore
create mode 100755 manage.py
...

现在，你的本地 Django 项目已经有了第一个版本历史记录！

再次运行 git status：

bash
git status

你会看到类似 “nothing to commit, working tree clean” 的信息，这说明当前工作区是干净的，没有未跟踪或未暂存的修改。

第三部分：连接本地仓库与 GitHub

你的项目现在是一个本地 Git 仓库了，接下来我们将它连接到 GitHub 上的一个远程仓库。

1. 在 GitHub 上创建新的仓库

登录你的 GitHub 账号，点击页面右上角的 “+” 图标，选择 “New repository”（新建仓库）。

在创建页面：

  • Repository name (仓库名称): 输入你的项目名称（例如 my-django-project）。这个名称将成为仓库在 GitHub 上的 URL 的一部分。
  • Description (描述): 可选，简要描述你的项目。
  • Public 或 Private:
    • Public (公开): 所有人都可以查看你的代码。适合开源项目或用于展示个人作品。
    • Private (私有): 只有你和明确授权的用户才能访问。适合包含敏感信息或不希望公开的项目。初学者可以选择 Private，如果想作为作品展示可以选择 Public。
  • Initialize this repository with: 不要勾选 “Add a README file”, “Add .gitignore”, “Choose a license”。因为你已经在本地有了 .gitignore 文件和项目代码，勾选这些会创建冲突。

点击绿色的 “Create repository” 按钮。

创建成功后，GitHub 会显示一个页面，提供了一些将现有本地仓库关联到此远程仓库的命令。找到类似 “…or push an existing repository from the command line” 的部分。它会提供类似下面的两行命令：

bash
git remote add origin https://github.com/your_username/my-django-project.git
git branch -M main # 或者 git branch -M master，取决于你本地分支名和GitHub默认设置
git push -u origin main

2. 关联本地仓库与远程仓库

回到你的项目根目录的终端中，执行 GitHub 提供的第一条命令：

bash
git remote add origin https://github.com/your_username/my-django-project.git

请将 your_username 替换为你的 GitHub 用户名，将 my-django-project.git 替换为你刚才创建的仓库名称。

git remote add origin <远程仓库URL> 命令的作用是为远程仓库的 URL 设置一个别名。通常我们将主远程仓库的别名设置为 origin。这样以后我们就可以直接使用 origin 来代替整个 URL 了。

3. 重命名本地主分支 (可选但推荐)

Git 社区正在逐步将默认的主分支名称从 master 改为 main，以避免一些历史上的不当联想。GitHub 新建的仓库默认主分支也是 main。为了保持一致，如果你本地的主分支是 master，可以使用以下命令将其重命名为 main：

bash
git branch -M main

如果你本地主分支已经是 main，则跳过此步。你可以通过 git status 或 git branch 命令查看当前所在分支。

4. 推送本地提交到 GitHub (git push)

现在，你可以将本地仓库的提交推送到关联的远程仓库了。

执行 GitHub 提供的第三条命令：

bash
git push -u origin main

  • git push: 将本地的提交上传到远程仓库。
  • -u: 这是 --set-upstream-to 的简写。第一次推送时使用此参数，它会将本地的当前分支（main）与远程仓库 origin 的 main 分支关联起来。之后，你就可以直接使用 git push 和 git pull 命令，而无需指定 origin main 了。
  • origin: 远程仓库的别名。
  • main: 要推送的本地分支名称。

执行 git push 后，Git 可能会要求你输入 GitHub 的用户名和密码，或者使用 Personal Access Token (PAT) 进行身份验证。GitHub 已经不再支持直接使用密码通过 Git 进行身份验证，推荐使用 PAT。如果你是第一次设置，可能需要按照提示或 GitHub 官方文档配置 PAT 或 SSH Key。使用 SSH Key 是更方便且安全的推荐方式。

推送成功后，访问你的 GitHub 仓库页面，刷新一下，你就能看到你的 Django 项目代码已经成功地上传到了 GitHub 上！

第四部分：日常开发与 Git 工作流

现在你的项目已经在 GitHub 上了，接下来的日常开发中，你会频繁使用 Git 来管理你的代码变更。以下是一个基本的开发工作流：

1. 查看状态 (git status)

在开始工作前或进行任何 Git 操作前，先使用 git status 查看当前仓库的状态，了解哪些文件被修改、哪些是新文件等。

bash
git status

2. 拉取远程仓库的最新代码 (git pull)

如果你的项目是多人协作，或者你在不同的电脑上开发，开始工作前应该先从远程仓库拉取最新的代码，避免冲突。

bash
git pull origin main

或者，如果你之前使用了 -u 参数设置了上游分支，直接使用：

bash
git pull

git pull 实际上是两个命令的组合：git fetch（从远程仓库下载最新提交）和 git merge（将下载的提交合并到当前本地分支）。

3. 进行代码修改

在你的 Django 项目中自由地修改代码，添加新功能，修复 Bug 等。

4. 再次检查状态 (git status)

修改完成后，再次运行 git status，你会看到 Git 列出了所有被修改（modified）、新添加（untracked）或删除（deleted）的文件。

bash
git status

“`
On branch main
Your branch is up to date with ‘origin/main’.

Changes not staged for commit:
(use “git add …” to include in what will be committed)
modified: myapp/views.py

Untracked files:
(use “git add …” to include in what will be committed)
myapp/templates/myapp/new_template.html

no changes added to commit (use “git add” and/or “git commit -a)”)
“`

5. 将修改添加到暂存区 (git add)

选择你想要包含在下一次提交中的文件，将它们添加到暂存区。

“`bash

添加单个文件

git add myapp/views.py

添加多个文件

git add myapp/views.py myapp/templates/myapp/new_template.html

添加当前目录下所有修改和新文件（但注意不要误加不需要的文件）

git add .
“`

运行 git status 确认文件已进入暂存区（显示为绿色）。

6. 提交更改 (git commit)

提交暂存区的更改，并编写清晰的提交信息。

bash
git commit -m "Feat: Add welcome message to myapp homepage"

提交信息格式建议：
* 第一行是简短的总结（不超过50个字符），使用祈使句（Add, Fix, Refactor 等）。
* 空一行。
* 后面可以写详细的解释（每行不超过72个字符）。

良好的提交信息能帮助你和团队成员快速理解每次变更的目的和内容。

7. 推送提交到 GitHub (git push)

将本地的最新提交推送到远程仓库。

bash
git push origin main

或者，如果已设置上游分支：

bash
git push

这样，你的最新代码就同步到了 GitHub 上。

第五部分：分支管理 – 更好地组织开发

直接在 main 分支上进行所有开发对于初学者个人项目是可以的，但在实际开发中，尤其是有新功能开发或 Bug 修复时，推荐使用分支（Branch）。分支允许你在一个独立的环境中进行开发，而不会影响到主分支的稳定代码。

1. 理解分支

你可以把分支想象成项目的一个独立的、平行的版本线。main 分支通常代表了项目的稳定、可发布版本。当你开始一个新任务时，可以从 main 分支创建一个新的分支，在这个分支上进行开发，完成后再将这个分支合并回 main。

2. 创建并切换到新分支 (git checkout -b 或 git switch -c)

假设你要开发一个用户注册功能。你可以从 main 分支创建一个名为 feature/user-registration 的新分支，并立即切换到该分支：

使用较新的 git switch 命令：

bash
git switch -c feature/user-registration

或者使用传统的 git checkout 命令：

bash
git checkout -b feature/user-registration

git checkout -b <新分支名称> 是 git branch <新分支名称>（创建分支）和 git checkout <新分支名称>（切换到分支）这两个命令的组合。

运行 git status 会告诉你当前所在的分支：

bash
On branch feature/user-registration
...

3. 在新分支上进行开发、提交

现在你在 feature/user-registration 分支上。在这个分支上做的任何修改和提交都不会影响到 main 分支。按照前面介绍的日常工作流进行开发、添加、提交：

“`bash

修改代码…

git status
git add .
git commit -m “Feat: Implement user registration form”

修改更多代码…

git status
git add .
git commit -m “Feat: Add user registration view and URL”
“`

4. 切换回主分支 (git checkout 或 git switch)

如果你需要回到 main 分支（例如，查看主分支的代码，或者拉取最新的远程代码），可以切换回去：

“`bash
git switch main

或者

git checkout main
“`

注意： 在切换分支前，建议先提交或暂存当前分支上的所有修改，否则 Git 可能会阻止你切换，或者将你的修改带到新分支上（这可能会导致混乱）。

5. 合并分支 (git merge)

当你完成了 feature/user-registration 分支上的开发，并测试通过后，可以将这个分支的修改合并到 main 分支。

首先，切换回目标分支（通常是 main）：

“`bash
git switch main

或者

git checkout main
“`

然后，拉取 main 分支的最新代码，确保本地 main 是最新的（避免不必要的合并冲突）：

bash
git pull origin main

最后，将你的功能分支合并到当前所在的 main 分支：

bash
git merge feature/user-registration

如果合并过程中没有冲突，Git 会自动完成合并。如果出现冲突（同一个文件的同一部分在两个分支上有不同的修改），Git 会提示你解决冲突。解决冲突需要手动编辑文件，选择保留哪些修改，然后 git add 冲突文件，最后 git commit 提交合并结果。解决冲突是 Git 中相对复杂的部分，需要一些练习。

6. 删除分支 (git branch -d)

合并完成后，如果不再需要这个功能分支，可以将其删除：

bash
git branch -d feature/user-registration

-d 参数表示安全删除，只有当分支的提交已经完全合并到当前分支后才会成功。如果分支还没有合并，但你确定要删除（例如，放弃了这个功能），可以使用 -D 参数强制删除：git branch -D feature/user-registration。

7. 推送合并后的主分支

别忘了将合并了新功能的 main 分支推送到 GitHub：

bash
git push origin main

第六部分：GitHub 的协作功能 – Pull Request (PR)

虽然分支管理在本地很有用，但 GitHub 提供了更强大的协作工具：Pull Request (PR)，也常被称为 Merge Request (MR) 在其他平台上。

Pull Request 是一个通知机制：你告诉项目维护者（或者你自己，如果是个人项目）你已经完成了一些工作（在一个分支上），并请求将这些工作合并到主分支或其他目标分支。

PR 的好处：
* 代码审查: 允许其他人在代码合并前进行审查、提出意见或建议。
* 讨论: 可以在 PR 页面针对代码或功能进行讨论。
* 自动化检查: 可以集成持续集成/持续部署 (CI/CD) 工具，在合并前自动运行测试、代码风格检查等。

Pull Request 的基本流程:

  1. 从 main 分支创建并切换到一个新的功能分支（如 feature/new-feature）。
  2. 在新分支上进行开发、添加、提交，直到功能完成。
  3. 将功能分支推送到 GitHub：git push origin feature/new-feature。因为这是你第一次推送这个新分支，可能需要使用 -u 参数：git push -u origin feature/new-feature。
  4. 在 GitHub 上创建 Pull Request: 访问你的 GitHub 仓库页面，GitHub 通常会提示你刚刚推送了一个新分支，并提供一个按钮让你方便地创建 Pull Request。你也可以点击 “Pull requests” 标签页，然后点击 “New pull request” 按钮。
  5. 填写 PR 信息: 选择要合并的源分支（你的 feature/new-feature）和目标分支（通常是 main）。填写清晰的标题和描述，说明本次 PR 的目的、解决了什么问题、做了哪些改动等。
  6. 提交 PR: 创建 PR 后，项目的协作者或维护者（如果是你个人项目，就是你自己）可以查看代码改动，并在 PR 页面进行评论。
  7. 代码审查与修改: 根据反馈进行代码修改。修改后，在本地功能分支上提交并再次推送到 GitHub (git push)。这些新的提交会自动关联到你的 PR。
  8. 合并 PR: 当代码审查通过，并且所有自动化检查（如果设置了）都通过后，项目维护者可以将你的功能分支合并到目标分支（如 main）。在 GitHub 页面点击 “Merge pull request” 按钮即可完成。
  9. 删除远程分支 (可选): 合并后，GitHub 通常会提供一个选项让你删除已经合并的功能分支。删除远程分支的命令是 git push origin --delete <分支名称>。

对于个人项目，你可以通过 PR 来模拟多人协作流程，强迫自己进行代码审查（即使是自己审查自己的代码），这有助于发现潜在问题并养成良好的习惯。

第七部分：GitHub Issues – 简单的任务管理

GitHub 还提供了 Issues 功能，可以作为简单的任务管理或 Bug 追踪工具。

你可以在 “Issues” 标签页创建新的 Issue，描述一个 Bug、一个新功能需求或一个待办事项。你可以在 Issue 中讨论、分配给某个成员（如果你有协作者）、添加标签等。

在你的提交信息或 Pull Request 描述中，你可以通过特定的关键词（如 Fix #<Issue编号>, Close #<Issue编号>, Resolve #<Issue编号>）关联到某个 Issue。当包含这些关键词的提交或 PR 被合并到默认分支（通常是 main）时，GitHub 会自动关闭关联的 Issue。

这对于初学者规划项目、记录 Bug 和跟踪进度非常有帮助。

第八部分：Git 与 GitHub 的最佳实践（针对 Django 项目）

  1. 频繁提交: 不要等到完成一个大功能才提交。每次完成一个小的、独立的逻辑单元就提交一次。这样即使后续代码出错，回溯和调试也会更容易。
  2. 清晰的提交信息: 编写有意义的提交信息，说明本次提交的目的和内容。
  3. 正确使用 .gitignore: 确保敏感信息（如 SECRET_KEY）、数据库文件、虚拟环境、编译生成的文件等被忽略。对于 SECRET_KEY，在生产环境中应使用环境变量或其他安全方式获取，而不是硬编码在 settings.py 中并上传到仓库。
  4. 使用虚拟环境: 始终为你的 Django 项目使用虚拟环境。这能隔离项目依赖，避免不同项目之间的库版本冲突。将 requirements.txt（记录项目依赖）添加到 Git 仓库，但忽略虚拟环境目录本身。你可以使用 pip freeze > requirements.txt 命令生成 requirements.txt 文件。
  5. 保持 main 分支的整洁和稳定: 重要的功能开发或 Bug 修复应该在单独的分支上进行。只有经过测试、确认稳定后，才合并到 main 分支。
  6. 定期推送到 GitHub: 不要把代码只留在本地。定期（例如每天工作结束时）推送到 GitHub，既是备份，也方便在不同设备间同步。
  7. 保护 main 分支 (可选): 在 GitHub 仓库设置中，可以为 main 分支设置保护规则，例如要求 Pull Request 必须通过状态检查（如自动化测试）、必须有指定数量的批准评论后才能合并。这对于团队协作或个人项目的质量控制很有用。
  8. 使用 SSH Keys 进行认证 (推荐): 相比HTTPS + PAT，使用 SSH Keys 更加方便和安全，无需每次推送都输入密码或 PAT。GitHub 文档有详细的配置教程。

第九部分：常见问题与故障排除

  • 忘记 git add: 如果你修改了文件但没有 git add 就尝试 git commit，Git 会告诉你 “nothing added to commit”。记得先 git add . 或 git add <文件>。
  • 提交信息写错了: 如果是最近一次提交且还没有推送到远程，可以使用 git commit --amend 来修改提交信息。这会替换掉最近的一次提交。
  • 推送被拒绝 (rejected): 通常是因为远程仓库的 main 分支有了新的提交，而你本地的 main 分支不是最新的。先执行 git pull 拉取最新代码，解决可能的合并冲突，然后再 git push。
  • 忽略文件 .gitignore 不生效:
    • 检查 .gitignore 文件名是否正确（注意开头的点）。
    • 检查 .gitignore 文件是否在项目根目录。
    • 如果文件在添加到 .gitignore 之前已经被 Git 跟踪了，忽略规则就不会生效。你需要先将该文件从 Git 跟踪中移除（但保留本地文件）：git rm --cached <文件路径>，然后提交这个移除操作，之后再进行新的修改和提交，Git 就会开始忽略它了。
  • 认证问题: 推送时提示认证失败。检查 GitHub 用户名密码是否正确（如果是通过 HTTPS 方式使用 PAT），或者 SSH Key 是否配置正确并添加到了 GitHub 账户。GitHub 已经弃用了使用账户密码直接通过 Git 进行认证的方式。
  • 合并冲突: Git 会提示哪些文件有冲突。打开这些文件，你会看到 Git 用 <<<<<<<, =======, >>>>>>> 标记出了冲突的部分。手动编辑文件，删除这些标记，保留你想要的代码。解决完所有冲突文件后，git add 这些文件，然后 git commit 完成合并提交。

总结

恭喜你！通过本文的学习，你已经掌握了将 Django 项目纳入 Git 版本控制并推送到 GitHub 的基本方法。这包括了 Git 的安装配置、本地仓库的初始化、.gitignore 的创建与作用、基本的 add-commit-push 工作流、分支的使用、以及 GitHub 的 Pull Request 和 Issues 功能。

从现在开始，为你的每一个 Django 项目使用 Git 和 GitHub 吧。这不仅仅是代码管理工具，更是提升开发效率、保障代码安全、 facilitating collaboration，and building your developer portfolio 的强大助力。

持续实践、不断探索 Git 和 GitHub 的更多高级功能（如 rebase, stash, submodule, Actions, Pages 等），你将成为一名更有效率、更专业的开发者。祝你在 Django 和 Git/GitHub 的学习旅程中一切顺利！

发表评论

您的邮箱地址不会被公开。 必填项已用 * 标注

滚动至顶部