mirror of
https://github.com/LucasVbr/first-contributions.git
synced 2026-05-13 17:21:50 +00:00
Merge branch 'main' into denny-branch
This commit is contained in:
Roshan Jossy
+8
-2
@@ -1,5 +1,6 @@
|
||||
# Contributors
|
||||
- [Utkarsh Upreti] (https://www.github.com/K4rsh)
|
||||
- [Zaid Qtaish](https://github.com/ZaidQtaish)
|
||||
- [Raja Rathour](https://github.com/Raja-89)
|
||||
- [Viraj Hudlikar](https://github.com/vhudlikar)
|
||||
- [Muhammad Raza](https://github.com/RazaJavaid2004)
|
||||
@@ -22,6 +23,10 @@
|
||||
- [Amadou Kebe](https://github.com/AmadouLKebe)
|
||||
- [baldlow](https://github.com/baldlow) -[Mohit Kumar](https://github.com/MateeRixx)
|
||||
- [Pygame17](https://github.com/Pygame17)
|
||||
- [Jonatan Rosali](https://github.com/JonatanRosali)
|
||||
- [Jason Herman](https://github.com/Everblade)
|
||||
- [Jason Ephraim Tjiunardi](https://github.com/jasontjiunardi)
|
||||
- [Thaiyal Bagam Sanjeev](https://github.com/SugarCrash2077)
|
||||
- [Mohamednishar J](https://github.com/nisharj)
|
||||
- [anshuman](https://github.com/sahayanshuman2005)
|
||||
- [Anubhav Saha](https://github.com/anubhavtogit)
|
||||
@@ -1227,6 +1232,7 @@
|
||||
- [Jack](https://github.com/jackliDev)
|
||||
- [puchan-s](https://github.com/puchan-s/first-contributions)
|
||||
- [Hiruna Panditha](https://github.com/Hiruna-SP)
|
||||
- [nemdull](https://github.com/nemdull)
|
||||
- [tomasbennett](https://github.com/tomasbennett)
|
||||
- [Rahmatulloh Ibrohim](https://github.com/raxmatulloxswe/)
|
||||
- [Kostiantyn Semenenko](https://github.com/NureSemenenkoKostiantyn)
|
||||
@@ -1327,5 +1333,5 @@
|
||||
- [Ugesh Praavin D](https://github.com/Ugesh-Praavin)
|
||||
- [Sahil Motiramani](https://github.com/SahilMotiramani)
|
||||
- [Akash Thakur](https://github.com/Akash9541)
|
||||
-[Sahil Motiramani](https://github.com/SahilMotiramani)
|
||||
-[Rajat](https://github.com/Rajat-44)
|
||||
- [Rajat](https://github.com/Rajat-44)
|
||||
- [nemdull](https://github.com/nemdull)
|
||||
|
||||
@@ -0,0 +1,134 @@
|
||||
# プログラマーでない人ができること
|
||||
## 聞くことから始める
|
||||
|
||||
オープンソースに関わる全てのことは、他の人との関わりを伴います。
|
||||
あなたはチームに参加しようとしているわけで、それはコミュニティやその仕組みを理解することを意味します。
|
||||
プロジェクトに入って「こんにちは、このプロジェクトはこうあるべきだと思います」といきなり言うのは、通常あまり歓迎されません。
|
||||
もちろん、そういうアプローチを歓迎するプロジェクトもありますが、プロジェクトがある程度運営されている場合、その態度が受け入れられる可能性は低いです。
|
||||
**聞くことこそ、プロジェクトが本当に必要としていることを知る最良の方法です。**
|
||||
|
||||
1. **メーリングリストに参加する**: 多くのプロジェクトでは、メーリングリストがプロジェクト開発に関する主なコミュニケーション手段です。
|
||||
大規模なプロジェクトでは、選択できるメーリングリストが複数あります。
|
||||
例えば、PostgreSQLプロジェクトでは、ユーザー向けリストが12件以上、開発者向けリストが6件も存在します。
|
||||
まずはメインのユーザー向けリストとコア開発者向けリストをフォローして、内容を追ってみることから始めることをお勧めします。
|
||||
|
||||
2. **ブログをフォローする**: コア開発者が運営するブログは、今後のリリースで何が起こるのか、そしてそこに至るまでに何が必要だったかを教えてくれます。
|
||||
「Planetサイト」は、プロジェクトに関連する様々なニュースやブログ記事を集約しています。
|
||||
もし planet.gnome.org や planet.mysql.com のような Planet サイトがあれば、まずそこから始めましょう。
|
||||
Googleで「planet <projectname>」と検索するだけでも見つかります。
|
||||
|
||||
3. **IRCチャンネルに参加する**: 多くのオープンソースプロジェクトには、開発者やユーザーが集まって問題や開発について話し合う専用のIRCチャンネルがあります。
|
||||
プロジェクトのウェブサイトで、チャンネル名やどのIRCネットワークにあるかを確認してください。
|
||||
|
||||
## チケットを扱う
|
||||
コードはオープンソースプロジェクトの中心ですが、コードを書くことだけが貢献方法ではありません。
|
||||
コードやコード周辺のシステムのメンテナンスは、新機能の作成やバグ修正の急ぎでおろそかにされがちです。
|
||||
こうした領域は、プロジェクトに足を踏み入れる簡単な方法となります。
|
||||
ほとんどのプロジェクトには、プロジェクトのウェブサイトのトップページやドキュメントにリンクされた公開チケットシステムがあります。
|
||||
それはユーザーと開発者の間の主要なコミュニケーション手段です。最新の状態を維持することは、プロジェクトを助ける優れた方法です。
|
||||
チケットシステムで特別な権限が必要になる場合がありますが、ほとんどのプロジェクトリーダーは「チケットを整理して手伝いたい」と言えば喜んで権限を与えてくれます。
|
||||
|
||||
4. **バグを診断する**: バグ報告はしばしば不十分です。
|
||||
バグを診断し、優先順位を付けることで、開発者が問題の詳細を把握する手間を省くことができます。ユーザーが「Xをしたらソフトが動かない」と報告した場合、その問題を引き起こす具体的な条件を時間をかけて特定してみましょう。再現性はあるか？問題を繰り返し起こる手順を作れるか？特定のブラウザでのみ発生する、あるいは特定のディストリビューションでのみ起こるなど、問題を絞り込めるか？原因が分からなくても、条件を絞り込む努力は、誰かが修正する際に役立ちます。
|
||||
発見したことはすべてチケットに記録して、他の人も参照できるようにしましょう。
|
||||
|
||||
5. **修正済みバグを閉じる**: バグはコード上で修正されても、チケットシステムで更新されないことがあります。こうした未整理のチケットを整理するのは時間がかかりますが、プロジェクト全体にとって価値があります。まずはチケットシステムで1年以上前のチケットを検索し、そのバグがまだ存在するか確認します。プロジェクトのリリース変更ログをチェックして、バグが修正され閉じられるべきか確認します。修正済みであれば、チケットにバージョン番号を記載して閉じます。 最新バージョンのソフトウェアでバグを再現できるか試してください。再現できなければ、チケットにその旨を記録して閉じます。まだ存在する場合は、そのこともチケットに記録して、開いたままにします。
|
||||
|
||||
## コードに取り組む
|
||||
|
||||
あらゆる経験レベルのプログラマーは、プロジェクトのコードに貢献できます。
|
||||
自分が好きなプロジェクトに本当に貢献するために、コーディングの天才である必要はありません。
|
||||
|
||||
コードを修正する場合、プロジェクトが採用している、コントリビューターからコードを取得する方法を調べましょう。
|
||||
各プロジェクトには独自のワークフローがあるため、コードを提出する前に確認することが重要です。
|
||||
|
||||
例えば、PostgreSQLプロジェクトでは非常に厳密なプロセスがあり、コード修正はパッチ形式でメーリングリストに送られ、コア開発者が変更のすべてを精査します。
|
||||
一方、Parrotのようにコードベースへのコミット権限を簡単に得られるプロジェクトもあります。
|
||||
プロジェクトがGitHubを使っている場合、GitHubのプルリクエスト機能を使ったワークフローがあるかもしれません。 プロジェクトごとに方法は異なります。
|
||||
|
||||
コードを修正するときは、コミュニティの責任あるメンバーとして行動し、コードスタイルを既存のコードベースに合わせましょう。
|
||||
追加・修正するコードは既存コードと同じように見えるべきです。
|
||||
中括弧のスタイルやインデントのスペースの扱いが好みでなくても、既存の標準に合わないコード変更を提出するのは失礼です。
|
||||
「自分のスタイルが正しい」と押し付けることと同じです。
|
||||
|
||||
6. **ベータ版やリリース候補をテストする**: 複数のプラットフォームで動作するプロジェクトは、移植性に関する様々な問題を抱える可能性があります。
|
||||
リリースが近づき、ベータ版やリリース候補が公開されたら、多くの人にテストしてもらうことがプロジェクトリーダーの望みです。
|
||||
あなたもその一人として、自分の環境で動作を確認し、貢献できます。通常はソフトウェアをダウンロードしてビルドし、テストするだけで十分ですが、珍しいディストリビューションやハードウェアでのテスト結果は非常に価値があります。
|
||||
ビルドやテストが成功したことを報告するだけでも、リリースが安定しているかどうかの判断材料になります。
|
||||
|
||||
7. **バグを修正する**: コードに取り組みたい貢献者は通常ここから始めます。
|
||||
やることはシンプルです: チケットシステムで興味のあるバグを見つけ、コードで修正を試みます。
|
||||
修正内容は適宜コード内に文書化しましょう。
|
||||
修正箇所をテストスイートに追加してテストするのも良い考えです。
|
||||
プロジェクトによっては、バグ修正にはテスト追加が必須の場合があります。
|
||||
初めて触れるコードベースを調べながらメモを取りましょう。
|
||||
バグを修正できなくても、修正試行の過程で分かったことをチケットに記録すれば、後から来る人に役立ちます。
|
||||
|
||||
8. **テストを書く**: ほとんどのプロジェクトにはコードをテストするテストスイートがありますが、さらにテストを追加できる箇所は常に存在します。
|
||||
Cならgcov、PerlならDevel::Coverなどのカバレッジツールを使って、テストスイートでカバーされていない箇所を特定し、テストを追加します。
|
||||
|
||||
9. **コンパイラ警告を消す**: 多くのCベースのプロジェクトでは、ビルド時に奇妙なコンパイラ警告が表示されます。
|
||||
これらの警告は通常問題の兆候ではありませんが、そう見えることがあります。。
|
||||
警告が多すぎると、コンパイラが「狼が来た」と叫んでいるように見えます。
|
||||
コードが本当にバグを隠していないか確認し、問題がなければ警告を消す修正を加えることで、誤検知を減らせます。
|
||||
|
||||
10. **コメントを追加する**: コードを調べていると、理解しづらい箇所が見つかることがあります。
|
||||
もしあなたが混乱したなら、他の人も混乱する可能性が高いです。
|
||||
コードにコメントを追加して、パッチとして提出しましょう。
|
||||
|
||||
## ドキュメントに取り組む
|
||||
コードを調べていると、分かりにくい部分を見つけることがあります。
|
||||
あなたが混乱したなら、他の人も同様に混乱する可能性が高いです。コードにドキュメントを追加し、パッチを提出してください。
|
||||
ドキュメントとの連携
|
||||
ドキュメントは、プロジェクトの要素の中でも最も軽視されがちな部分です。
|
||||
また、プロジェクトに精通した人の視点から書かれたため、初めて触れる人の視点から見た場合、理解しにくい場合があります。
|
||||
「このマニュアルは、私がすでにパッケージの使い方を理解していることを前提にしているようだ」と感じたことがあるなら、私の言っていることがわかるでしょう。
|
||||
プロジェクトに深く関わっている人々が気づかないドキュメントの欠点を、新鮮な視点を持つ人が指摘できることがあります。
|
||||
|
||||
11. **サンプルを作る**: どのプロジェクトも、使い方の具体例は多いに越したことはありません。
|
||||
ウェブAPI、ライブラリ、GUIアプリ（Gimpなど）、コマンドラインツール、いずれでも、適切な使い方の例は長いドキュメントよりもわかりやすく説明できます。
|
||||
APIやライブラリなら、ツールを使ったサンプルプログラムを作成します。
|
||||
既存のコードから必要最低限に切り出すだけでも構いません。
|
||||
ツールなら、日常生活でどのように使っているかを実例として示します。
|
||||
視覚的に理解したい場合は、重要なプロセス（アプリのインストール手順など）のスクリーンキャプチャも有効です。
|
||||
|
||||
## コミュニティに取り組む
|
||||
|
||||
オープンソースはコードだけでなく、コミュニティがあって初めて機能します。
|
||||
コミュニティを育てる方法はいくつもあります。
|
||||
|
||||
12. **質問に答える**: コミュニティを育てる最良の方法は、他の人を助けることです。
|
||||
特に初めての人の質問に答えることは、プロジェクトの成長と活性化に重要です。
|
||||
初心者を助ける時間は、将来的に活発なコミュニティメンバーを生む投資です。
|
||||
誰もがどこかから始める必要があり、プロジェクトは常に新しい人材の流入を必要としています。
|
||||
|
||||
13. **ブログ記事を書く**: 自分のブログがあるなら、プロジェクトの使用体験について書きましょう。
|
||||
ソフトウェア使用中に直面した問題とその解決方法について書きます。
|
||||
これにより、他の人にもプロジェクトを意識させ、同じ問題に直面した人が将来検索した際に役立つ情報を提供できます。
|
||||
（技術的冒険のブログは、次に仕事で同じソフトウェアを使うときの実務経験を示すのにも役立ちます）
|
||||
|
||||
14. **ウェブサイトを改善する**: ウェブデザインのスキルがある場合、プロジェクトのウェブサイトや公開イメージの改善に貢献できます。
|
||||
プロジェクトのグラフィックを刷新したり、ロゴを作成したりすることも価値があります。
|
||||
コミュニティ内でこうしたスキルを持つ人は少ないことが多く、非常に歓迎されます。
|
||||
|
||||
15. **技術ドキュメントを書く**: アプリケーションやソフトウェアの動作について書けるなら、技術ドキュメントを作成できます。
|
||||
特にオープンソースで、一般向けに更新・拡張・作成が必要なドキュメントに最適です。
|
||||
平易な英語で書けば書くほど良いです。プログラマーでなくても技術ドキュメントは書けます。
|
||||
|
||||
最も重要なのは、周囲の人々が何を話しているかに耳を傾けることです。
|
||||
差し迫ったニーズに気づけるかどうかを探してみましょう。
|
||||
|
||||
例えば、最近Parrotの開発者向けメールリストでは、古いTracシステムを廃止して、GitHubをトラブルチケット管理システムとして使用することが決まりました。
|
||||
一部の人は反対でした。というのも、既存のチケットをGitHubに移行する方法がなかったからです。
|
||||
1日の議論のやり取りの後、私は「コンバータを作ってみたらどうですか？」と提案しました。
|
||||
人々はそのアイデアに大喜び。私は450件以上のチケットを変換するプログラムを作成し、チケット履歴を一切失うことなく移行に成功しました。
|
||||
これは大きな成功でした。私も貢献でき、コア開発者たちはParrotの開発業務に集中できたのです。
|
||||
|
||||
16. **教え、他者を助ける**:
|
||||
あるトピックについてより深く学ぶ最良の方法は、それを教えてみることです。
|
||||
最高の教師は、複雑なことをシンプルな例で説明できる人です。
|
||||
そのため、最高の学習者であり、プログラミングの世界で最高であるためには、まず最高の教師になろうとする必要があります。
|
||||
他者に教えることで、自分自身の理解も深まり、スキルや知識も向上します。
|
||||
誰かから助けを得たとき、それを自分だけに留めず、他の人と共有してください。
|
||||
そうすることで、世界はより良い場所になります。
|
||||
|
||||
+145
@@ -0,0 +1,145 @@
|
||||
# 非程序员可以做的事
|
||||
## 从倾听开始
|
||||
|
||||
开源的本质是人与人之间的合作。
|
||||
你想要加入一个团队，就必须了解这个社区以及它是如何运作的。
|
||||
直接进入一个项目并说“嗨，我认为这个项目应该做XXX”通常不会被很好地接受。
|
||||
某些项目可能欢迎这种方式，但如果项目已经运行一段时间，这种态度很难被采纳。
|
||||
**倾听是了解项目真正需求的最佳方式。**
|
||||
|
||||
1. **加入邮件列表**：
|
||||
对于许多项目来说，邮件列表是关于项目开发的主要沟通渠道。在大型项目中，可能会有很多不同的邮件列表可供选择。例如，PostgreSQL 项目在其邮件列表页面上就有不少于 12 个面向用户的列表和 6 个开发者列表。
|
||||
建议你一开始关注主要的用户列表和核心开发者列表来“听听看”。
|
||||
|
||||
2. **关注博客**：
|
||||
核心开发人员维护的博客通常会分享有关未来版本的计划，以及达成这些目标的过程。一个叫做 planet 的网站会汇集来自多个相关来源的新闻和博客内容。
|
||||
如果某个项目有 planet 网站，比如 planet.gnome.org 或 planet.mysql.com，请从那里开始。只需在 Google 中搜索 "planet <projectname>" 即可。
|
||||
|
||||
3. **加入 IRC 频道**：
|
||||
许多开源项目都有专属的 IRC（互联网中继聊天）频道，开发者和用户会在里面讨论问题与开发进度。在项目的官方网站上通常可以找到 IRC 频道的名称和所在网络的信息。
|
||||
|
||||
**处理工单系统**
|
||||
代码是任何开源项目的核心，但不要以为只有写代码才算是贡献。
|
||||
代码的维护及其周边系统往往在开发新功能或修复 bug 的过程中被忽略。
|
||||
这些部分是你进入项目的良好切入点。
|
||||
大多数项目都有公开的故障工单系统，通常在项目主页和文档中就能找到链接。
|
||||
它是用户与开发者之间的主要沟通渠道。
|
||||
保持工单系统的更新就是一种很有价值的贡献。
|
||||
你可能需要获得该系统的特别权限，一旦你表示出愿意协助维护，项目负责人通常会很乐意为你开放权限。
|
||||
|
||||
4. **诊断 bug**：
|
||||
很多 bug 报告都不够详细。
|
||||
协助诊断并分析 bug 可以大大节省开发者排查问题的时间。
|
||||
比如用户报告“我做了 X 操作，软件就坏了”，你可以尝试复现问题，找出具体触发条件。
|
||||
这个问题是可以重复触发的吗？能不能提炼出一套步骤重现问题？是否只在某些浏览器或操作系统中才出现？
|
||||
|
||||
即使你不清楚问题的根本原因，但你做出的分析工作，也会让其他人更容易去修复它。
|
||||
无论你发现了什么，请将其记录在工单系统中，方便所有人查看。
|
||||
|
||||
5. **关闭已修复的 bug**：
|
||||
有些 bug 虽然已经在代码中修复，但对应的工单却没有更新状态。
|
||||
清理这些“陈年工单”虽然耗时，但对整个项目非常有帮助。
|
||||
|
||||
你可以从查询一年以前的工单开始，检查这些 bug 是否仍然存在。
|
||||
阅读项目的更新日志，确认 bug 是否已被修复。
|
||||
如果确定已修复，请在工单中注明修复版本并关闭工单。
|
||||
|
||||
也可以尝试使用最新版本重现这个 bug。
|
||||
如果无法复现，请在工单中注明并关闭；如果仍存在，也请更新工单说明并保留为“打开”状态。
|
||||
|
||||
## 参与代码工作
|
||||
|
||||
不同经验水平的开发者都可以为项目贡献代码。
|
||||
不要认为只有编程大神才有资格参与贡献。
|
||||
|
||||
如果你的工作涉及代码更改，请先了解项目是如何接受代码贡献的。
|
||||
每个项目的工作流都不同，因此在提交代码之前请先询问清楚流程。
|
||||
|
||||
例如，PostgreSQL 项目对代码提交要求非常严格：必须以补丁形式发送到邮件列表，由核心开发者详细审查。
|
||||
而 Parrot 项目则相对宽松，很容易就能获得代码库的提交权限。
|
||||
如果项目托管在 GitHub 上，可能还会使用 pull request 的工作流。
|
||||
没有两个项目是完全相同的。
|
||||
|
||||
每当你修改代码时，请务必遵守已有代码风格，使你提交的代码看起来就像是原生的一部分。
|
||||
即使你不喜欢某种括号或缩进方式，也不应擅自改变已有风格。
|
||||
这就像在说：“我不喜欢你们的风格，我的更好，你们应该改成我的。”
|
||||
|
||||
6. **测试测试版或候选版本**：
|
||||
如果一个项目支持多个平台，那发布前的可移植性测试就至关重要。
|
||||
当项目发布 beta 或 RC（Release Candidate）版本时，项目负责人希望有人能在各种平台上进行测试。
|
||||
你就可以成为其中一员，帮助确认在你的环境下也能正常运行。
|
||||
|
||||
通常你只需下载、构建并运行软件即可。
|
||||
尤其当你使用的是较为冷门的操作系统或硬件时，你的反馈对项目非常宝贵。
|
||||
|
||||
7. **修复一个 bug**：
|
||||
这是很多想写代码的新手常见的起点。
|
||||
很简单：在工单系统中找一个感兴趣的问题，尝试去修复它。
|
||||
如果合适，可以在代码中添加注释记录你的修改；如果项目有测试套件，最好也为你修复的 bug 添加测试用例。
|
||||
即便你没能修复 bug，也请将你调查的结果写进工单中，这对后来的人是很有帮助的。
|
||||
|
||||
8. **编写测试用例**：
|
||||
大多数项目都有测试套件，但几乎没有哪个测试覆盖是“完美”的。
|
||||
可以使用测试覆盖工具（如：C 的 gcov，Perl 的 Devel::Cover）找出哪些代码尚未被测试。
|
||||
然后为这些部分添加测试用例。
|
||||
|
||||
9. **消除编译警告**：
|
||||
许多基于 C 的项目在编译时会有很多警告信息。
|
||||
虽然多数情况下这并不影响程序运行，但会制造混乱或误导。
|
||||
你可以排查警告背后是否隐藏真正的 bug。
|
||||
如果没有实际问题，就修改代码消除警告，提升代码整洁度。
|
||||
|
||||
10. **添加注释**：
|
||||
当你在阅读代码时，可能会遇到令人困惑的部分。
|
||||
如果你感到困惑，别人可能也会。
|
||||
请在适当位置添加注释并提交补丁，帮助其他人理解代码。
|
||||
|
||||
## 编写文档
|
||||
|
||||
文档常常是被忽视的一部分。
|
||||
而且很多时候文档是“内部人”写给“内部人”的，忽略了初学者视角。
|
||||
如果你曾看过某个手册让你觉得：“作者好像默认我已经懂这套系统了”，你就明白我的意思了。
|
||||
新人的眼睛能发现老成员早已忽视的问题。
|
||||
|
||||
11. **创建示例**：
|
||||
任何项目都不嫌示例多。
|
||||
无论是 Web API、函数库、图形工具（如 Gimp）或命令行工具，
|
||||
一个实用示例往往比一大堆文档更能直观说明使用方式。
|
||||
对于 API 或库，可以写个简单的 demo；对于工具，展示真实的使用情景。
|
||||
如果你擅长视觉内容，也可以录屏展示如何安装、配置等步骤。
|
||||
|
||||
## 参与社区
|
||||
|
||||
开源项目不仅仅是代码。社区才是开源的生命力来源。以下是你可以帮助社区的方式：
|
||||
|
||||
12. **回答问题**：
|
||||
帮助新手是社区成长的重要方式。
|
||||
即使对方的问题很基础，也不要敷衍了事。
|
||||
哪怕是你很想说“RTFM”，请记住：帮助他们，就等于在培养未来的维护者。
|
||||
每个人都是从新手走过来的，项目要保持活力就需要不断有新人加入。
|
||||
|
||||
13. **写一篇博客**：
|
||||
如果你有博客，请写下你使用该项目的经验。
|
||||
记录你遇到的问题和解决办法，这不仅可以帮助搜索到的人，也有助于传播该项目。
|
||||
（顺带一提，如果你未来找工作，技术博客是一个很好的展示作品集的方式）
|
||||
|
||||
14. **优化网站**：
|
||||
如果你有网页设计技能，可以协助美化项目网站或设计 logo，提升项目的公众形象。
|
||||
这些往往是开源社区中缺乏的技能，我相信很多维护者都会非常欢迎这方面的协助。
|
||||
|
||||
15. **编写技术文档**：
|
||||
如果你擅长用通俗易懂的方式说明软件原理，可以帮助项目撰写或更新技术文档。
|
||||
很多开源项目都在寻找志愿者来扩展文档，尤其是面向普通大众的部分。
|
||||
你不需要是程序员，只要能把话说清楚就行。
|
||||
|
||||
最重要的是，倾听周围人的讨论，观察有没有什么急需解决的问题。
|
||||
例如，在 Parrot 项目的邮件列表中，有人提议将工单系统从 Trac 转移到 GitHub。
|
||||
但由于缺乏转换工具，一度引发争论。我当时提出“我可以写一个转换器”。
|
||||
大家非常欢迎这个提议。我花时间写了一个转换程序，把 450 多条工单全部迁移了过去。
|
||||
这是一次很成功的贡献。开发者继续专注写代码，而我解决了一个让大家头疼的问题。
|
||||
|
||||
16. **教学与协助他人**：
|
||||
最好的学习方式就是尝试去教别人。
|
||||
能用最简单的例子讲清复杂概念的老师，往往才是最厉害的。
|
||||
教学不但能加深你自己的理解，也能帮助别人快速上手。
|
||||
你从别人那里学到的知识，也请传递下去，让世界变得更美好。
|
||||
+53
@@ -0,0 +1,53 @@
|
||||
# 实用链接
|
||||
|
||||
本页面致敬所有让我们生活更轻松的技巧网站、博客文章和实用链接。
|
||||
无论是初学者还是资深开发者，它们都是极好的参考资源。
|
||||
这个页面将作为一个索引，汇总所有对开源领域新人或想深入了解的人有帮助的链接。
|
||||
|
||||
## 链接列表
|
||||
**请注意: 以下所有链接均为英文内容。**
|
||||
|
||||
1. [Git 交互式教程](https://try.github.io)
|
||||
2. [YouTube：FreeCodeCamp 的 Git 和 GitHub 初学者教程](https://www.youtube.com/watch?v=RGOj5yH7evk)
|
||||
3. [git - 简明指南](http://rogerdudler.github.io/git-guide/)
|
||||
4. [如何撤销、更改或删除 Git 提交](http://sethrobertson.github.io/GitFixUm/fixup.html)
|
||||
5. [Git 和 GitHub 教程（多语言版本）](https://github.com/Roshanjossey/first-contributions)
|
||||
6. [解决合并冲突](https://www.git-tower.com/learn/git/ebook/en/command-line/advanced-topics/merge-conflicts)
|
||||
7. [Git How To：解决合并冲突](https://githowto.com/resolving_conflicts)
|
||||
8. [Git 基础 - 快速入门指南](https://blog.praveen.science/basics-of-git-the-quick-start-guide/)
|
||||
9. [我们在 Spotify Agile 方法中使用的 Git 标准](https://blog.praveen.science/git-standards-followed-in-our-way-of-spotify-agile-methodolgy/)
|
||||
10. [Git 快捷方式](https://blog.praveen.science/git-shortcuts/)
|
||||
11. [官方 Git 多语言备忘单](https://services.github.com/on-demand/resources/cheatsheets)
|
||||
12. [来自 Tower 的 Git 备忘单](https://www.git-tower.com/learn/cheat-sheets/git)
|
||||
13. [常见 Git 问题及解决方法](https://www.codementor.io/citizen428/git-tutorial-10-common-git-problems-and-how-to-fix-them-aajv0katd)
|
||||
14. [Git Rebase 图解指南](https://blog.gitprime.com/git-rebase-an-illustrated-guide/)
|
||||
15. [新手 Rebasing 与 Squashing 指南](https://github.com/servo/servo/wiki/Beginner%27s-guide-to-rebasing-and-squashing)
|
||||
16. [命令与文件关联的 Git 速查表](http://ndpsoftware.com/git-cheatsheet.html)
|
||||
17. [如何贡献开源](https://opensource.guide/how-to-contribute/)
|
||||
18. [开源贡献入门指南](https://github.com/OpenSourceHelpCommunity/Getting-Started-With-Contributing-to-Open-Sources)
|
||||
19. [FreeCodeCamp 的开源贡献指南](https://github.com/freeCodeCamp/how-to-contribute-to-open-source)
|
||||
20. [Atlassian 的 Git 教程](https://www.atlassian.com/git)
|
||||
21. [Pull Request 审查流程](https://help.github.com/articles/about-pull-request-reviews/)
|
||||
22. [另一个 Git 交互式教程](https://learngitbranching.js.org/)
|
||||
23. [Git 命令行速查表](https://gist.github.com/davfre/8313299)
|
||||
24. [编程书籍（免费)](https://github.com/EbookFoundation/free-programming-books)
|
||||
25. [Git 专业技巧与秘籍电子书](https://goalkicker.com/GitBook/GitProfessionalTipsSecrets.pdf)
|
||||
26. [成为 Git 专家的简单规则](https://medium.freecodecamp.org/follow-these-simple-rules-and-youll-become-a-git-and-github-master-e1045057468f)
|
||||
27. [关于 Git 提交信息的建议](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)
|
||||
28. [更好的提交信息的 5 个技巧](https://thoughtbot.com/blog/5-useful-tips-for-a-better-commit-message)
|
||||
29. [Git 版本控制基础](https://ourcodingclub.github.io/2017/02/27/git.html)
|
||||
30. [Git 版本控制课程（Udacity）](https://www.udacity.com/course/version-control-with-git--ud123)
|
||||
31. [Coursera 上 Google 提供的 Git 课程（可试听）](https://www.coursera.org/learn/introduction-git-github)
|
||||
32. [在 VS Code 中使用版本控制](https://code.visualstudio.com/docs/editor/versioncontrol)
|
||||
33. [Git 与 GitHub 的区别以及入门方法](https://kinsta.com/knowledgebase/git-vs-github/)
|
||||
34. [Hello World Github 教程](https://guides.github.com/activities/hello-world/)
|
||||
35. [如何使用 GitHub](https://www.edureka.co/blog/how-to-use-github/)
|
||||
36. [Git 与 GitHub 的 10 天教程](https://github.com/Asabeneh/10-days-of-git-and-github)
|
||||
37. [GitHub 快捷键列表](https://docs.github.com/en/get-started/using-github/keyboard-shortcuts)
|
||||
38. [Kunal Kushwaha 的 Git 和 GitHub 完整教程（YouTube）](https://www.youtube.com/watch?v=apGV9Kg7ics&ab_channel=KunalKushwaha)
|
||||
39. [Git 工作流速查表（Google Drive)](https://drive.google.com/uc?export=download&id=1QPRh5YmqQm4DFfitelPYlBTWC2I6tTTM)
|
||||
40. [初学者 Git 工作流指南](https://medium.com/@anjulapaulus_84798/beginners-guide-to-proper-git-workflow-35a2d967734e)
|
||||
41. [如何使用 GitHub Pages](https://docs.github.com/en/pages)
|
||||
42. [了解 GitHub Copilot](https://docs.github.com/en/copilot/about-github-copilot/what-is-github-copilot)
|
||||
|
||||
持续添加你觉得有用的链接吧！
|
||||
@@ -0,0 +1,66 @@
|
||||
# 修改 Commit
|
||||
|
||||
假设你已经将一个更改提交到远程仓库，但后来你发现提交信息有一个拼写错误，或者你忘记在最近的提交中添加一行。
|
||||
你该如何编辑这个提交？这篇教程将为你解答。
|
||||
|
||||
## 在推送到 Github 后修改最近的提交信息
|
||||
如果你不想打开文件，可以通过以下方式进行修改：
|
||||
* 输入 `git commit --amend -m "然后是你新的提交信息"`
|
||||
* 运行 `git push origin <branch-name>` 将更改提交到仓库。
|
||||
|
||||
注意：如果只输入 `git commit --amend`，则会打开文本编辑器，提示你编辑提交信息。
|
||||
添加 `-m` 标志可以防止这种情况。
|
||||
|
||||
## 修改单个提交
|
||||
|
||||
那么，如果我们忘记对文件做一个小的更改，比如更改一个单词，而且我们已经将提交推送到远程仓库了，怎么办呢？
|
||||
|
||||
以下是我的提交日志：
|
||||
```
|
||||
g56123f 创建 bot 文件
|
||||
a2235d 更新 contributor.md
|
||||
a5da0d 修改 bot 文件
|
||||
```
|
||||
假设我忘记在 bot 文件中添加一个单词。
|
||||
|
||||
有两种方法可以解决这个问题。第一种方法是创建一个包含更改的新提交，如下所示：
|
||||
```
|
||||
g56123f 创建 bot 文件
|
||||
a2235d 更新 contributor.md
|
||||
a5da0d 修改 bot 文件
|
||||
b0ca8f 添加 bot 文件中的单词
|
||||
```
|
||||
第二种方法是修改 `a5da0d` 提交，添加这个新单词，并将其作为一个提交推送到 Github。
|
||||
第二种方法更好，因为这只是一个小改动。
|
||||
|
||||
为了实现这一点，我们可以按照以下步骤操作：
|
||||
* 修改文件。在本例中，我会修改 bot 文件，加入之前遗漏的单词。
|
||||
* 接下来，使用 `git add <filename>` 将文件添加到暂存区。
|
||||
|
||||
通常，在将文件添加到暂存区之后，我们会运行 git commit -m "我们的提交信息"`, 对吧？
|
||||
但由于我们希望修改的是上一个提交，我们应该运行：
|
||||
|
||||
* `git commit --amend`
|
||||
这会打开文本编辑器，提示你编辑提交信息。你可以选择保留原来的信息，也可以修改它。
|
||||
* 退出编辑器
|
||||
* 使用 `git push origin <branch-name>` 推送更改
|
||||
|
||||
这样，两个更改就会合并为一个提交。
|
||||
|
||||
## 修改远程提交
|
||||
|
||||
如果你想修改的提交已经推送到远程，修改该提交将导致你的本地历史与远程分支不同步（因为你实际上创建了一个新提交并替换了已修改的提交）。
|
||||
由于你希望更改远程的提交，你需要覆盖远程仓库中的历史记录。为了实现这一点，请按照上述相同的步骤操作，但在推送提交到远程时使用强制推送。
|
||||
|
||||
> **警告**
|
||||
> 强制推送到远程将覆盖（并丢弃）远程上的更改，只保留你推送的提交。其他团队成员在此期间对远程的更改也将被覆盖。
|
||||
|
||||
这是如何修改远程仓库中最后一次提交的方法：
|
||||
|
||||
```bash
|
||||
git add <your changed files>
|
||||
git commit --amend -m "然后是你的新提交信息"
|
||||
git push --force
|
||||
```
|
||||
|
||||
>使用 `--force-with-lease` 比 `--force` 更安全，它可以避免覆盖远程分支上其他人的更改（如果你不打算这么做）。
|
||||
@@ -0,0 +1,37 @@
|
||||
# 查看提交日志
|
||||
|
||||
为了查看某个分支或某个文件的提交日志，可以使用以下命令：
|
||||
|
||||
`git log [options] [path]`
|
||||
|
||||
该命令的输出默认按逆时间顺序排列。
|
||||
|
||||
## 命令输出示例
|
||||
```
|
||||
$ git log
|
||||
commit e3fabb30ab536bd5876461d8a749301a321e714f (HEAD -> check-commit-log-ko, upstream/main, origin/main, origin/HEAD, main)
|
||||
Author: Dan Yunheum Seol yunheum.seol@mail.mcgill.ca
|
||||
Date: Tue Jun 4 01:07:25 2024 -0400
|
||||
|
||||
Add dan-seol to Contributors list (#84962)
|
||||
|
||||
commit 4af4ec8a56e057ce8768af77eda528453974d0bc
|
||||
Author: Edgar Humberto Tijerina Tamez <168693312+EdgarHTT@users.noreply.github.com>
|
||||
Date: Mon Jun 3 23:06:05 2024 -0600
|
||||
|
||||
Add Edgar Tijerina to Contributors list (#84961)
|
||||
```
|
||||
|
||||
|
||||
## 命令变体和选项
|
||||
- 若要查看从某些特定提交 ids: <i>（例如 `foo` 和 `bar`）可达的提交，可以使用：</i><br>
|
||||
`git log foo bar `
|
||||
- 也可以通过在提交 id 前添加 `^` 来排除某个提交<i>（例如 `baz`）：</i><br>
|
||||
`git log foo bar ^baz`
|
||||
- 查看特定文件的提交日志：<br>
|
||||
`git log --all <filename>`
|
||||
- 限制日志中提交的数量：<i>（例如 `5`）</i><br>
|
||||
`git log -n 5`
|
||||
|
||||
## 参考
|
||||
- [官方文档](https://git-scm.com/docs/git-log)
|
||||
@@ -0,0 +1,78 @@
|
||||
# 配置 git
|
||||
|
||||
第一次使用 git 提交时，你可能会看到如下提示：
|
||||
|
||||
```bash
|
||||
$ git commit
|
||||
*** 请告诉我你是谁。
|
||||
|
||||
运行
|
||||
|
||||
git config --global user.email "you@example.com"
|
||||
git config --global user.name "Your Name"
|
||||
|
||||
来设置你账户的默认身份。
|
||||
如果只想在当前仓库设置身份，省略 --global。
|
||||
```
|
||||
|
||||
Git 在创建提交时需要知道你是谁。当你在团队中协作时，你应该能够看到是谁修改了项目的哪些部分以及何时修改的，因此，Git 设计时就要求每个提交都与一个名字和电子邮件地址相关联。
|
||||
|
||||
有多种方法可以为 `git commit` 命令提供你的电子邮件和用户名，下面我们将介绍几种常用的方法。
|
||||
|
||||
### 全局配置
|
||||
|
||||
当你将某个配置存储在全局配置中时，它在你工作的所有仓库中都是可访问的。这是推荐的方式，并且适用于大多数使用场景。
|
||||
|
||||
要将某个配置存储在全局配置中，你可以使用以下 `config` 命令：
|
||||
|
||||
`$ git config --global <variable name> <value>`
|
||||
|
||||
对于用户信息，我们可以运行：
|
||||
|
||||
```
|
||||
$ git config --global user.email "you@example.com"
|
||||
$ git config --global user.name "Your Name"
|
||||
```
|
||||
|
||||
### 仓库配置
|
||||
|
||||
顾名思义，这些配置仅作用于当前仓库。如果你想在某个特定仓库中提交，例如工作项目，并使用你公司的电子邮件地址，你可以使用这种方法。
|
||||
|
||||
要将某个配置存储在仓库配置中，可以在 `config` 命令中省略 `--global` 标志，如下所示：
|
||||
|
||||
`$ git config <variable name> <value>`
|
||||
|
||||
对于用户信息，我们可以运行：
|
||||
|
||||
```
|
||||
$ git config user.email "you@alternate.com"
|
||||
$ git config user.name "Your Name"
|
||||
```
|
||||
|
||||
### 命令行配置
|
||||
|
||||
这些配置仅作用于当前命令。所有 git 命令在动作动词之前都可以使用 `-c` 参数来设置临时配置数据。
|
||||
|
||||
要在命令行配置中存储某个配置，按如下方式运行命令：
|
||||
|
||||
`$ git -c <variable-1>=<value> -c <variable-2>=<variable> <command>`
|
||||
|
||||
在我们的例子中，我们将提交命令改为：
|
||||
|
||||
`git -c user.name='Your Name' -c user.email='you@example.com' commit -m "Your commit message"`
|
||||
|
||||
### 配置优先级说明
|
||||
|
||||
在这里描述的三种方法中，优先级顺序是 `command-line > repository > global`。这意味着，如果同一个变量在命令行和全局中都有配置，命令行的值将用于该操作。
|
||||
|
||||
### 超出用户信息
|
||||
|
||||
到目前为止，我们仅在配置中处理了用户信息。然而，还有许多其他配置选项。以下是一些常见的配置：
|
||||
|
||||
1. `core.editor` - 指定用于编写提交消息等的编辑器名称。
|
||||
2. `commit.template` - 指定系统中作为初始提交模板的文件。
|
||||
3. `color.ui` - 指定是否在 git 输出中使用颜色的布尔值。
|
||||
|
||||
为了便于理解，我们简化了一些细节。如果你想进一步了解，访问 [git-scm.com](https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration)。
|
||||
|
||||
|
||||
@@ -0,0 +1,76 @@
|
||||
# .gitignore
|
||||
|
||||
.gitignore 文件是一个文本文件，用于告诉 Git 在项目中哪些文件或文件夹应被忽略。
|
||||
|
||||
一个本地的 .gitignore 文件通常放置在项目的根目录下。你也可以创建一个全局的 .gitignore 文件，这样文件中的任何条目都会在你所有的 Git 仓库中被忽略。
|
||||
|
||||
## 为什么使用 .gitignore
|
||||
现在你可能会想，为什么要让 Git 忽略某些文件和文件夹。原因是你不希望像构建文件、缓存文件、其他本地配置文件（例如 node_modules）、编译文件、IDE 创建的临时文件等被 Git 跟踪。通常，这样做是为了避免提交工作目录中的临时文件，这些文件对其他协作者没有用。
|
||||
|
||||
## 入门
|
||||
要创建一个本地的 .gitignore 文件，创建一个文本文件并命名为 .gitignore（记得在文件名前加上 `.`）。然后根据需要编辑此文件。每一行都应该列出你希望 Git 忽略的文件或文件夹。
|
||||
|
||||
该文件中的条目也可以遵循匹配模式。
|
||||
|
||||
```
|
||||
* 用作通配符匹配
|
||||
/ 用于忽略相对于 .gitignore 文件的路径名
|
||||
# 用于在 .gitignore 文件中添加注释
|
||||
|
||||
下面是 .gitignore 文件的一个示例：
|
||||
|
||||
# 忽略 Mac 系统文件
|
||||
.DS_store
|
||||
|
||||
# 忽略 node_modules 文件夹
|
||||
node_modules
|
||||
|
||||
# 忽略所有文本文件
|
||||
*.txt
|
||||
|
||||
# 忽略与 API 密钥相关的文件
|
||||
.env
|
||||
|
||||
# 忽略 SASS 配置文件
|
||||
.sass-cache
|
||||
|
||||
```
|
||||
要添加或更改全局 `.gitignore` 文件，运行以下命令：
|
||||
|
||||
```
|
||||
git config --global core.excludesfile ~/.gitignore_global
|
||||
|
||||
```
|
||||
这将创建文件 ~/.gitignore_global。现在，你可以像本地 .gitignore 文件一样编辑这个文件。你所有的 Git 仓库都会忽略全局 .gitignore 文件中列出的文件和文件夹。
|
||||
|
||||
## 如何取消跟踪已提交的文件
|
||||
|
||||
要取消跟踪单个文件，即停止跟踪该文件但不删除它，可以使用：
|
||||
|
||||
```
|
||||
git rm --cached filename
|
||||
```
|
||||
|
||||
要取消跟踪 .gitignore 中的每个文件：
|
||||
|
||||
首先，提交任何未提交的代码更改，然后运行：
|
||||
|
||||
```
|
||||
git rm -r --cached
|
||||
```
|
||||
|
||||
这将从索引（暂存区）中移除任何已更改的文件，然后运行：
|
||||
|
||||
```
|
||||
git add .
|
||||
```
|
||||
Commit it:
|
||||
|
||||
```
|
||||
git commit -m ".gitignore is now working"
|
||||
```
|
||||
|
||||
要撤销 ```git rm --cached filename```，使用 ```git add filename```
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,19 @@
|
||||
# 删除本地创建的分支
|
||||
|
||||
当你不小心拼错了分支名称时，这个操作会非常有用。
|
||||
|
||||
你可以通过 *3* 种方式来删除分支：
|
||||
|
||||
```
|
||||
git branch -D <branch_name>
|
||||
```
|
||||
|
||||
```
|
||||
git branch --delete --force <branch_name> # 与 -D 相同
|
||||
```
|
||||
|
||||
```
|
||||
git branch --delete <branch_name> # 如果未合并会报错
|
||||
```
|
||||
|
||||
-D 代表 --delete --force，即即使分支未合并，也会强制删除该分支。你也可以使用 -d，它代表 --delete，当分支未合并时，会抛出错误。
|
||||
@@ -0,0 +1,119 @@
|
||||
# Gitflow
|
||||
|
||||
Gitflow 是由 Vincent Driessen 创建的 Git 分支模型。本文将讨论 Gitflow 的要求和用例。<br />
|
||||
Gitflow 工作流定义了一个围绕项目发布而设计的严格分支模型，提供了一个强大的框架来管理大型项目。Gitflow 特别适用于具有计划发布周期的项目以及 DevOps 最佳实践中的持续交付。它为不同的分支分配了非常具体的角色，并定义了它们应该如何以及何时互动。它使用独立的分支来准备、维护和记录发布。
|
||||
|
||||
|
||||
## 实现
|
||||
|
||||
1. **Develop 和 Master Branches**：与单一的 master 分支不同，Git Flow 使用两个分支来记录项目的历史。它基于两个具有无限生命周期的主分支，即 master 和 develop：
|
||||
- **Master Branch**：master 分支包含生产代码并存储官方的发布历史。
|
||||
- **Develop Branch**：develop 分支包含预生产代码，作为功能的集成分支。
|
||||
- **创建 Develop Branch**：<br />
|
||||
不使用 Gitflow 扩展时：
|
||||
```
|
||||
git branch develop
|
||||
git push -u origin develop
|
||||
```
|
||||
使用 Gitflow 扩展时：当使用 gitflow 扩展库时，在现有的仓库中执行 `git flow init` 将创建 develop 分支。
|
||||
```
|
||||
git flow init
|
||||
```
|
||||
2. **Feature Branch**：每个新功能应该放在它自己的分支上，可以推送到中央仓库以备份或协作。Feature 分支使用最新的 develop 作为其父分支。当功能完成时，它会合并回 develop。功能分支永远不应直接与 master 分支交互。
|
||||
- **创建 Feature Branch**： <br />
|
||||
不使用 git-flow 扩展时：
|
||||
```
|
||||
git checkout develop
|
||||
git checkout -b feature_branch
|
||||
```
|
||||
使用 gitflow 扩展时：
|
||||
```
|
||||
git flow feature start feature_branch
|
||||
```
|
||||
- **完成 Feature Branch**： <br />
|
||||
不使用 git-flow 扩展时：
|
||||
```
|
||||
git checkout develop
|
||||
git merge feature_branch
|
||||
```
|
||||
使用 git-flow 扩展时：
|
||||
```
|
||||
git flow feature finish feature_branch
|
||||
```
|
||||
3. **Release Branch**：当 develop 分支包含足够的功能用于发布（或者接近预定的发布日期）时，我们会从 develop 分支派生出一个 release 分支。创建这个分支标志着下一个发布周期的开始，因此在此之后不能再添加新功能——只能添加 bug 修复、文档生成和其他与发布相关的任务。Release 分支应从 develop 分支派生，并必须同时合并到 master 和 develop 分支。<br />
|
||||
使用专门的分支来准备发布使得一个团队可以在 polishing 当前发布时，另一个团队继续为下一个发布开发新功能。
|
||||
- **创建 Release Branch**： <br />
|
||||
不使用 git-flow 扩展时：
|
||||
```
|
||||
git checkout develop
|
||||
git checkout develop
|
||||
git checkout -b release/0.1.0
|
||||
```
|
||||
使用 git-flow 扩展时：
|
||||
```
|
||||
git flow release start 0.1.0
|
||||
```
|
||||
切换到新分支 'release/0.1.0'
|
||||
- **完成 Release Branch**： <br />
|
||||
不使用 git-flow 扩展时：
|
||||
```
|
||||
git checkout master
|
||||
git merge release/0.1.0
|
||||
```
|
||||
使用 git-flow 扩展时：
|
||||
```
|
||||
git flow release finish 0.1.0
|
||||
```
|
||||
4. **Hotfix Branch**：维护或“hotfix”分支用于快速修复生产发布。Hotfix 分支对于立即解决 master 分支中的不希望出现的问题非常必要。Hotfix 分支与 release 分支和 feature 分支类似，不同之处在于它是基于 master 分支而非 develop 分支派生的。这是唯一一个应直接从 master 分支派生的分支。修复完成后，它应该同时合并到 master 和 develop（或当前的 release 分支），并且 master 分支应该打上更新的版本号标签。
|
||||
- **创建 Hotfix Branch**： <br />
|
||||
不使用 git-flow 扩展时：
|
||||
```
|
||||
git checkout master
|
||||
git checkout -b hotfix_branch
|
||||
```
|
||||
使用 git-flow 扩展时：
|
||||
```
|
||||
git flow hotfix start hotfix_branch
|
||||
```
|
||||
- **完成 Hotfix Branch**： <br />
|
||||
不使用 git-flow 扩展时：
|
||||
```
|
||||
git checkout master
|
||||
git merge hotfix_branch
|
||||
git checkout develop
|
||||
git merge hotfix_branch
|
||||
```
|
||||
使用 git-flow 扩展时：
|
||||
```
|
||||
git branch -D hotfix_branch
|
||||
git flow hotfix finish hotfix_branch
|
||||
```
|
||||
|
||||
|
||||
## 优势
|
||||
|
||||
- 确保项目生命周期中的任何时刻分支状态保持清晰。
|
||||
- 分支的命名约定遵循系统化模式，使其更容易理解。
|
||||
- 支持大多数常用的 git 工具和扩展。
|
||||
- 适合在生产中维护多个版本。
|
||||
- 非常适合基于发布的软件工作流。
|
||||
- 提供了专门用于生产热修复的渠道。
|
||||
|
||||
|
||||
## 劣势
|
||||
|
||||
- Git 历史记录变得难以阅读。
|
||||
- master 和 develop branch的分割被认为是冗余的，并使持续交付/集成变得更加困难。
|
||||
- 不推荐用于维护生产中的单一版本。
|
||||
|
||||
|
||||
## 总结
|
||||
|
||||
我们在这里讨论了 Git Flow 工作流。Git Flow 是你和你的团队可以使用的多种 Git 工作流之一。让我们总结一下 Git Flow 的整个工作流：
|
||||
1. 从 master 创建一个 develop 分支。
|
||||
2. 从 develop 创建功能分支。
|
||||
3. 当功能完成时，将其合并到 develop 分支。
|
||||
4. 从 develop 创建一个 release 分支。
|
||||
5. 当 release 分支完成时，将其合并到 develop 和 master。
|
||||
6. 如果 master 中发现问题，则从 master 创建一个 hotfix 分支。
|
||||
7. 一旦 hotfix 完成，它将被合并到 develop 和 master。
|
||||
@@ -0,0 +1,83 @@
|
||||
# 在 Arch Linux 上安装 Git
|
||||
|
||||
要在 Arch Linux 上安装 Git，可以使用包管理器 pacman。首先，打开终端并使用以下命令更新系统：
|
||||
|
||||
```shell
|
||||
$ sudo pacman -Syu
|
||||
```
|
||||
|
||||
接下来，运行以下命令安装 Git：
|
||||
|
||||
```shell
|
||||
$ sudo pacman -S git
|
||||
```
|
||||
|
||||
要确认 Git 是否正确安装，运行以下命令：
|
||||
|
||||
```shell
|
||||
$ git --version
|
||||
```
|
||||
|
||||
你应该会看到类似以下的输出：
|
||||
|
||||
```shell
|
||||
Output
|
||||
$ git version 2.34.1
|
||||
```
|
||||
|
||||
# 设置 Git
|
||||
|
||||
配置可以通过使用 git config 命令来完成。
|
||||
具体来说，你需要提供你的名字和电子邮件地址，因为 Git 会将这些信息嵌入到你做的每个提交中。
|
||||
你可以通过输入以下命令来添加这些信息：
|
||||
|
||||
现在我们已经完成了 Git 的安装，让我们使用 "git config" 命令配置 Git 以供首次使用。
|
||||
我们需要确保你的用户名和电子邮件地址设置正确。要设置它们，使用以下命令：
|
||||
|
||||
```shell
|
||||
$ git config --global user.name "Your Name"
|
||||
$ git config --global user.email "youremail@domain.com"
|
||||
```
|
||||
|
||||
你可以通过在终端中输入以下命令来显示所有已设置的配置项：
|
||||
|
||||
```shell
|
||||
$ git config --list
|
||||
```
|
||||
|
||||
如果所有配置字段已按照你的需求设置，输出应该类似于：
|
||||
|
||||
```shell
|
||||
user.name=Your Name
|
||||
user.email=youremail@domain.com
|
||||
```
|
||||
|
||||
# 持久化 Git 凭证
|
||||
|
||||
默认情况下，Git 每次与远程仓库交互时都会提示你重新输入用户名和密码。你可以配置 Git 来缓存或存储你的凭证，以避免这种情况。以下是两种常用的方法：
|
||||
|
||||
### 1. 凭证缓存
|
||||
|
||||
Git 可以将你的凭证暂时存储在内存中，这样你就不需要频繁地重新输入它们。运行以下命令启用凭证缓存：
|
||||
|
||||
```shell
|
||||
$ git config --global credential.helper cache
|
||||
```
|
||||
|
||||
默认情况下，凭证会缓存 15 分钟。要调整超时时间（例如，1 小时），可以使用：
|
||||
|
||||
```shell
|
||||
$ git config --global credential.helper 'cache --timeout=3600'
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 2. 凭证存储
|
||||
|
||||
如果你更倾向于将凭证永久存储为明文（不太安全，但方便），可以使用以下命令：
|
||||
|
||||
```shell
|
||||
$ git config --global credential.helper store
|
||||
```
|
||||
|
||||
使用此方法时，你的凭证将以明文形式保存在 `~/.git-credentials` 文件中。特别是在共享或公共计算机上使用此方法时，请小心操作。
|
||||
@@ -0,0 +1,104 @@
|
||||
# 在 Ubuntu OS 上安装 Git
|
||||
|
||||
默认情况下，Git 很可能已经在你的 Ubuntu 操作系统中安装好了。你可以通过打开终端并输入以下命令来确认：
|
||||
|
||||
```shell
|
||||
$ git --version
|
||||
```
|
||||
|
||||
如果你看到类似下面的输出，那么恭喜你！你已经成功安装了 Git。
|
||||
|
||||
```shell
|
||||
Output
|
||||
$ git version 2.34.1
|
||||
```
|
||||
|
||||
如果适用于你，接下来可以继续进行 Git 配置,去[设置 Git](#设置-Git)。
|
||||
|
||||
如果输出中没有显示 Git 版本号，你仍然可以通过 Ubuntu 的 APT 包管理器来安装 Git。
|
||||
|
||||
首先，通过使用 apt 包管理工具更新本地包索引。返回到你的终端并输入以下命令。
|
||||
|
||||
```shell
|
||||
$ sudo apt update
|
||||
```
|
||||
|
||||
完成后，输入以下命令来安装 Git：
|
||||
|
||||
```shell
|
||||
$ sudo apt install git
|
||||
```
|
||||
|
||||
你可以通过运行以下命令并检查是否收到相关输出，来确认 Git 是否已正确安装：
|
||||
|
||||
```shell
|
||||
$ git --version
|
||||
```
|
||||
|
||||
```shell
|
||||
Output
|
||||
$ git version 2.34.1
|
||||
```
|
||||
|
||||
Git 成功安装后，接下来可以配置 Git。
|
||||
|
||||
# 设置 Git
|
||||
|
||||
配置可以通过使用 git config 命令来完成。
|
||||
具体来说，你需要提供你的名字和电子邮件地址，因为 Git 会将这些信息嵌入到你做的每个提交中。
|
||||
你可以通过输入以下命令来添加这些信息：
|
||||
|
||||
现在我们已经完成了 Git 的安装，让我们使用 "git config" 命令配置 Git 以供首次使用。
|
||||
我们需要确保你的用户名和电子邮件地址设置正确。要设置它们，使用以下命令：
|
||||
|
||||
```shell
|
||||
$ git config --global user.name "Your Name"
|
||||
$ git config --global user.email "youremail@domain.com"
|
||||
```
|
||||
|
||||
你可以通过在终端中输入以下命令来显示所有已设置的配置项：
|
||||
|
||||
```shell
|
||||
$ git config --list
|
||||
```
|
||||
|
||||
如果所有配置字段已按照你的需求设置，输出应该类似于：
|
||||
|
||||
```shell
|
||||
user.name=Your Name
|
||||
user.email=youremail@domain.com
|
||||
```
|
||||
|
||||
...
|
||||
|
||||
# 持久化 Git 凭证
|
||||
|
||||
默认情况下，Git 会在每次你推送到远程仓库时要求你输入用户名和密码。
|
||||
在 Git 中，你可以配置凭证缓存，以避免每次输入用户名和密码。以下是实现这一目标的几种方法：
|
||||
|
||||
1. 凭证缓存：Git 提供了一个凭证缓存系统，可以在指定的时间内将你的凭证存储在内存中。这样，你就不需要每次与远程仓库交互时重新输入凭证。
|
||||
|
||||
要启用凭证缓存，你可以使用以下命令：
|
||||
|
||||
```shell
|
||||
$ git config --global credential.helper cache
|
||||
```
|
||||
|
||||
默认情况下，Git 会将凭证缓存 15 分钟。你可以通过指定 --timeout 选项并跟上所需的秒数来调整缓存超时时间。
|
||||
|
||||
例如，要将缓存超时设置为 1 小时（3600 秒），可以使用：
|
||||
|
||||
```shell
|
||||
$ git config --global credential.helper 'cache --timeout=3600'
|
||||
|
||||
```
|
||||
|
||||
2. 凭证存储：这将 Git 的凭证助手设置为 "store"。使用这个凭证助手时，Git 会将远程仓库的凭证存储在磁盘上的一个明文文件中。这种方法是最简单的，但存储明文凭证的方式也是最不安全的。
|
||||
|
||||
```shell
|
||||
$ git config --global crednetial.helper store
|
||||
```
|
||||
|
||||
使用存储凭证助手时，输入的凭证会永久保存在 Linux 或 macOS 上的 ~/.git-credentials 文件中，或 Windows 上的 %USERPROFILE%\.git-credentials 文件中。这些凭证将以明文格式存储，这意味着如果有人获取到该文件，就可以读取凭证。
|
||||
|
||||
使用存储凭证助手的优点是，你每次与远程仓库交互时，不需要再次输入凭证。然而，特别是在使用共享或公共计算机时，请注意存储明文凭证的安全隐患。
|
||||
+45
@@ -0,0 +1,45 @@
|
||||
# 保持你的分叉与该仓库同步
|
||||
|
||||
首先，应该理解完整同步的流程，这一点非常重要。在这个流程中，有三个不同的仓库：我的公共仓库在 GitHub 上 `github.com/firstcontributions/first-contributions.git`，你在 GitHub 上的仓库分叉 `github.com/Your-Name/first-contributions/`，以及你本地机器上的仓库，你应该在其中进行工作。这种合作方式通常用于开源项目，称为 `Triangle Workflows`。
|
||||
|
||||
<img style="float;" src="https://firstcontributions.github.io/assets/additional-material/triangle_workflow.png" alt="triangle workflow" />
|
||||
|
||||
为了保持你的两个仓库与我的公共仓库同步，我们首先需要将公共仓库的内容拉取并与本地机器上的仓库合并。
|
||||
我们的第二步是将你的本地仓库推送到你的 GitHub 分叉。如前所述，只有通过你的分叉你才能发起一个“拉取请求”。因此，你的 GitHub 分叉是最后更新的仓库。
|
||||
|
||||
现在，让我们看看如何做到这一点：
|
||||
|
||||
首先，你必须确保自己处于主分支上。要知道自己当前在哪个分支，可以检查的第一行：
|
||||
```
|
||||
git status
|
||||
```
|
||||
如果你不在主分支上，输入以下命令切换到主分支：
|
||||
```
|
||||
git checkout main
|
||||
```
|
||||
|
||||
然后，你应该将我的公共仓库添加到你的 Git 仓库中，使用 `add upstream remote-url`：
|
||||
```
|
||||
git remote add upstream https://github.com/firstcontributions/first-contributions.git
|
||||
```
|
||||
这告诉 Git，指定的 URL 位置有该项目的另一个版本，并且我们将其命名为 `upstream`。一旦你的 Git 配置了上游仓库，你就可以拉取公共仓库的最新版本：
|
||||
```
|
||||
git fetch upstream
|
||||
```
|
||||
|
||||
你刚刚拉取了我仓库的最新版本（`upstream` 远程仓库）。现在，你需要将公共仓库的内容合并到你的主分支中：
|
||||
```
|
||||
git rebase upstream/main
|
||||
```
|
||||
在这里，你正在将公共仓库合并到你的主分支。现在，你本地机器上的主分支已更新。最后，如果你将主分支推送到你的 GitHub 分叉，那么你的 GitHub 分叉也会更新：
|
||||
```
|
||||
git push origin main
|
||||
```
|
||||
请注意，这里你推送的是名为 `origin` 的远程仓库。
|
||||
|
||||
如果你想同时将我仓库的最新更改（`upstream` 远程仓库）拉取并合并到你本地的分支中，可以直接使用：
|
||||
```
|
||||
git pull upstream main
|
||||
```
|
||||
|
||||
到目前为止，你的所有仓库都已更新。做得很好！每当你的 GitHub 仓库提示你比公共仓库落后几个提交时，你都应该执行这些操作。
|
||||
+25
@@ -0,0 +1,25 @@
|
||||
# 移动提交到不同的分支
|
||||
假设你提交了一个更改，然后意识到你提交到了错误的分支。
|
||||
你该如何更改呢？这篇教程将为你解答。
|
||||
|
||||
## 将最新的提交移动到现有分支
|
||||
为此，请输入以下命令：
|
||||
|
||||
```git reset HEAD~ --soft``` - 撤销上一个提交，但保留更改。
|
||||
```git stash``` - 记录当前目录的状态。
|
||||
|
||||
```git checkout name-of-the-correct-branch``` - 切换到正确的分支。
|
||||
```git stash pop``` - 恢复最近的存储状态。
|
||||
```git add .``` - 或者尝试单独添加文件。
|
||||
```git commit -m "your message here"``` - 保存并提交更改。
|
||||
|
||||
现在你的更改已经在正确的分支上了。
|
||||
|
||||
|
||||
### 将最新的提交移动到新分支
|
||||
为此，请输入以下命令：
|
||||
```git branch newbranch``` - 创建一个新分支，保存所有提交。
|
||||
```git reset --hard HEAD~#``` - 将 master 分支回退 # 个提交。记住，这些提交将从 master 中消失。
|
||||
```git checkout newbranch``` - 切换到你创建的新分支，所有提交都会在该分支中。
|
||||
|
||||
记住：任何未提交的更改将会丢失。
|
||||
@@ -0,0 +1,23 @@
|
||||
# 从 Git 中移除文件
|
||||
|
||||
有时你可能想要从 Git 中移除一个文件，但不想从你的计算机中删除它。你可以使用以下命令来实现：
|
||||
|
||||
``git rm <file> --cached``
|
||||
|
||||
## 那么发生了什么？
|
||||
|
||||
Git 将不再跟踪被移除文件的更改。对 Git 来说，就像你删除了这个文件一样。如果你在文件系统中找到这个文件，你会发现它依然存在。
|
||||
|
||||
注意，在上述示例中使用了 `--cached` 标志。如果我们没有加上这个标志，Git 将不仅从仓库中移除文件，还会从你的文件系统中删除它。
|
||||
|
||||
如果你使用 `git commit -m "Remove file1.js"` 提交更改，并通过 `git push origin master` 推送到远程仓库，远程仓库也会删除该文件。
|
||||
|
||||
## 其他功能
|
||||
|
||||
- 如果你想删除多个文件，可以将它们全部包含在同一命令中：
|
||||
|
||||
`git rm file1.js file2.js file3.js --cached`
|
||||
|
||||
- 你可以使用通配符（*）删除相似的文件。例如，如果你想从本地仓库中删除所有 `.txt` 文件：
|
||||
|
||||
`git rm *.txt --cached`
|
||||
+31
@@ -0,0 +1,31 @@
|
||||
# 从你的仓库中移除分支
|
||||
|
||||
如果你已经按照教程进行到此，我们的 `<add-your-name>` 分支已经完成了它的使命，是时候将其从你本地机器的仓库中删除了。虽然这不是必须的，但该分支的名称显示了它的特殊用途，因此它的生命周期可以相应地短一些。
|
||||
|
||||
首先，让我们将你的 `<add-your-name>` 合并到你的 master 分支中，因此切换到 master 分支：
|
||||
```
|
||||
git checkout master
|
||||
```
|
||||
|
||||
将 `<add-your-name>` 合并到 master:
|
||||
```
|
||||
git merge <add-your-name> master
|
||||
```
|
||||
|
||||
在你本地机器的仓库中移除`<add-your-name>` :
|
||||
```
|
||||
git branch -d <add-your-name>
|
||||
```
|
||||
|
||||
现在你已经删除了你本地机器上的 `<add-your-name>` 分支，一切看起来整洁干净。
|
||||
不过，在此时，你应该仍然在你的 GitHub 分叉中有 `<add-your-name>` 分支。然而，在删除之前，请记住，你是从这个远程分支向我的仓库提交了一个 "Pull request"。因此，除非我已经合并了这个请求，否则不要删除这个分支。
|
||||
|
||||
然而，如果我已经合并了你的分支，并且你想删除远程分支，可以使用：
|
||||
```
|
||||
git push origin --delete <add-your-name>
|
||||
```
|
||||
|
||||
现在，你知道如何整理你的分支了。
|
||||
随着时间的推移，我的公共仓库会添加很多提交。而你本地机器和 GitHub 分叉的 master 分支将不会保持同步。因此，为了保持你的仓库与我的同步，请按照下面的步骤进行操作。
|
||||
|
||||
#### [保持你的分叉与仓库同步](keeping-your-fork-synced-with-this-repository.zh-cn.md)
|
||||
@@ -0,0 +1,18 @@
|
||||
# 重置一个分支
|
||||
|
||||
`reset` 是一个可以用来重置仓库（相对于某个提交或分支）的命令。正如其名字所示，重置会丢弃当前（基础）分支上的所有内容，并使其与我们选择重置的目标分支（称为原始分支）完全相同。这实际上意味着，我们将得到一个原始分支的副本，名称为基础分支。<br/>
|
||||
然而，问题是，为什么我们不直接删除基础分支，然后从原始分支中检出一个新的基础分支呢？从技术角度来看，这将与重置具有相同的效果，但在一些工业场景下，我们无法删除分支，或者我们不能删除分支，因为删除分支可能会干扰/破坏 CI/CD 流水线，或者影响正在进行的工作流。因此，为了避免这种可能导致停机的情况，我们建议在需要重置某个分支时使用 `git reset`。
|
||||
|
||||
## 命令
|
||||
|
||||
执行 `git reset` 重置分支非常简单。
|
||||
```
|
||||
git reset <base_branch> <origin_branch>
|
||||
```
|
||||
|
||||
一个示例如下：
|
||||
```
|
||||
git reset stage master --hard
|
||||
```
|
||||
上述命令将 `stage` 分支重置为 `master`，因此 `stage` 分支将与 `master` 完全相同。
|
||||
你可能会想，为什么要使用 `--hard` 标志？这是为了忽略在重置之前或之后被暂存的所有更改。
|
||||
@@ -0,0 +1,20 @@
|
||||
# 重置一个提交
|
||||
|
||||
```reset``` 是一个用于将仓库回退到之前某个提交的命令，丢弃该提交之后的所有更改。<br/>
|
||||
重置和撤销提交的主要区别在于，git reset ```取消暂存文件并将我们的更改带回工作目录```
|
||||
而 git revert ```从远程仓库中删除提交```。<br/>
|
||||
|
||||
```git reset``` 可以通过以下命令来实现：
|
||||
- 以下命令将以两个参数的方式给出所有提交的摘要：
|
||||
|
||||
- 提交哈希的前七个字符 - 这是我们在 **reset** 命令中需要引用的内容。
|
||||
- 提交信息
|
||||
|
||||
```
|
||||
git log --oneline
|
||||
```
|
||||
|
||||
|
||||
- 可以使用以下命令将仓库重置到特定的提交：<br />
|
||||
```git reset commithash```
|
||||
其中 commithash 是我们在日志中找到的提交哈希的前 7 个字符。
|
||||
@@ -0,0 +1,36 @@
|
||||
# 什么是合并冲突？
|
||||
|
||||
当你尝试将另一个分支合并到当前工作分支时，你是在将另一个上下文的更改与当前工作文件结合在一起。
|
||||
如果两个人修改了同一文件的相同行，或者一个人决定删除该文件，而另一个人决定修改它，Git 无法识别哪个版本是正确的。Git 会标记该文件为存在冲突 - 在解决冲突之前，你无法继续工作。
|
||||
|
||||
# 如何解决合并冲突？
|
||||
|
||||
当遇到合并冲突时，Git 会通过在文件中将问题区域包裹在“<<<<<<<< HEAD”和“>>>>>>>>>>[other branch name]”中来标记冲突。
|
||||
|
||||
第一个标记后的内容来自你当前的工作分支。尖括号后，Git 会告诉我们更(改来自哪个分支)。一个“=======”行将两个冲突的更改分开。
|
||||
我们的任务是清理这些行：当我们完成后，文件应该看起来正是我们想要的样子。建议咨询写入冲突更改的队友，决定哪个版本应该是最终的。可能是你们其中一个的版本，也可能是两者的混合。
|
||||
|
||||
例如：
|
||||
```
|
||||
<<<<<<< HEAD:mergetest
|
||||
This is my third line
|
||||
=======
|
||||
This is a fourth line I am adding
|
||||
>>>>>>> 4e2b407f501b68f8588aa645acafffa0224b9b78:mergetest
|
||||
```
|
||||
|
||||
`<<<<<<<`：表示合并冲突行的开始。第一组行来自你试图合并更改的文件。
|
||||
`=======`：表示用于比较的断点。分隔用户提交的更改（上方）和来自合并的更改（下方），以便直观地看到差异。
|
||||
`>>>>>>>`：表示合并冲突行的结束。
|
||||
|
||||
你可以通过编辑文件来解决冲突，然后手动合并 Git 难以合并的部分。这可能意味着丢弃你的更改或别人的更改，或者两者的混合。你还需要删除文件中的 '<<<<<<<'、'=======' 和 '>>>>>>>'。
|
||||
|
||||
|
||||
一旦解决了冲突，请使用 `git add` 命令。不要忘记运行测试，因为你需要确保已正确解决冲突。
|
||||
|
||||
你还可以根据所使用的 IDE 下载不同的插件，以便更轻松地解决合并冲突。
|
||||
|
||||
|
||||
# 如何撤销合并？
|
||||
|
||||
如果你想撤销合并，可以使用 `git merge --abort`。
|
||||
@@ -0,0 +1,41 @@
|
||||
# 撤销一个提交
|
||||
|
||||
撤销一个提交意味着创建一个全新的提交，撤销之前提交所做
|
||||
的所有更改。这就像在 Git 中执行 `CTRL + Z`。
|
||||
|
||||
在 Git 中，撤销操作变得更加简单，因为你推送到远程仓库的每个提交都有一个唯一的字母数字键（称为 SHA，安全哈希算法）与之关联。
|
||||
这意味着只要你有该提交的 SHA，你就可以撤销任何提交。
|
||||
但你必须小心按顺序撤销操作，以免破坏你的仓库。
|
||||
|
||||
|
||||
为了获取我们想要撤销的特定提交的 SHA，查看所有提交的日志会很有帮助。
|
||||
要获取此信息，我们可以运行命令：
|
||||
```git log --oneline ```
|
||||
仅运行 ```git log``` 命令也会给我们返回 SHA（长格式）。
|
||||
但使用 ```--oneline``` 标志会告诉 Git 我们希望以简洁（单行）的方式显示，以便更容易阅读。
|
||||
|
||||
当你运行此命令时，显示的前 7 个字符就是所谓的简短提交哈希。
|
||||
|
||||
例如，运行 ```git log --oneline``` 时，我得到的输出如下：
|
||||
```
|
||||
389004d added spacing in title
|
||||
c1b9fc1 Merge branch 'master' into tutorials
|
||||
77eaafd added tutorial for reverting a commit
|
||||
```
|
||||
|
||||
这表明，通过使用 ```git log --oneline```，我们可以获取仓库中所有提交的列表，并附带每个提交的前 7 个字符的 SHA。
|
||||
|
||||
现在，假设我想撤销我提交的 "在标题中添加了空格" 这个更改，以下是我将采取的步骤：
|
||||
|
||||
* 复制该提交的 SHA，在本例中是 ```389004d```
|
||||
* 然后运行命令 ```git revert 389004d```
|
||||
|
||||
这将打开我的文本编辑器，并提示我编辑提交信息。
|
||||
你可以选择保留 Git 的默认提交信息，该信息以 `Revert` 开头，
|
||||
也可以根据自己的喜好自定义提交信息。
|
||||
|
||||
* 接下来，我将保存并关闭文本编辑器。
|
||||
* 返回命令行。
|
||||
* 运行 ```git push origin <branch-name>``` 将撤销的更改推送到 GitHub。
|
||||
|
||||
就这样，变更被撤销。在这种情况下，我的仓库将恢复到 ```c1b9fc1``` 时的状态。
|
||||
@@ -0,0 +1,88 @@
|
||||
# 什么是 Squashing（压缩提交）？
|
||||
|
||||
在 Git 中，**squashing（压缩提交）** 是指重写提交历史，把多个提交合并成一个提交，并添加一个描述性信息来说明这次更改的内容。
|
||||
|
||||
在开源项目中，这通常是常见操作，因为分支的详细历史记录往往只对原始开发者有意义。
|
||||
压缩提交可以简化更改记录，也方便在需要时进行回滚。
|
||||
|
||||
# 如何进行提交压缩（Squash commits）？
|
||||
|
||||
首先，你可以执行 `git log` 命令，查看你当前分支中要合并的提交历史：
|
||||
|
||||
```
|
||||
git log
|
||||
```
|
||||
|
||||
你会看到类似这样的提交记录：
|
||||
|
||||
```
|
||||
commit blablabla
|
||||
Author: omguhh
|
||||
Date: 10/10/20
|
||||
提交信息 1
|
||||
|
||||
commit blablabla2
|
||||
Author: omguhh
|
||||
Date: 10/10/20
|
||||
提交信息 2
|
||||
```
|
||||
|
||||
现在你已经找到了要合并的提交，可以使用 ```git rebase```来进行压缩。假设你已经熟悉 ```git rebase```，我们可以通过 **交互模式（interactive mode）** 来进行操作：
|
||||
|
||||
```
|
||||
git rebase -i
|
||||
```
|
||||
|
||||
你也可以通过指定回溯的提交数来启动交互式 rebase，比如：
|
||||
|
||||
```
|
||||
git rebase -i HEAD~2
|
||||
```
|
||||
|
||||
执行该命令后，你将看到类似以下内容的交互式界面：
|
||||
|
||||
```
|
||||
pick blablabla Changing test01.txt file
|
||||
pick blablabla2 Adding dummy01.txt file
|
||||
|
||||
#
|
||||
# 可用命令：
|
||||
# p, pick = 使用该提交
|
||||
# r, reword = 使用该提交，但修改提交信息
|
||||
# e, edit = 使用该提交，但中断以进行修改
|
||||
# s, squash = 使用该提交，但合并进前一个提交
|
||||
# f, fixup = 类似 squash，但忽略该提交信息
|
||||
# x, exec = 执行 shell 命令
|
||||
#
|
||||
# 你可以调整这些行的顺序，Git 会按顺序执行。
|
||||
#
|
||||
# 如果删除某一行，该提交将会丢失。
|
||||
#
|
||||
# 如果删除所有行，rebase 将会被取消。
|
||||
#
|
||||
# 空提交将会被注释掉。
|
||||
```
|
||||
|
||||
所以，如果你想将 ```blablabla2``` 压缩到 ```blablablabla```，你应该将其改成如下形式：
|
||||
|
||||
```
|
||||
pick blablabla 更改 test01.txt 文件
|
||||
squash blablabla2 添加 dummy01.txt 文件
|
||||
|
||||
```
|
||||
|
||||
一切正常的话，你将看到如下合并提交的编辑界面：
|
||||
|
||||
```
|
||||
# 这是两个提交的合并结果.
|
||||
# 第一个提交的信息是：
|
||||
提交信息 1
|
||||
|
||||
# 第二个提交的信息是：
|
||||
|
||||
提交信息 2
|
||||
```
|
||||
|
||||
你可以在此自由修改合并提交的信息。
|
||||
|
||||
退出并保存后，执行 `git log` 命令应显示你刚刚输入的合并信息，且这两个提交已被合并为一个。
|
||||
@@ -0,0 +1,161 @@
|
||||
# 使用 Git Stash 暂存工作进度
|
||||
|
||||
如果你正在进行一个大型开发任务，突然需要切换分支去做其他事情，但当前代码还没写完、也没有测试，
|
||||
你可能并不希望提交这些不完整的更改。可 Git 不允许你直接切换分支，除非先处理这些更改。
|
||||
那该怎么办呢？如何避免提交未完成的代码，同时还能自由切换分支？
|
||||
|
||||
这就是本教程要讲解的内容。
|
||||
|
||||
## 暂存你的工作（Stashing）
|
||||
|
||||
假设你在项目的某个分支中修改了一些文件，此时运行 ```git status``` 可以看到：
|
||||
|
||||
```
|
||||
$ git status
|
||||
# 当前分支：master
|
||||
# 暂存区中的更改：
|
||||
# (使用 "git reset HEAD <file>..." 来取消暂存)
|
||||
#
|
||||
# 修改: index.html
|
||||
#
|
||||
# 未暂存的更改：
|
||||
# (使用 "git add <file>..." 来更新将要提交的内容)
|
||||
#
|
||||
# 修改: lib/simplegit.rb
|
||||
#
|
||||
```
|
||||
|
||||
此时你想切换分支，但又不想提交更改。那就使用 ```git stash```:
|
||||
|
||||
```
|
||||
$ git stash
|
||||
Saved working directory and index state \
|
||||
"WIP on master: 049d078 added the index file"
|
||||
HEAD is now at 049d078 added the index file
|
||||
(要恢复这些更改，输入 "git stash apply")
|
||||
```
|
||||
|
||||
现在你的工作目录是干净的，可以使用 ```git status``` 查看：
|
||||
|
||||
```
|
||||
$ git status
|
||||
# 当前分支：master
|
||||
没有要提交的内容，工作目录干净
|
||||
```
|
||||
|
||||
此时你可以切换到任意分支继续开发。你 stash 的内容被保存在一个栈（stack）中。你可以使用 ```git stash list``` 查看所有保存的 stash：
|
||||
|
||||
```
|
||||
$ git stash list
|
||||
stash@{0}: WIP on master: 049d078 added the index file
|
||||
stash@{1}: WIP on master: c264051 Revert "added file_size"
|
||||
stash@{2}: WIP on master: 21d80a5 added number to log
|
||||
```
|
||||
|
||||
如果你想重新应用刚刚保存的 stash，可以使用 ```git stash apply```。默认情况下，它会应用最近一次保存的 stash。
|
||||
如果你想应用指定的 stash，可以使用命令 ```git stash apply <stash-name>```，将 `<stash-name>` 替换为对应名称：
|
||||
|
||||
```
|
||||
$ git stash apply
|
||||
# 当前分支：master
|
||||
# 未暂存的更改：
|
||||
# (使用 "git add <file>..." 来更新将要提交的内容)
|
||||
#
|
||||
# 修改： index.html
|
||||
# 修改： lib/simplegit.rb
|
||||
#
|
||||
```
|
||||
|
||||
你会发现 Git 恢复了你在执行 stash 时未提交的更改。
|
||||
在这个示例中，你在应用 stash 时处于干净的工作目录，且是在与 stash 创建时相同的分支；
|
||||
但请注意：**并不要求工作目录必须干净，也不需要在原分支才能成功应用 stash。**
|
||||
|
||||
你可以在一个分支中保存 stash，之后切换到另一个分支并重新应用它。
|
||||
即使当前工作目录中存在未提交的更改，也可以应用 stash；但如果某些内容无法干净地应用，Git 会提示合并冲突。
|
||||
|
||||
文件中的更改虽然恢复了，但之前已暂存（staged）的文件并没有恢复到暂存区。
|
||||
要恢复这些被暂存的更改，你需要使用带有 ```--index``` 参数的 ```git stash apply```：
|
||||
|
||||
```
|
||||
$ git stash apply --index
|
||||
# 当前分支： master
|
||||
# 已暂存更改：
|
||||
# (使用 "git reset HEAD <file>..." 取消暂存)
|
||||
#
|
||||
# 修改： index.html
|
||||
#
|
||||
# 未暂存更改：
|
||||
# (使用 "git add <file>..." to update what will be committed)
|
||||
#
|
||||
# 修改： lib/simplegit.rb
|
||||
#
|
||||
```
|
||||
|
||||
`apply` 命令仅仅是恢复 stash 内容，它不会自动从 stash 栈中移除对应条目。
|
||||
|
||||
如果你想删除某个 stash，可以使用 ```git stash drop``` 并指定 stash 名称：
|
||||
|
||||
```
|
||||
$ git stash list
|
||||
stash@{0}: WIP on master: 049d078 added the index file
|
||||
stash@{1}: WIP on master: c264051 Revert "added file_size"
|
||||
stash@{2}: WIP on master: 21d80a5 added number to log
|
||||
$ git stash drop stash@{0}
|
||||
Dropped stash@{0} (364e91f3f268f0900bc3ee613f9f733e82aaed43)
|
||||
```
|
||||
|
||||
你也可以使用 ```git stash pop``` 命令，它会应用最后一次 stash 的内容并将其从栈中删除。
|
||||
|
||||
## 取消应用已应用的 Stash（Un-applying）
|
||||
|
||||
有时你应用了 stash，做了一些工作，但之后想要**撤销**刚刚恢复的 stash 更改。
|
||||
Git 并没有内建 ```git unapply``` 命令，但你可以使用“反向补丁”来实现类似效果：
|
||||
|
||||
```$ git stash show -p stash@{0} | git apply -R```
|
||||
|
||||
如果不指定 stash，Git 默认使用最新的 stash：
|
||||
|
||||
```$ git stash show -p | git apply -R```
|
||||
|
||||
你也可以为此配置一个快捷别名：
|
||||
|
||||
```
|
||||
$ git config --global alias.stash-unapply '!git stash show -p | git apply -R'
|
||||
$ git stash apply
|
||||
$ #... 进行工作
|
||||
$ git stash-unapply
|
||||
```
|
||||
|
||||
## 从 Stash 创建新分支
|
||||
|
||||
如果你 stash 了某些更改，但后来继续在该分支上进行开发，
|
||||
再次应用 stash 时可能会因为文件已被修改而引发**冲突**。
|
||||
|
||||
如果你想更方便地重新测试 stash 的内容，可以使用 ```git stash branch``` 命令。
|
||||
它会执行以下操作：
|
||||
|
||||
1. 创建一个新分支；
|
||||
2. 回到你 stash 时所在的提交；
|
||||
3. 应用 stash 内容；
|
||||
4. 应用成功后自动删除 stash。
|
||||
|
||||
示例：
|
||||
|
||||
```
|
||||
$ git stash branch testchanges
|
||||
Switched to a new branch "testchanges"
|
||||
# 当前分支： testchanges
|
||||
# 已暂存的更改：
|
||||
# (使用 "git reset HEAD <file>..." 取消暂存)
|
||||
#
|
||||
# 修改: index.html
|
||||
#
|
||||
# 未暂存的更改：
|
||||
# (使用 "git add <file>..." 来更新将要提交的内容)
|
||||
#
|
||||
# 修改: lib/simplegit.rb
|
||||
#
|
||||
Dropped refs/stash@{0} (f0dfc4d5dc332d1cee34a634182e168c4efc3359)
|
||||
```
|
||||
|
||||
这是一个非常实用的快捷方式，可以轻松恢复你 stash 的内容，并在一个新分支中继续开发。
|
||||
@@ -0,0 +1,52 @@
|
||||
# 存储凭据（用户名与密码）
|
||||
|
||||
你可能遇到过这样的烦恼——每次访问仓库都要输入用户名和密码，这很麻烦，而且若耗时过长还会打断你的工作流。
|
||||
但其实没必要如此繁琐。
|
||||
|
||||
这里我们介绍一种常见的方式： [git credential cache](https://git-scm.com/docs/git-credential-cache)。
|
||||
|
||||
**注意：** 请遵循你所在单位或学校的安全策略。
|
||||
|
||||
## 凭据缓存（Caching）
|
||||
|
||||
我们可以使用 Git 的 credential cache 来存储用户名和密码。
|
||||
|
||||
**警告：** 此方法会将凭据以*明文*形式保存在你电脑的硬盘上。
|
||||
任何人都可以访问该文件，比如恶意的 NPM 模块。
|
||||
|
||||
### 全局凭据缓存
|
||||
|
||||
如果你希望为所有仓库启用凭据缓存，只需执行以下命令：
|
||||
|
||||
```
|
||||
$ git config --global credential.helper cache
|
||||
```
|
||||
|
||||
**提醒：** 请遵循你所在单位或学校的安全策略。
|
||||
|
||||
### 仓库级别的凭据缓存
|
||||
|
||||
如果你只想为当前仓库启用缓存，可以使用以下命令：
|
||||
|
||||
```
|
||||
$ git config credential.helper cache
|
||||
```
|
||||
|
||||
**提醒：** 请遵循你所在单位或学校的安全策略。
|
||||
|
||||
### 缓存超时时间
|
||||
|
||||
如果不指定缓存时间，凭据可能会被永久保留在内存中。
|
||||
你可以通过以下命令设置缓存的持续时间（单位为秒）：
|
||||
|
||||
```
|
||||
git config credential.helper 'cache --timeout=<timeout>'
|
||||
```
|
||||
|
||||
使用此 helper，凭据只会存储在内存中，不会写入磁盘，且在指定时间后会自动清除。
|
||||
默认超时时间是 900 秒（15 分钟）。
|
||||
|
||||
#### 参考资料：
|
||||
[Stack Overflow](https://stackoverflow.com/questions/35942754/how-can-i-save-username-and-password-in-git)
|
||||
|
||||
### [附加材料](additional-material.md)
|
||||
@@ -0,0 +1,59 @@
|
||||
# 撤销本地提交
|
||||
|
||||
要撤销本地提交，只需要运行以下命令：
|
||||
```
|
||||
git reset
|
||||
```
|
||||
此命令会将暂存区（staging area）重置为你最近的一次提交，但工作目录中的更改不会被影响。
|
||||
因此，你仍然可以重新提交这些更改。
|
||||
|
||||
如果你只是想从上一次提交中移除某个文件，可以使用以下命令：
|
||||
```
|
||||
git reset <文件名>
|
||||
```
|
||||
该命令只会将指定的文件从暂存区中移除，但文件中的更改仍然保留。
|
||||
|
||||
```git reset``` 使用示例：
|
||||
```
|
||||
# 修改了 index.php 和 tutorial.php
|
||||
# 将文件添加到暂存区
|
||||
$ git add .
|
||||
# 想起来这两个文件应该分开提交
|
||||
# 取消暂存 tutorial.php
|
||||
$ git reset tutorial.php
|
||||
# 先提交 index.php
|
||||
$ git commit -m "Changed index.php"
|
||||
# 现在提交 tutorial.php
|
||||
$ git add tutorial.php
|
||||
$ git commit -m "修改了 tutorial.php"
|
||||
```
|
||||
|
||||
假设你把本地仓库搞乱了，只想恢复到最近一次提交的状态，
|
||||
你可以运行以下命令：
|
||||
```
|
||||
git reset --hard
|
||||
```
|
||||
这个命令不仅会重置暂存区，还会把工作目录中的所有更改回退到最近一次提交。
|
||||
其中的 ```--hard``` 模式表示 Git 会同时撤销工作目录中的所有改动。
|
||||
**只有当你确定想彻底丢弃本地的所有开发内容时，才应该使用这个命令。**
|
||||
|
||||
```git reset --hard``` 使用示例：
|
||||
```
|
||||
# 决定开始一个疯狂的实验
|
||||
# 创建一个新文件 'crazy.php' 并写入一些代码
|
||||
# 提交 crazy.php
|
||||
$ git add crazy.php
|
||||
$ git commit -m "开始了疯狂的开发"
|
||||
# 再次编辑 crazy.php 并修改了很多其他文件
|
||||
# 提交所有被跟踪的文件
|
||||
$ git add .
|
||||
$ git commit -m "继续开发"
|
||||
# 测试后情况失控
|
||||
# 决定把所有内容撤销
|
||||
$ git reset --hard HEAD~2
|
||||
```
|
||||
|
||||
```git reset --hard HEAD~2``` 会将当前分支回退两个提交点，
|
||||
同时撤销你所做的所有更改，并将这两个提交从项目历史中移除。
|
||||
|
||||
注意： 如果你已经将提交推送到了共享仓库，请不要执行 ```git reset --hard``` 因为这将对仓库中的其他人造成问题。
|
||||
@@ -0,0 +1,71 @@
|
||||
# 为什么在贡献时要使用分支
|
||||
|
||||
## 什么是分支？
|
||||
|
||||
分支（Branch）本质上是指向某个提交（commit）的指针。
|
||||
|
||||
当你创建分支时，Git 会基于你当前的代码状态生成一个新的快照，你可以在这个分支上自由修改，而不会影响主代码（通常是 master 分支）。
|
||||
|
||||
当你对实验结果满意并希望将其合并进主代码时，只需运行：
|
||||
<branch name> master.
|
||||
这会告诉 Git：将你在实验分支上的更改合并到 master 主分支中。
|
||||
|
||||
在多人参与的开源项目中，使用分支可以让每位贡献者独立开发，不影响主分支，从而更方便地合并最合适的代码。
|
||||
|
||||
## 它是如何工作的？
|
||||
|
||||
分支代表了一条独立的开发路径。
|
||||
分支是编辑/暂存/提交流程的抽象表现。你可以将其想象为：为你开辟了一套新的工作目录、暂存区和项目历史。
|
||||
|
||||
新提交会被记录在当前分支的历史中，从而在项目历史中形成一个“分叉”。
|
||||
|
||||
`git branch` 命令可用于创建、列出、重命名和删除分支。
|
||||
但它并不能用于切换分支或合并历史记录。因此，它通常与 `git checkout` 和 `git merge` 命令一起使用。
|
||||
|
||||
## 为什么要使用分支？
|
||||
|
||||
如果你仍然在思考“为什么我们要在版本控制中使用分支？”，那这里有一个简单的例子可以说明：
|
||||
|
||||
假设某款量产汽车在正式发布前需要喷漆，原定默认颜色为“橄榄绿”，但制造团队的一些成员想展示“红色”版本。
|
||||
|
||||
为了避免混乱，“红色喷漆”就像是主项目（汽车）的一个分支。
|
||||
如果将该分支合并进主项目，那么最终的颜色就是红色；如果不合并，则继续使用橄榄绿。
|
||||
|
||||
是否将某个贡献者的分支合并进主分支，通常由项目负责人决定。
|
||||
|
||||
## 举个例子
|
||||
|
||||
Alice 在开发功能 A，Bob 在开发功能 B。
|
||||
Alice 完成功能 A 一半后，提交了几次；但功能 A 实在太复杂，于是她决定先去开发功能 C，并继续在同一分支（alice）提交。
|
||||
|
||||
与此同时，Bob 完成功能 B 后，打算接手功能 A，于是他把 alice 分支合并到了自己的 bob 分支中。
|
||||
|
||||
等 Bob 完成功能 A 后，准备将 bob 分支合并进 master。
|
||||
但 bob 分支此时包含了功能 A、功能 B 和部分功能 C，而功能 C 还没完成！
|
||||
|
||||
这就很容易在合并时引发混乱的冲突。
|
||||
|
||||
解决办法是：不要用“人名分支”，而应该使用“功能分支”。
|
||||
Alice 应该为功能 A 和功能 C 分别创建分支；Bob 应该为功能 B 和功能 A 分别创建分支。
|
||||
这样，他们就能并行开发各自的功能，互不干扰。
|
||||
|
||||
## 如何创建分支？
|
||||
|
||||
#### 创建分支
|
||||
|
||||
```
|
||||
git branch 任意分支名
|
||||
```
|
||||
|
||||
这将新建一个名为“任意分支名”的分支。
|
||||
在这个分支上进行的更改不会影响主分支。
|
||||
详细教程请参考： [如何创建分支](https://www.atlassian.com/git/tutorials/using-branches)
|
||||
|
||||
#### 删除分支
|
||||
|
||||
```
|
||||
git branch -d 任意分支名
|
||||
```
|
||||
|
||||
此命令会从 Git 仓库中删除名为“任意分支名”的分支。
|
||||
参考： [如何从仓库中移除分支](https://github.com/jashnimje/first-contributions/blob/7dcae72208e4b42fcf834b4f189fa8ee78238077/additional-material/git_workflow_scenarios/removing-branch-from-your-repository.md)
|
||||
@@ -0,0 +1,140 @@
|
||||
[](https://github.com/ellerbrock/open-source-badges/)
|
||||
[<img align="right" width="150" src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-desktop-old-version-tutorial/join-slack-team.png">](https://join.slack.com/t/firstcontributors/shared_invite/zt-1hg51qkgm-Xc7HxhsiPYNN3ofX2_I8FA)
|
||||
[](https://opensource.org/licenses/MIT)
|
||||
[](https://www.codetriage.com/roshanjossey/first-contributions)
|
||||
|
||||
# First Contributions（首次贡献）
|
||||
|
||||
| <img alt="Git Bash" src="https://cdn.icon-icons.com/icons2/2699/PNG/512/git_scm_logo_icon_170096.png" width="200"> | Git Bash Edition |
|
||||
| ------------------------------------------------------------------------------------------------------------------ | ---------------- |
|
||||
|
||||
第一次做一件事总是很难，特别是涉及协作的时候，犯错并不是一件让人舒服的事。但开源正是关于协作与共同进步的。我们希望简化新手首次学习和参与开源贡献的流程。
|
||||
|
||||
阅读文章和看教程固然有用，但没有什么比“亲自动手且不会搞砸任何事情”更有效。本项目旨在为新手提供引导，简化首次贡献的过程。请记住：你越放松，学得越快。如果你正想要完成你的第一次贡献，只需按照下列简单步骤操作。我们保证这将非常有趣！
|
||||
|
||||
如果你还没有在 Windows 上安装 Git Bash，请[点击这里安装](https://git-scm.com/download/win)。
|
||||
|
||||
<img align="right" width="300" src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-desktop-tutorial/fork.png" alt="fork this repository" />
|
||||
|
||||
## Fork 本仓库
|
||||
|
||||
点击本页面右上角的 Fork 按钮，即可 Fork 此仓库。
|
||||
|
||||
这将在你的 GitHub 账户中创建一个副本。
|
||||
|
||||
## 克隆这个仓库
|
||||
现在将此仓库克隆到你的本地机器。
|
||||
|
||||
**重要：不要克隆原始仓库。请到你自己的 fork 页面进行克隆。**
|
||||
|
||||
点击 "Code"，然后复制下方的链接。
|
||||
|
||||
<img src="https://firstcontributions.github.io/assets/cli-tool-tutorials/git-bash-windows-tutorial/gb-clone-1.png" alt="copy string" />
|
||||
|
||||
打开你刚下载的 Git Bash 应用。如果是在 Windows 上，它看起来应该如下图所示。
|
||||
|
||||
<img src="https://firstcontributions.github.io/assets/cli-tool-tutorials/git-bash-windows-tutorial/gb-terminal-1.png" alt="open git bash terminal" />
|
||||
|
||||
使用以下命令进入你希望保存项目的文件夹：
|
||||
|
||||
```bash
|
||||
cd <folder>
|
||||
```
|
||||
|
||||
<img src="https://firstcontributions.github.io/assets/cli-tool-tutorials/git-bash-windows-tutorial/gb-terminal-2.png" alt="cd into a folder" />
|
||||
|
||||
使用你刚刚复制的链接，运行以下命令克隆仓库：
|
||||
|
||||
```bash
|
||||
git clone <repo-url>
|
||||
```
|
||||
|
||||
<img src="https://firstcontributions.github.io/assets/cli-tool-tutorials/git-bash-windows-tutorial/gb-clone-2.png" alt="clone the repository" />
|
||||
|
||||
进入该目录，并在 VS Code 中打开项目进行修改。
|
||||
|
||||
<img src="https://firstcontributions.github.io/assets/cli-tool-tutorials/git-bash-windows-tutorial/gb-terminal-3.png" alt="cd into the newly cloned repo" />
|
||||
|
||||
## 创建分支
|
||||
|
||||
使用以下命令创建分支并切换到该分支：
|
||||
|
||||
```bash
|
||||
git checkout -b <branch-name>
|
||||
```
|
||||
|
||||
将 `<add-your-name>`替换为例如 "add-james-smith" 的格式。
|
||||
|
||||
<img src="https://firstcontributions.github.io/assets/cli-tool-tutorials/git-bash-windows-tutorial/gb-branch.png" alt="create a branch" />
|
||||
|
||||
## 做出必要修改并提交更改
|
||||
|
||||
使用文本编辑器打开 `Contributors.md` 文件，滚动到页面底部，添加你的名字，然后保存文件。
|
||||
|
||||
例如，如果你叫 James Smith，添加如下内容：
|
||||
|
||||
\[James Smith](https://github.com/jamessmith)
|
||||
|
||||
你可以通过运行以下命令查看是否有文件更改：
|
||||
|
||||
```bash
|
||||
git status
|
||||
```
|
||||
|
||||
<img src="https://firstcontributions.github.io/assets/cli-tool-tutorials/git-bash-windows-tutorial/gb-status.png" alt="check the status" />
|
||||
|
||||
现在提交你的更改：
|
||||
|
||||
首先将更改添加到暂存区：
|
||||
|
||||
```bash
|
||||
git add file-name
|
||||
```
|
||||
|
||||
然后使用以下命令提交更改：
|
||||
|
||||
```bash
|
||||
git commit -m "Add your-name to Contributors list"
|
||||
```
|
||||
|
||||
请将 `<your-name>` 替换为你的名字。
|
||||
|
||||
<img src="https://firstcontributions.github.io/assets/cli-tool-tutorials/git-bash-windows-tutorial/gb-commit.png" alt="commit changes" />
|
||||
|
||||
你可以使用 `git log --oneline` 命令确认提交记录。
|
||||
|
||||
## 推送更改到 GitHub
|
||||
|
||||
完成上述步骤后，使用以下命令将更改推送到 GitHub：
|
||||
|
||||
```bash
|
||||
git push origin <branch-name>
|
||||
```
|
||||
|
||||
<img src="https://firstcontributions.github.io/assets/cli-tool-tutorials/git-bash-windows-tutorial/gb-push.png" alt="push changes" />
|
||||
|
||||
## 提交更改供审查
|
||||
|
||||
访问你的 GitHub 仓库页面，会看到 `Compare & pull request` 按钮。点击它。
|
||||
|
||||
<img src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-desktop-tutorial/compare-and-pull.png" alt="create a pull request" />
|
||||
|
||||
点击提交 pull request.
|
||||
|
||||
<img src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-desktop-tutorial/submit-pull-request.png" alt="submit pull request" />
|
||||
|
||||
不久之后，我会将你的更改合并到主分支中。合并后你会收到邮件通知。
|
||||
|
||||
## Where to go from here?
|
||||
|
||||
恭喜你！你刚完成了标准的 - fork -> clone -> edit -> PR 工作流程，这是你未来在开源项目中常会用到的模式！
|
||||
|
||||
你可以通过访问 [web app](https://firstcontributions.github.io#social-share)与朋友分享你的贡献。
|
||||
|
||||
如果你有任何问题或需要帮助，欢迎加入我们的 Slack 团队： [Join slack team](https://join.slack.com/t/firstcontributors/shared_invite/zt-1hg51qkgm-Xc7HxhsiPYNN3ofX2_I8FA).
|
||||
|
||||
### [Additional material](../additional-material/git_workflow_scenarios/additional-material.md)
|
||||
|
||||
## 使用其他工具的教程
|
||||
|
||||
[Back to main page](https://github.com/firstcontributions/first-contributions#tutorials-using-other-tools)
|
||||
@@ -0,0 +1,109 @@
|
||||
[](https://github.com/ellerbrock/open-source-badges)
|
||||
[<img align="right" width="150" src="https://firstcontributions.github.io/assets/gui-tool-tutorials/github-desktop-tutorial/join-slack-team.png">](https://join.slack.com/t/firstcontributors/shared_invite/enQtNjkxNzQwNzA2MTMwLTVhMWJjNjg2ODRlNWZhNjIzYjgwNDIyZWYwZjhjYTQ4OTBjMWM0MmFhZDUxNzBiYzczMGNiYzcxNjkzZDZlMDM)
|
||||
[](https://opensource.org/licenses/MIT)
|
||||
[](https://www.codetriage.com/roshanjossey/first-contributions)
|
||||
|
||||
# First Contributions （首次贡献）
|
||||
|
||||
| <img alt="GitHub Desktop" src="https://cdn.icon-icons.com/icons2/2157/PNG/512/github_git_hub_logo_icon_132878.png" width="200"> | GitHub 命令行工具 (CLI) |
|
||||
| ------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------- |
|
||||
|
||||
这是给我们这些终端爱好者准备的指南，感谢 [Github-CLI](https://cli.github.com/)，我们可以在终端中完成所有事情。你的第一次贡献应该是有趣、有成就感的，它将激励你继续前进！
|
||||
|
||||
这个指南稍微有些挑战，因为我们不会使用任何图形界面。但它仍然非常有趣，并且你一定可以跟得上！
|
||||
|
||||
你需要准备以下工具：
|
||||
|
||||
- 安装 Git (如何安装 [git](https://git-scm.com/downloads))
|
||||
- Github 账户
|
||||
|
||||
现在我们需要在系统中安装 `github-cli` 工具，方法请见[官方文档](https://github.com/cli/cli#installation)
|
||||
|
||||
接着输入以下命令登录 CLI：
|
||||
|
||||
```bash
|
||||
gh auth login
|
||||
```
|
||||
|
||||
按照指示完成登录，我们就准备好了！
|
||||
|
||||
# Fork 这个仓库
|
||||
|
||||
只需运行以下命令即可：
|
||||
|
||||
```bash
|
||||
gh repo fork firstcontributions/first-contributions
|
||||
```
|
||||
|
||||
**重要提示：命令会提示你是否需要克隆仓库，请选择 “yes”**
|
||||
|
||||
# 创建你的分支
|
||||
|
||||
使用 Git 创建一个新分支，命名时请用你的名字替换示例中的部分，例如：
|
||||
|
||||
```bash
|
||||
git switch -c add-john-doe
|
||||
```
|
||||
|
||||
# 做出必要更改并提交
|
||||
|
||||
现在，你可以用文本编辑器打开 `Contributors.md` 文件并添加你的名字。将你的名字加在文件的任何地方，然后保存文件。
|
||||
|
||||
在项目目录中执行 `git status` 命令查看更改。
|
||||
<img align="right" width="450" src="https://firstcontributions.github.io/assets/Readme/git-status.png" alt="git status" />
|
||||
|
||||
使用 `git add` 命令将更改添加到你刚创建的分支：
|
||||
`git add Contributors.md`
|
||||
|
||||
然后使用 `git commit` 命令提交更改：
|
||||
`git commit -m "Add your-name to Contributors list`
|
||||
请将 `your-name` 替换为你的名字。
|
||||
|
||||
# 推送更改到 GitHub
|
||||
|
||||
使用下面的命令推送更改：
|
||||
|
||||
```
|
||||
git push origin -u your-branch-name
|
||||
```
|
||||
|
||||
请将 `your-branch-name` 替换为你之前创建的分支名称。
|
||||
|
||||
<details>
|
||||
<summary> <strong>如果在推送过程中出现错误，请点击这里：</strong> </summary>
|
||||
|
||||
- ### 身份验证错误
|
||||
<pre>remote: Support for password authentication was removed on August 13, 2021. Please use a personal access token instead.
|
||||
remote: Please see https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/ for more information.
|
||||
fatal: Authentication failed for 'https://github.com/<your-username>/first-contributions.git/'</pre>
|
||||
请参考 [GitHub's tutorial](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account) 来生成并配置 SSH key。
|
||||
|
||||
</details>
|
||||
|
||||
# 提交你的更改以供审查
|
||||
|
||||
在你的仓库目录下运行以下命令来创建 Pull Request：
|
||||
|
||||
```bash
|
||||
gh pr create --repo firstcontributions/first-contributions
|
||||
```
|
||||
|
||||
接着提交 Pull Request。
|
||||
|
||||
你可以使用 `gh status` 命令来查看你的 PR 状态。
|
||||
|
||||
## 接下来做什么？
|
||||
|
||||
恭喜你！你刚完成了一个常见的开源贡献流程 — fork -> clone -> edit -> pull request！
|
||||
|
||||
你可以通过访问 [web app](https://firstcontributions.github.io/#social-share) 与朋友和关注者分享你的贡献。
|
||||
|
||||
如果你有任何疑问或需要帮助，也可以加入我们的 Slack 团队：[Join slack team](https://join.slack.com/t/firstcontributors/shared_invite/zt-vchl8cde-S0KstI_jyCcGEEj7rSTQiA)。
|
||||
|
||||
现在你可以开始为其他项目做贡献了。我们收集了一些适合入门的项目，你可以在[the list of projects in the web app](https://firstcontributions.github.io/#project-list)上查看。
|
||||
|
||||
### [Additional material](additional-material/git_workflow_scenarios/additional-material.md)
|
||||
|
||||
## 使用其他工具的教程
|
||||
|
||||
[Back to main page](https://github.com/firstcontributions/first-contributions#tutorials-using-other-tools)
|
||||
@@ -8,6 +8,8 @@
|
||||
|
||||
Ler artigos e ver tutoriais pode ajudar, mas nada melhor do que realmente "pôr a mão na massa" sem estragar nada. Este projecto visa simplificar a forma com que os novatos fazem a sua primeira contribuição. Lembre-se: quanto mais relaxado(a) estiveres, melhor aprenderás. Se quiseres fazer a tua primeira contribuição, siga os passos abaixo. Nós prometemos, será divertido.
|
||||
|
||||
Se não te sentires à vontade com a linha de comandos, [aqui tens tutoriais que usam as ferramentas GUI](#tutoriais-com-outras-ferramentas).
|
||||
|
||||
Se ainda não tens o git na tua máquina, [instala-o aqui]( https://help.github.com/articles/set-up-git/ ).
|
||||
|
||||
## Faz Fork deste repositório
|
||||
|
||||
@@ -8,61 +8,66 @@
|
||||
|
||||
閱讀文章和觀看教學會有所幫助。不過，有什麼方法能比在不會弄亂任何東西的情況下，實際動手做來得更好？本項目旨在指導初學者及簡化初學者參與開源的方式。記住：過程越輕鬆，學習效益越高。如果妳/你想要做出第一次貢獻，只需按照以下簡單步驟操作即可。跟你保證，這會很好玩 :)
|
||||
|
||||
#### *如果你不喜歡使用指令列，[這裡有使用圖形界面工具的教學。]( #使用其他工具的教學)*
|
||||
#### _如果你不喜歡使用指令列，[這裡有使用圖形界面工具的教學。](#使用其他工具的教學)_
|
||||
|
||||
<img align="right" width="300" src="https://firstcontributions.github.io/assets/Readme/fork.png" alt="fork this repository" />
|
||||
|
||||
如果你的電腦上尚未安裝 git，請按照這個[安裝指引（英文）](https://help.github.com/articles/set-up-git/)進行安裝。
|
||||
如果你的電腦上尚未安裝 git，請按照這個[安裝指南（英文）](https://help.github.com/articles/set-up-git/)進行安裝。
|
||||
|
||||
## 分叉（Fork）本代碼庫
|
||||
## 分叉（Fork）本儲存庫
|
||||
|
||||
點選圖示中的按鈕來 Fork 這個 Git 儲存庫。
|
||||
這個操作會將儲存庫分叉到你/妳的 GitHub 帳號下。
|
||||
|
||||
## 複製（Clone）代碼庫
|
||||
## 複製（Clone）儲存庫
|
||||
|
||||
<img align="right" width="300" src="https://firstcontributions.github.io/assets/Readme/clone.png" alt="clone this repository" />
|
||||
|
||||
接下來，將複製後的儲存庫複製到你/妳的電腦上。點選圖示中的綠色按鈕，接著點選複製到剪貼簿按鈕（將儲存庫地址複製下來）
|
||||
接下來，將複製後的儲存庫複製到你/妳的電腦上。點選圖示中的綠色按鈕，接著點選複製到剪貼簿按鈕（將儲存庫網址複製下來）
|
||||
|
||||
隨後打開命令列視窗，鍵入如下 git 命令：
|
||||
隨後打開命令列視窗，輸入如下 git 命令：
|
||||
|
||||
```bash
|
||||
git clone "url you just copied"
|
||||
```
|
||||
"url you just copied"（去掉雙引號）就是複製到妳/你帳戶名下的儲存庫地址。取得這鏈接地址的方法請見上一步。
|
||||
|
||||
"url you just copied"（去掉雙引號）就是複製到妳/你帳戶名下的儲存庫網址。取得這網址的方法請見上一步。
|
||||
|
||||
<img align="right" width="300" src="https://firstcontributions.github.io/assets/Readme/copy-to-clipboard.png" alt="copy URL to clipboard" />
|
||||
|
||||
譬如：
|
||||
|
||||
```bash
|
||||
git clone https://github.com/<this-is-you>/first-contributions.git
|
||||
```
|
||||
|
||||
'this-is-you' 指的就是你/妳自己的 GitHub 用戶名。這一步，會將你/妳的 first-contributions 儲存庫複製到你的電腦上。
|
||||
'this-is-you' 指的就是你/妳的 GitHub 用戶名。這一步會將你/妳的 first-contributions 儲存庫複製到你的電腦上。
|
||||
|
||||
## 新建一個分支
|
||||
## 新建一個分支（Branch）
|
||||
|
||||
下面的命令能在命令行窗口中，把目錄切換到 first-contributions。
|
||||
|
||||
```bash
|
||||
cd first-contributions
|
||||
```
|
||||
|
||||
接下來使用 `git switch` 命令建立一個程式碼分支：
|
||||
|
||||
```bash
|
||||
git switch -c <add-your-name>
|
||||
```
|
||||
|
||||
譬如：
|
||||
|
||||
```bash
|
||||
git switch -c add-david
|
||||
```
|
||||
|
||||
（新分支的名稱不一定需要有 *add*。然而，在這個新分支的名稱加入 *add* 是一件合理的事情，因為這個分支的目的是將妳/你的名字添加到貢獻者列表中。）
|
||||
（新分支的名稱不一定需要有 _add_。然而，在這個新分支的名稱加入 _add_ 是一件合理的事情，因為這個分支的目的是將妳/你的名字添加到貢獻者列表中。）
|
||||
|
||||
## 對程式碼進行修改，然後提交 (Commit) 修改
|
||||
|
||||
使用妳/你喜歡的文字編輯器打開 `Contributors.md` 這個文件，更新文件內容，將自己的名字加上去，然後存檔。在命令窗口執行 `git status`，這會列出被更動的文件。接著 `git add` 這命令則可以添加更動項目到分支裡，就像以下這條命令。
|
||||
使用妳/你喜歡的編輯器打開 `Contributors.md` 這個文件，將自己的名字加在檔案最下面，然後存檔。在命令窗口執行 `git status`，這會列出被更動的文件。接著 `git add` 這命令則可以添加更動項目到分支裡，就像以下這條命令。
|
||||
|
||||
<img align="right" width="450" src="https://firstcontributions.github.io/assets/Readme/git-status.png" alt="git status" />
|
||||
|
||||
@@ -71,23 +76,27 @@ git add Contributors.md
|
||||
```
|
||||
|
||||
現在就可以使用 `git commit` 命令 commit（提交）你/妳的修改了。
|
||||
|
||||
```bash
|
||||
git commit -m "Add <your-name> to Contributors list"
|
||||
```
|
||||
|
||||
將 `<your-name>` 替換為自己的名字
|
||||
|
||||
## 將更動發佈（Push）到 GitHub
|
||||
|
||||
使用 `git push` 命令發佈代碼
|
||||
|
||||
```bash
|
||||
git push origin <add-your-name>
|
||||
```
|
||||
|
||||
將 `<add-your-name>` 替換為之前新建的分支名稱。
|
||||
|
||||
<details>
|
||||
<summary> <strong>如果在 push（發佈）過程中出 error（錯誤），點擊這裡</strong> </summary>
|
||||
<summary> <strong>如果在發佈（push）過程中出錯誤（error），點擊這裡</strong> </summary>
|
||||
|
||||
- ### Authentication Error
|
||||
- ### 身份驗證錯誤（Authentication Error）
|
||||
<pre>remote: Support for password authentication was removed on August 13, 2021. Please use a personal access token instead.
|
||||
remote: Please see https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/ for more information.
|
||||
fatal: Authentication failed for 'https://github.com/<your-username>/first-contributions.git/'</pre>
|
||||
@@ -108,7 +117,7 @@ git push origin <add-your-name>
|
||||
不久之後，如果妳/你更改的文件與原本沒有衝突，我們會把所有的變化合併到這個項目的主分支。
|
||||
變更合併後，妳/你會收到通知 email。
|
||||
|
||||
## 接下來做什麼呢？
|
||||
## 下一步？
|
||||
|
||||
在[這個網站](https://firstcontributions.github.io/#social-share)慶祝妳/你的成就並跟朋友及追隨者分享。
|
||||
|
||||
@@ -121,8 +130,8 @@ git push origin <add-your-name>
|
||||
## 使用其他工具的教學
|
||||
|
||||
| <a href="../gui-tool-tutorials/github-desktop-tutorial.md"><img alt="GitHub Desktop" src="https://desktop.github.com/images/desktop-icon.svg" width="100"></a> | <a href="../gui-tool-tutorials/github-windows-vs2017-tutorial.md"><img alt="Visual Studio 2017" src="https://upload.wikimedia.org/wikipedia/commons/c/cd/Visual_Studio_2017_Logo.svg" width="100"></a> | <a href="../gui-tool-tutorials/gitkraken-tutorial.md"><img alt="GitKraken" src="https://firstcontributions.github.io/assets/gui-tool-tutorials/gitkraken-tutorial/gk-icon.png" width="100"></a> | <a href="../gui-tool-tutorials/github-windows-vs-code-tutorial.md"><img alt="VS Code" src="https://upload.wikimedia.org/wikipedia/commons/1/1c/Visual_Studio_Code_1.35_icon.png" width=100></a> | <a href="../gui-tool-tutorials/sourcetree-macos-tutorial.md"><img alt="Sourcetree App" src="https://wac-cdn.atlassian.com/dam/jcr:81b15cde-be2e-4f4a-8af7-9436f4a1b431/Sourcetree-icon-blue.svg" width=100></a> | <a href="../gui-tool-tutorials/github-windows-intellij-tutorial.md"><img alt="IntelliJ IDEA" src="https://upload.wikimedia.org/wikipedia/commons/thumb/9/9c/IntelliJ_IDEA_Icon.svg/512px-IntelliJ_IDEA_Icon.svg.png" width=100></a> |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| [GitHub Desktop](../gui-tool-tutorials/github-desktop-tutorial.md) | [Visual Studio 2017](../gui-tool-tutorials/github-windows-vs2017-tutorial.md) | [GitKraken](../gui-tool-tutorials/gitkraken-tutorial.md) | [Visual Studio Code](../gui-tool-tutorials/github-windows-vs-code-tutorial.md) | [Atlassian Sourcetree](../gui-tool-tutorials/sourcetree-macos-tutorial.md) | [IntelliJ IDEA](../gui-tool-tutorials/github-windows-intellij-tutorial.md) |
|
||||
| -------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| [GitHub Desktop](../gui-tool-tutorials/github-desktop-tutorial.md) | [Visual Studio 2017](../gui-tool-tutorials/github-windows-vs2017-tutorial.md) | [GitKraken](../gui-tool-tutorials/gitkraken-tutorial.md) | [Visual Studio Code](../gui-tool-tutorials/github-windows-vs-code-tutorial.md) | [Atlassian Sourcetree](../gui-tool-tutorials/sourcetree-macos-tutorial.md) | [IntelliJ IDEA](../gui-tool-tutorials/github-windows-intellij-tutorial.md) |
|
||||
|
||||
<p>項目支持者:</p>
|
||||
<p>
|
||||
|
||||
Reference in New Issue
Block a user