说实话，很多科研人员在写Fortran时往往把代码当成“一次性实验”。等到项目需要多人合作或长期维护时却发现根本没有办法追踪改动、回滚错误。别慌！只要把Git搬进你的Linux工作站， 再配合fpm就能把“散落的源码”变成可复现、可共享的精品工程，挖野菜。。

一、 准备工作：装好 Git 与编译器

我整个人都不好了。 在大多数发行版上，Git几乎是标配。如果你还没装， 只需几行命令：

# Ubuntu/Debian 系列
sudo apt update
sudo apt install -y git
# CentOS / RHEL
sudo yum install -y git

接着检查一下版本：

git --version   # 如显示 git version 2.34.1，说明已经就绪

至于 Fortran 编译器，常见的有 gfortranIntel OneAPI Fortran 和 NVIDIA HPC SDK。下面给出一个切换 gfortran 版本的小技巧：

# 安装多个版本
sudo apt install -y gfortran-10 gfortran-12
# 使用 update-alternatives 统一管理
sudo update-alternatives --config gfortran

二、 仓库初始化与基本操作

打开终端，进入你的源码根目录，施行：

# 创建 Git 仓库
cd /home/user/physics_sim/
git init
# 把所有 Fortran 源码加入暂存区
git add *.f90 *.f *.F95
# 首次提交
git commit -m "🚀 初始提交：搭建框架"

将心比心... 如果你计划将代码托管到远程平台，别忘了关联远程地址：

# 示例：GitHub
git remote add origin https://github.com/username/physics_sim.git
git branch -M main
git push -u origin main

.gitignore 的小秘籍

YYDS... .mod、.o、编译产生的二进制文件以及 IDE 的配置文件，都不该进入仓库。下面是一段常用的忽略规则：

# .gitignore 示例
*.o
*.mod
*.so
*.a
/build/
/*.exe
/.vscode/
/.idea/

三、让 fpm 成为你的构建伙伴

fpm 是 Fortran 社区近几年崛起的“包管理+构建系统”。它天然依赖 Git， 用 fpm.toml 描述项目元信息，一键生成可复现的构建产物，探探路。。

my_fpm_app/
├── fpm.toml
├── src/
│   └── main.f90
└── test/
    └── test_main.f90
        

常用命令一目了然：

# 创建新项目
fpm new my_fpm_app
# 编译并运行示例程序
fpm run
# 施行全部单元测试
fpm test
# 打包发布
fpm publish --target github-release

把 fpm 与 Git 串联起来的诀窍：

• .gitattributes: 对源码使用 UTF-8 编码，避免跨平台出现乱码。
• .git/hooks/pre-commit: 在提交前自动运行 fpm test && fpm fmt --check确保每一次 push 都是干净的。
• tag 策略: 每次发布稳定版时 用语义化标签标记，这样 CI 能自动抓取对应源码进行构建。

四、 分支管理策略：让协作不再“踩坑”

下面是一套适合科研团队的小分支模型，既保留主线稳定，又能灵活实验：

Main: 永远保持可部署状态，只接受已通过 CI 的 Merge Request。 Develop: 日常开发分支， 每天都可能有人 push，新功能先在这里孵化。 Feature/: 针对具体功能或算法实现， 如 feature/new-radiation-model Patches/:: 用来快速修复紧急 bug，比方说 Patches/fix-memory-leak Sprint/*:: 按照科研周期划分的大任务块，可在 sprint 完结后合并到 develop。 \end{ul}，原来如此。

顺便说一句， 这套模型并不是硬性规定，你可以根据实验室规模自行裁剪，只要保持“谁改了什么”和“何时合并”两条原则，就能让代码审查变得轻松愉快，哎，对！。

Merging 与 Rebase 的取舍

If you love a linear history ， 可以使用：

# 拉取最新主线后 rebase 本地分支
git fetch origin
git rebase origin/main
# 合并回 develop 时使用 fast‑forward 或者 --no‑ff 保留记录：
git checkout develop && git merge --no-ff feature/new-model -m "🔧 合并新模型"
        

If you prefer preserving each merge commit ， 得了吧... 直接使用普通的 merge 即可。

五、 CI/CD：让每一次提交都有“平安网”

A CI 流水线不仅能帮你自动跑测试，还能在不同编译器下交叉验证。下面给出一个基于 GitHub Actions 的简易配置示例， 仅供参考：，你没事吧？

name: Fortran CI
on:
  push:
    branches: 
  pull_request:
jobs:
  build-test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        compiler: 
        opt: 
    steps:
      - uses: actions/checkout@v3
      - name: Install compiler ${{ matrix.compiler }}
        run: |
          sudo apt-get update && sudo apt-get install -y ${{ matrix.compiler }}
      - name: Install fpm & dependencies
        run: |
          curl -sSfL https://github.com/fortran-lang/fpm/releases/latest/download/fpm-linux-x86_64.tar.gz | tar xz && sudo mv fpm /usr/local/bin/
      - name: Build with ${{ matrix.compiler }} ${{ matrix.opt }}
        env:
          FC: ${{ matrix.compiler }}
          FFLAGS: "-${{ matrix.opt }}"
        run: |
          fpm build --profile release
      - name: Run tests
        run: |
          fpm test --profile release
      - name: Upload artifacts 
        if: success
        uses: actions/upload-artifact@v3
        with:
          name: binaries-${{ matrix.compiler }}-${{ matrix.opt }}
          path: ./build/*
                

This workflow 会在每次 push 或 PR 时以两种 gfortran 版本和两种优化等级交叉编译，并施行全部单元测试。只要有一次失败，你立刻收到邮件提醒——再也不用担心 “本地跑得通，却在服务器炸掉”。

六、进阶小技巧 & 常见坑点排查

我可是吃过亏的。 想象一下 当所有成员都能“一键 Pull → 编译 → 测试”，而不必手动拷贝 .o 文件或纠结于不同机器上的路径差异，那种畅快感真的像打开了新世界的大门！💡 别忘了 每次成功合并后在 README 或 Wiki 上记录关键决策——这不仅是技术文档，更是团队记忆的沉淀。

七、 ：从零到熟练，只差一步行动

Eureka！只要把 Git 当成日常编辑器的一部分， 把 fpm 当作项目骨架，把 CI 当作质量守门员，你的 Fortran 项目就会拥有像商业软件一样的可靠性和可维护性。无论是单人独研还是跨校合作， 这套流程都能帮助你轻松追踪每一次算法改动，每一次性能调优，以及每一次意外 bug 的根源所在。

现在就打开终端吧——输入第一条 cd ~/my_fortran_project && git init && git add . && git commit -m "🎉 项目起航", 然后看着它在远程仓库里闪闪发光，你会发现原来科研编码也可以这么有仪式感！祝你玩得开心， 代码永远干净如新 🚀.，内卷...