同步操作将从 PaddlePaddle/PaddleClas 强制同步,此操作会覆盖自 Fork 仓库以来所做的任何修改,且无法恢复!!!
确定后同步将在后台操作,完成时将刷新页面,请耐心等待。
PaddleClas 未来将维护 2 种分支,分别为:
PaddleClas 的历史分支,未来将不再维护。考虑到一些同学可能仍在使用,这些分支还会继续保留:
PaddleClas 欢迎大家向 repo 中积极贡献代码,下面给出一些贡献代码的基本流程。
https://github.com/USERNAME/PaddleClas
。# 拉取 develop 分支的代码
git clone https://github.com/USERNAME/PaddleClas.git -b develop
cd PaddleClas
clone 的地址可以从下面获取
首先通过 git remote -v
查看当前远程仓库的信息。
origin https://github.com/USERNAME/PaddleClas.git (fetch)
origin https://github.com/USERNAME/PaddleClas.git (push)
上面的信息只包含了 clone 的远程仓库的信息,也就是自己用户名下的 PaddleClas,接下来我们创建一个原始 PaddleClas 仓库的远程主机,命名为 upstream 。
git remote add upstream https://github.com/PaddlePaddle/PaddleClas.git
使用 git remote -v
查看当前远程仓库的信息,输出如下,发现包括了 origin 和 upstream 2 个远程仓库。
origin https://github.com/USERNAME/PaddleClas.git (fetch)
origin https://github.com/USERNAME/PaddleClas.git (push)
upstream https://github.com/PaddlePaddle/PaddleClas.git (fetch)
upstream https://github.com/PaddlePaddle/PaddleClas.git (push)
这主要是为了后续在提交 pull request(PR)时,始终保持本地仓库最新。
可以基于当前分支创建新的本地分支,命令如下。
git checkout -b new_branch
也可以基于远程或者上游的分支创建新的分支,命令如下。
# 基于用户远程仓库(origin)的 develop 创建 new_branch 分支
git checkout -b new_branch origin/develop
# 基于上游远程仓库(upstream)的 develop 创建 new_branch 分支
# 如果需要从 upstream 创建新的分支,需要首先使用 git fetch upstream 获取上游代码
git checkout -b new_branch upstream/develop
最终会显示切换到新的分支,输出信息如下
Branch new_branch set up to track remote branch develop from upstream.
Switched to a new branch 'new_branch'
Paddle 开发人员使用 pre-commit 工具来管理 Git 预提交钩子。 它可以帮助我们格式化源代码(C++,Python),在提交(commit)前自动检查一些基本事宜(如每个文件只有一个 EOL,Git 中不要添加大文件等)。
pre-commit 测试是 Travis-CI 中单元测试的一部分,不满足钩子的 PR 不能被提交到 PaddleClas,首先安装并在当前目录运行它:
pip install pre-commit
pre-commit install
clang-format
版本在 3.8 以上。pip install pre-commit
和 conda install -c conda-forge pre-commit
安装的 yapf
稍有不同的,PaddleClas 开发人员使用的是 pip install pre-commit
。可以通过 git status
查看改动的文件。
对 PaddleClas 的 README.md
做了一些修改,希望提交上去。则可以通过以下步骤
git add README.md
pre-commit
重复上述步骤,直到 pre-comit 格式检查不报错。如下所示。
使用下面的命令完成提交。
git commit -m "your commit info"
获取 upstream 的最新代码并更新当前分支。这里的 upstream 来自于 1.2 节的和远程仓库建立连接
部分。
git fetch upstream
# 如果是希望提交到其他分支,则需要从 upstream 的其他分支 pull 代码,这里是 develop
git pull upstream develop
git push origin new_branch
点击 new pull request,选择本地分支和目标分支,如下图所示。在 PR 的描述说明中,填写该 PR 所完成的功能。接下来等待 review,如果有需要修改的地方,参照上述步骤更新 origin 中的对应分支即可。
Sign in with GitHub to agree
, 点击完成后将会跳转回您的 Pull Request 页面在 PR 被 merge 进主仓库后,我们可以在 PR 的页面删除远程仓库的分支。
也可以使用 git push origin :分支名
删除远程分支,如:
git push origin :new_branch
# 切换到 develop 分支,否则无法删除当前分支
git checkout develop
# 删除 new_branch 分支
git branch -D new_branch
为了使官方维护人员在评审代码时更好地专注于代码本身,请您每次提交代码时,遵守以下约定:
1)请保证 Travis-CI 中单元测试能顺利通过。如果没过,说明提交的代码存在问题,官方维护人员一般不做评审。
2)提交 Pull Request 前:
请注意 commit 的数量。
原因:如果仅仅修改一个文件但提交了十几个 commit,每个 commit 只做了少量的修改,这会给评审人带来很大困扰。评审人需要逐一查看每个 commit 才能知道做了哪些修改,且不排除 commit 之间的修改存在相互覆盖的情况。
建议:每次提交时,保持尽量少的 commit,可以通过 git commit --amend
补充上次的 commit 。对已经 Push 到远程仓库的多个 commit,可以参考 squash commits after push。
请注意每个 commit 的名称:应能反映当前 commit 的内容,不能太随意。
3)如果解决了某个 Issue 的问题,请在该 Pull Request 的第一个评论框中加上: fix #issue_number
,这样当该 Pull Request 被合并后,会自动关闭对应的 Issue 。关键词包括: close, closes, closed, fix, fixes, fixed, resolve, resolves, resolved,请选择合适的词汇。详细可参考 Closing issues via commit messages。
此外,在回复评审人意见时,请您遵守以下约定:
1)官方维护人员的每一个 review 意见都希望得到回复,这样会更好地提升开源社区的贡献。
2)如果评审意见比较多,
start a review
进行回复,而非直接回复的方式。原因是每个回复都会发送一封邮件,会造成邮件灾难。此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。