mirror of
https://github.com/LucasVbr/first-contributions.git
synced 2026-05-14 01:31:50 +00:00
Merge branch 'main' into my-first-contribution
This commit is contained in:
Roshan Jossy
@@ -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. **教え、他者を助ける**:
|
||||
あるトピックについてより深く学ぶ最良の方法は、それを教えてみることです。
|
||||
最高の教師は、複雑なことをシンプルな例で説明できる人です。
|
||||
そのため、最高の学習者であり、プログラミングの世界で最高であるためには、まず最高の教師になろうとする必要があります。
|
||||
他者に教えることで、自分自身の理解も深まり、スキルや知識も向上します。
|
||||
誰かから助けを得たとき、それを自分だけに留めず、他の人と共有してください。
|
||||
そうすることで、世界はより良い場所になります。
|
||||
|
||||
@@ -122,3 +122,40 @@ Most of all, listen to what people around you discuss. See if you can recognize
|
||||
16. **Teach and Help others**:
|
||||
The best way to learn more about a topic is to try to teach it.
|
||||
The best teacher is the one who can explain complex stuff with simple examples. So you need to try to be the best teacher to be the best learner and the best in your programming world. Teaching others will make you feel better about yourself and it will help you get better skills and knowledge in your profession. When you get help from someone don't keep it to yourself share it with others. Make the world a better place to live.
|
||||
|
||||
17. **Improve Accessibility**
|
||||
- Audit project documentation/websites for:
|
||||
- Alt text for images.
|
||||
- Screen reader compatibility.
|
||||
- Suggest fixes for:
|
||||
- Color contrast.
|
||||
- Keyboard navigation.
|
||||
- Semantic HTML.
|
||||
|
||||
18. **Organize Community Events**
|
||||
- Help organize:
|
||||
- Virtual meetups or hackathons.
|
||||
- "Ask Me Anything" (AMA) sessions with maintainers.
|
||||
- Moderate forums/Discord/Slack to keep discussions productive.
|
||||
|
||||
19. **Curate Resources**
|
||||
- Create an **"Awesome [Project Name]"** list with:
|
||||
- Tutorials, videos, third-party tools.
|
||||
- Compile a **FAQ section** from common questions in forums/issues.
|
||||
|
||||
20. **Social Media & Outreach**
|
||||
- Manage project’s Twitter/LinkedIn:
|
||||
- Share updates, milestones, or contributor spotlights.
|
||||
- Write **"Getting Started" threads** or tweetorials for new users.
|
||||
|
||||
21. **Localization & Internationalization**
|
||||
- Translate UI strings (via Crowdin/Weblate).
|
||||
- Adapt docs for regional contexts (e.g., date formats, idioms).
|
||||
|
||||
22. **Design & UX Feedback**
|
||||
- Mockup UI improvements (Figma/Canva sketches).
|
||||
- Report confusing workflows (e.g., "Settings menu is hard to find").
|
||||
|
||||
23. **Grant Writing & Fundraising**
|
||||
- Apply for open-source grants (GitHub Sponsors, NLnet).
|
||||
- Draft **case studies** showcasing project impact.
|
||||
|
||||
@@ -0,0 +1,84 @@
|
||||
# গিট কনফিগারেশন
|
||||
|
||||
প্রথমবারের মতো যখন আপনি `commit` করার চেষ্টা করবেন, তখন এই ধরনের বার্তা দেখতে পাবেন:
|
||||
|
||||
```bash
|
||||
$ git commit
|
||||
*** Please tell me who you are.
|
||||
|
||||
Run
|
||||
|
||||
git config --global user.email "you@example.com"
|
||||
git config --global user.name "Your Name"
|
||||
|
||||
to set your account's default identity.
|
||||
Omit --global to set the identity only in this repository.
|
||||
```
|
||||
|
||||
একটি `commit` তৈরি করতে গিটকে জানতে হবে যে এর লেখক কে। সহযোগী কাজের ক্ষেত্রে, প্রকল্পের বিভিন্ন অংশের পরিবর্তন করেছেন কে এবং কবে, তা জানা খুবই গুরুত্বপূর্ণ। তাই গিটে প্রতিটি `commit`-এর সাথে ব্যবহারকারীর নাম এবং ইমেল ঠিকানা সংযুক্ত করা হয়।
|
||||
|
||||
এখানে কিছু উপায় আছে যার মাধ্যমে আপনি আপনার ইমেল এবং নাম `git commit` কমান্ডের সাথে যুক্ত করতে পারেন।
|
||||
|
||||
### গ্লোবাল কনফিগারেশন
|
||||
|
||||
গ্লোবাল কনফিগারেশনে সংরক্ষিত তথ্য সমস্ত গিট রিপোজিটরিতে প্রযোজ্য। এটি হল সবচেয়ে ব্যবহৃত পদ্ধতি।
|
||||
|
||||
গ্লোবাল কনফিগারেশনে কিছু সেট করতে, আপনি `config` কমান্ডটি এভাবে ব্যবহার করতে পারেন:
|
||||
|
||||
```bash
|
||||
$ git config --global <variable name> <value>
|
||||
```
|
||||
|
||||
ব্যবহারকারীর তথ্য সেট করার জন্য, এটি এভাবে হবে:
|
||||
|
||||
```bash
|
||||
$ git config --global user.email "you@example.com"
|
||||
$ git config --global user.name "Your Name"
|
||||
```
|
||||
|
||||
### রিপোজিটরি স্তরের কনফিগারেশন
|
||||
|
||||
এই ধরনের কনফিগারেশন শুধুমাত্র আপনার বর্তমান রিপোজিটরিতে প্রযোজ্য। যদি আপনি কোনও নির্দিষ্ট রিপোজিটরিতে কাজ করতে চান (উদাহরণস্বরূপ, কোম্পানির প্রকল্পে), তবে এই পদ্ধতি ব্যবহার করতে পারেন।
|
||||
|
||||
রিপোজিটরি স্তরের কনফিগারেশন সেট করতে, `--global` বাদ দিয়ে `config` কমান্ডটি ব্যবহার করুন:
|
||||
|
||||
```bash
|
||||
$ git config <variable name> <value>
|
||||
```
|
||||
|
||||
ব্যবহারকারীর তথ্য সেট করার জন্য, এটি এভাবে হবে:
|
||||
|
||||
```bash
|
||||
$ git config user.email "you@alternate.com"
|
||||
$ git config user.name "Your Name"
|
||||
```
|
||||
|
||||
### কমান্ড লাইনে কনফিগারেশন
|
||||
|
||||
এই ধরনের কনফিগারেশন শুধুমাত্র একটি নির্দিষ্ট কমান্ডের জন্য প্রযোজ্য। সব গিট কমান্ডে `-c` ব্যবহার করে আপনি কনফিগারেশন পরামিতি সেট করতে পারেন।
|
||||
|
||||
একটি কমান্ডের জন্য কনফিগারেশন পরিবর্তন করতে, গিট কমান্ডটি এভাবে ব্যবহার করুন:
|
||||
|
||||
```bash
|
||||
$ git -c <variable-1>=<value> -c <variable-2>=<value> <command>
|
||||
```
|
||||
|
||||
আমাদের ক্ষেত্রে, `commit` কমান্ডটি এভাবে হবে:
|
||||
|
||||
```bash
|
||||
git -c user.name='Your Name' -c user.email='you@example.com' commit -m "Your commit message"
|
||||
```
|
||||
|
||||
### অগ্রাধিকারের ক্রম
|
||||
|
||||
এই তিনটি কনফিগারেশন পদ্ধতির মধ্যে অগ্রাধিকারের ক্রম হল: `কমান্ড লাইন > রিপোজিটরি > গ্লোবাল`। এর মানে হল যদি কোনও পরিবর্তনশীল গ্লোবাল এবং কমান্ড লাইনে উভয় ক্ষেত্রেই সেট করা থাকে, তবে কমান্ড লাইনের মান ব্যবহার করা হবে।
|
||||
|
||||
## শুধু ব্যবহারকারীর তথ্য নয়
|
||||
|
||||
এখন পর্যন্ত আমরা গিট কনফিগারেশন নিয়ে আলোচনা করেছি শুধু ব্যবহারকারীর তথ্যের ক্ষেত্রে। কিন্তু গিট আরও অনেক পরামিতি কনফিগার করতে দেয়। এখানে কিছু উল্লেখযোগ্য উদাহরণ:
|
||||
|
||||
1. `core.editor` - কমিট মেসেজ এডিট করার জন্য ব্যবহৃত টেক্সট এডিটর,
|
||||
2. `commit.template` - কমিটের জন্য প্রাথমিক টেমপ্লেট ফাইল,
|
||||
3. `color.ui` - টার্মিনালে গিট মেসেজে রঙিন ফন্ট ব্যবহার করা যাবে কিনা তা নির্ধারণ করে।
|
||||
|
||||
আরও বিস্তারিত জানতে [git-scm.com](https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration) দেখুন।
|
||||
@@ -0,0 +1,58 @@
|
||||
# ওপেন সোর্স অবদানের জন্য Git অনুমতি ত্রুটি সমাধান
|
||||
|
||||
## সমস্যা
|
||||
|
||||
আমি "first-contributions" রিপোজিটরিতে অবদান রাখার চেষ্টা করার সময় একটি অনুমতি ত্রুটি পেয়েছিলাম। আমি নতুন ব্রাঞ্চ তৈরি করে এবং পরিবর্তনগুলি পুশ করার চেষ্টা করার পর:
|
||||
|
||||
```bash
|
||||
$ git checkout -b fahimar_oss_YYYY
|
||||
Switched to a new branch 'fahimar_oss_YYYY'
|
||||
|
||||
$ git push origin fahimar_oss_YYYY
|
||||
remote: Permission to firstcontributions/first-contributions.git denied to fahimar.
|
||||
fatal: unable to access 'https://github.com/firstcontributions/first-contributions.git/': The requested URL returned error: 403
|
||||
```
|
||||
|
||||
সমস্যাটি ছিল যে, আমি মূল রিপোজিটরিটি সরাসরি ক্লোন করেছিলাম এবং সেখানে পুশ করার চেষ্টা করেছিলাম। একজন বাইরের অবদানকারী হিসেবে, আমার মূল রিপোজিটরিতে লেখার অনুমতি নেই।
|
||||
|
||||
## সমাধান
|
||||
|
||||
আমি নিম্নলিখিত উপায়ে এই সমস্যাটি সমাধান করেছি:
|
||||
|
||||
1. আমার রিমোট URL পরিবর্তন করে এটিকে আমার ব্যক্তিগত ফর্কে পয়েন্ট করানো:
|
||||
|
||||
```bash
|
||||
$ git remote set-url origin https://github.com/yourname/first-contributions.git
|
||||
```
|
||||
|
||||
2. রিমোট ঠিকভাবে আপডেট হয়েছে কিনা তা যাচাই করা:
|
||||
|
||||
```bash
|
||||
$ git remote -v
|
||||
origin https://github.com/yourname/first-contributions.git (fetch)
|
||||
origin https://github.com/yourname/first-contributions.git (push)
|
||||
```
|
||||
|
||||
3. সফলভাবে আমার ফর্কে পুশ করা:
|
||||
|
||||
```bash
|
||||
$ git push origin fahimar_oss_YYYY
|
||||
```
|
||||
|
||||
4. GitHub আমাকে একটি লিঙ্ক দিয়েছিল যাতে আমি আমার ব্রাঞ্চ থেকে পুল রিকোয়েস্ট তৈরি করতে পারি:
|
||||
```
|
||||
remote: Create a pull request for 'fahimar_oss_YYYY' on GitHub by visiting:
|
||||
remote: https://github.com/fahimar/first-contributions/pull/new/fahimar_oss_YYYY
|
||||
```
|
||||
|
||||
## প্রধান শিক্ষা
|
||||
|
||||
ওপেন সোর্স অবদানের জন্য সঠিক কাজের ধারাবাহিকতা হল:
|
||||
|
||||
1. মূল রিপোজিটরিটি আপনার GitHub অ্যাকাউন্টে ফর্ক করুন
|
||||
2. আপনার ফর্কটি স্থানীয়ভাবে ক্লোন করুন
|
||||
3. একটি নতুন ব্রাঞ্চে পরিবর্তন করুন
|
||||
4. আপনার ফর্কে পুশ করুন
|
||||
5. আপনার ফর্ক থেকে মূল রিপোজিটরিতে পুল রিকোয়েস্ট তৈরি করুন
|
||||
|
||||
যদি আপনি আগে মূল রিপোজিটরি ক্লোন করে থাকেন এবং আপনার ফর্ক না করে থাকেন, তবে উপরে দেখানো মতো রিমোট URL আপডেট করে এটি ঠিক করতে পারেন।
|
||||
+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,164 @@
|
||||
# حاجات ممكن اللي مش مبرمج يعملها
|
||||
## اسمع الأول
|
||||
|
||||
كل حاجة في الـ Open Source بتعتمد على الناس اللي شغالة فيها.
|
||||
إنت عايز تنضم لفريق، وده معناه إنك تفهم المجتمع شغال إزاي.
|
||||
لو دخلت على مشروع وقلت "هاي، أنا شايف إن المشروع المفروض يعمل كذا" غالبًا ده مش هيكون مقبول.
|
||||
ممكن مشاريع معينة تكون بتحب الأسلوب ده، لكن لو المشروع ليه فترة شغال، نسبة إن الناس تتقبل الكلام ده قليلة.
|
||||
**أحسن حاجة تعملها في الأول إنك تسمع وتشوف الناس شغالة إزاي.**
|
||||
|
||||
1. **اشترك في Mailing List**: في مشاريع كتير، الـ mailing list هي وسيلة التواصل الرئيسية بين الناس اللي بتطور المشروع.
|
||||
في المشاريع الكبيرة، هتلاقي كذا mailing list.
|
||||
مثلاً، مشروع PostgreSQL عنده أكتر من 12 mailing list للمستخدمين و6 للمطورين.
|
||||
ابدأ بمتابعة الـ list الأساسية للمستخدمين وواحدة من بتوع المطورين علشان تفهم اللي بيحصل.
|
||||
|
||||
2. **تابع Blog**: المطورين الكبار غالبًا بيكتبوا تدوينات بيشرحوا فيها اللي هيحصل في النسخ الجاية،
|
||||
وبيتكلموا عن اللي اتعمل علشان نوصل للمرحلة دي.
|
||||
في مواقع اسمها Planet بتجمع التدوينات والأخبار من كذا مصدر عن المشروع.
|
||||
لو فيه planet زي planet.gnome.org أو planet.mysql.com، يبقى ده مكان كويس تبدأ منه.
|
||||
اكتب في جوجل "planet <اسم المشروع>".
|
||||
|
||||
3. **ادخل على قناة IRC**: معظم مشاريع الـ Open Source عندها قنوات IRC الناس بتدخل تتكلم فيها عن المشاكل والتطوير.
|
||||
ادخل على موقع المشروع وشوف اسم القناة على أي شبكة IRC.
|
||||
|
||||
**اشتغل على التذاكر**
|
||||
الكود هو الأساس في أي مشروع مفتوح المصدر، بس ده مش معناه إن الكود هو الطريقة الوحيدة اللي ممكن تساهم بيها.
|
||||
فيه حاجات تانية كتير الناس بتكسل تعملها، زي صيانة النظام أو متابعة المشاكل.
|
||||
ابدأ من هنا وهتلاقي نفسك بقيت جزء من الفريق.
|
||||
|
||||
معظم المشاريع عندها نظام تذاكر على الموقع الرسمي.
|
||||
ده بيكون وسيلة تواصل بين الناس اللي بتستخدم البرنامج والمطورين.
|
||||
تنضيف التذاكر دي وتحديثها بيساعد الفريق جدًا.
|
||||
|
||||
ممكن تحتاج صلاحيات علشان تعدل على التذاكر، بس صدقني، أول ما تقول إنك عايز تساعد، هيدوك الصلاحيات دي على طول.
|
||||
|
||||
4. **حلل مشكلة (Bug)**: ساعات الناس بتبلّغ عن مشاكل بشكل مش واضح.
|
||||
لو حد قال "البرنامج بيهنّج لما بعمل كذا"، خد وقتك وحاول تعرف المشكلة دي بتحصل إزاي.
|
||||
هل بتتكرر؟ تقدر تكتب خطوات تثبت بيها إنها بتحصل؟ بتحصل على متصفح معين؟ ولا في نظام تشغيل معين؟
|
||||
|
||||
حتى لو معرفتش تحلها، إنك توضّح المشكلة أكتر بيسهّل على حد تاني ييجي يحلها.
|
||||
وكل اللي تكتشفه، اكتبه في التذكرة علشان غيرك يستفيد.
|
||||
|
||||
5. **اقفل التذاكر القديمة**: كتير من المشاكل بتكون اتحلت، بس التذاكر لسه مفتوحة.
|
||||
البحث في التذاكر القديمة وتنضيفها حاجة مهمة جدًا.
|
||||
|
||||
ابدأ بدور على تذاكر بقالها أكتر من سنة وشوف هل المشكلة لسه موجودة ولا اتصلحت.
|
||||
راجع سجل التغييرات في الإصدارات وشوف لو فيه ذكر للمشكلة.
|
||||
لو اتحلت، اكتب رقم النسخة في التذكرة واقفلها.
|
||||
|
||||
جرّب تعيد المشكلة في آخر نسخة من البرنامج.
|
||||
لو مشتغلتش، اكتب ده في التذكرة واقفلها.
|
||||
لو لسه موجودة، اكتبه برضو وسيب التذكرة مفتوحة.
|
||||
|
||||
## الشغل على الكود
|
||||
الناس اللي عندها خبرة مختلفة في البرمجة تقدر تساعد في الكود.
|
||||
مش لازم تكون مبرمج جامد علشان تساهم.
|
||||
|
||||
لو ناوي تعدل على الكود، اعرف الأول المشروع بيشتغل إزاي في موضوع استلام التعديلات.
|
||||
كل مشروع ليه طريقة معينة، فاسأل الأول.
|
||||
|
||||
مثلاً، PostgreSQL بيستقبل التعديلات على شكل Patch في mailing list، والمطورين بيراجعوها كويس جدًا.
|
||||
لكن في مشروع زي Parrot، ممكن تاخد صلاحيات التعديل بسهولة.
|
||||
لو المشروع على GitHub، غالبًا بيستخدموا Pull Requests.
|
||||
كل مشروع وليه طريقته.
|
||||
|
||||
لما تعدل حاجة، خليك محترم مع باقي الفريق وحافظ على تنسيق الكود زي ما هو.
|
||||
ما تحاولش تفرض أسلوبك.
|
||||
الكود اللي بتكتبه لازم يشبه اللي موجود، حتى لو مش عاجبك.
|
||||
|
||||
6. **اختبر نسخة Beta أو Release Candidate**:
|
||||
المشاريع اللي بتشتغل على كذا نظام تشغيل ساعات بيكون فيها مشاكل توافق.
|
||||
قبل الإصدارات، المطورين بينزلوا نسخ تجريبية علشان الناس تجربها.
|
||||
لو شغّلت البرنامج على نظام تشغيل مختلف واشتغل، ده بيساعدهم يعرفوا إن النسخة كويسة.
|
||||
|
||||
مش لازم تعمل حاجة غير إنك تبني البرنامج وتفتحه وتجربه.
|
||||
لو شغال، بلغهم.
|
||||
ده بيفرق كتير جدًا مع المطورين.
|
||||
|
||||
7. **صلّح Bug**: ده غالبًا أول حاجة الناس بتعملها لما تبدأ تشتغل في الكود.
|
||||
دور على Bug شكله بسيط، وجرب تصلحه.
|
||||
اكتب ملاحظاتك جوه الكود، ولو في Test يوضح إن المشكلة اتحلت، ضيفه.
|
||||
لو معرفتش تصلحها، اكتب اللي وصلتله في التذكرة.
|
||||
|
||||
8. **اكتب Test**:
|
||||
معظم المشاريع عندها Tests، بس دايمًا فيه مكان لإضافة تانية.
|
||||
استخدم أدوات بتقيس مدى التغطية، زي `gcov` أو `Devel::Cover`.
|
||||
وشوف أجزاء الكود اللي مش متغطية، وضيف لها Test.
|
||||
|
||||
9. **اسكت تحذير من الكومبايلر**:
|
||||
لما تبني برامج C، ممكن يطلعلك تحذيرات.
|
||||
مش دايمًا معناها إن فيه مشكلة، بس بتشوّش.
|
||||
لو شفت تحذير، شوف هل فعلاً فيه مشكلة؟
|
||||
لو لأ، عدل الكود علشان تسكت التحذير.
|
||||
|
||||
10. **ضيف تعليق**:
|
||||
لو لقيت جزء في الكود مش مفهوم، اكتبه تعليق.
|
||||
أكيد في ناس غيرك هتتلخبط برضو.
|
||||
ابعت تعديل فيه التعليقات دي.
|
||||
|
||||
## الشغل على التوثيق
|
||||
المستندات دايمًا بتتاخد بشكل بسيط.
|
||||
وساعات بتكون مكتوبة كأن اللي بيقراها أصلاً فاهم المشروع.
|
||||
لو حسيت إن التوثيق مش واضح، قول.
|
||||
اللي عنيهم جديدة بيشوفوا حاجات الناس اللي شغالة عليها مش شايفاها.
|
||||
|
||||
11. **اعمل مثال**:
|
||||
مفيش مشروع عنده أمثلة كتير كفاية.
|
||||
لو فيه API، أو مكتبة، أو برنامج GUI زي Gimp، أو حتى أداة سطر أوامر – اعمل مثال عملي بيشرح ازاي تستخدمه.
|
||||
|
||||
ممكن المثال يكون حاجة بسيطة من كود انت كتبته، أو حتى فيديو Screen Recording وانت بتستخدمه.
|
||||
الناس بتحب تشوف التطبيق العملي أكتر من الكلام.
|
||||
|
||||
## اشتغل مع المجتمع
|
||||
الـ Open Source مش بس كود. المجتمع هو اللي بيخلي المشاريع دي تعيش وتكبر.
|
||||
فيه طرق كتير تقدر تساعد بيها في تقوية المجتمع حوالي المشروع.
|
||||
|
||||
12. **جاوب على سؤال**:
|
||||
أحسن طريقة تساعد بيها المشروع والمجتمع هي إنك تساعد غيرك.
|
||||
لما حد جديد يسأل سؤال، وحضرتك تجاوبه بدل ما تقول له "روح اقرأ الـ Manual"، كده إنت مش بس ساعدته،
|
||||
إنت كمان شجّعته يكمل، ويمكن كمان يبقى عضو نشيط في المشروع بعد كده.
|
||||
|
||||
كلنا بدأنا من الصفر، والمشاريع محتاجة دايمًا ناس جديدة تدخل علشان تفضل عايشة.
|
||||
|
||||
13. **اكتب تدوينة (Blog Post)**:
|
||||
لو عندك مدونة، احكي فيها عن تجربتك مع المشروع اللي بتستخدمه.
|
||||
قول واجهت إيه مشاكل، وازاي حليتها.
|
||||
كده بتساعد المشروع بطريقتين:
|
||||
- إنك بتخلي الناس تفكر في المشروع وتسمع عنه.
|
||||
- وإنك بتسيب أثر للي بعدك لو حد واجه نفس المشكلة وعمل بحث على جوجل.
|
||||
|
||||
(والتدوينة دي كمان ممكن تبقى وسيلة كويسة توري بيها خبرتك الحقيقة في الشغل لما تيجي تدور على شغل.)
|
||||
|
||||
14. **طوّر موقع المشروع**:
|
||||
لو عندك خبرة في تصميم المواقع، وساعدت في تحسين الموقع أو شكله العام، ده وقتك مش بيضيع.
|
||||
يمكن المشروع محتاج لوجو، أو ستايل أحسن، أو تنظيم أحسن للمحتوى.
|
||||
الحاجات دي ساعات بتكون ناقصة عند المبرمجين، وساعتها أي حد عنده ذوق أو خبرة في التصميم بيفرق جامد.
|
||||
أنا عن نفسي بتمنى ألاقي حد يساعدني في التصميم في مشاريعي!
|
||||
|
||||
15. **اكتب توثيق تقني (Documentation)**:
|
||||
لو تقدر تشرح ازاي برنامج أو أداة شغالة، يبقى تقدر تكتب توثيق تقني عنها.
|
||||
مشاريع Open Source كتير بتبقى محتاجة توثيق جديد، أو تطوير اللي موجود، أو تبسيطه للناس.
|
||||
|
||||
كل ما كانت كتابتك أبسط وأوضح، كل ما كانت أحسن.
|
||||
وأجمل حاجة؟ مش لازم تكون مبرمج علشان تكتب Documentation.
|
||||
|
||||
والأهم من كل ده، اسمع الناس بتتكلم عن إيه.
|
||||
حاول تلاحظ المشاكل اللي محتاجة حل.
|
||||
مثلاً، في مرة على Mailing List لمشروع Parrot، قرروا ينقلوا من Trac لـ GitHub في نظام التذاكر.
|
||||
ناس كتير كانوا ضد القرار علشان مفيش طريقة ينقلوا التذاكر القديمة.
|
||||
دخلت وقلت "طب ما أكتب أنا برنامج يحوّل التذاكر؟" والناس فرحت جدًا.
|
||||
فعلاً كتبت برنامج نقل أكتر من 450 تذكرة، واحتفظنا بتاريخهم.
|
||||
نجاح جميل، وساعدت الفريق، والمطورين ركزوا في شغلهم بدل وجع الدماغ.
|
||||
|
||||
16. **علّم وساعد غيرك**:
|
||||
أحسن طريقة تتعلم بيها أكتر، إنك تشرح اللي فهمته لحد تاني.
|
||||
المدرّس الشاطر هو اللي يقدر يشرح حاجة معقدة بطريقة بسيطة.
|
||||
|
||||
لو علمت حد، أو ساعدته، مش بس هتحس إنك عملت حاجة كويسة،
|
||||
ده كمان هيثبت المعلومة في دماغك، ويقوّي مهاراتك.
|
||||
ولما حد يساعدك، ما تحتفظش بالمعلومة لنفسك.
|
||||
شارك اللي عرفته، وخلّي الدنيا مكان أحسن.
|
||||
|
||||
والسلام عليكم ورحمة الله وبركاته.
|
||||
|
||||
|
||||
@@ -0,0 +1,124 @@
|
||||
プログラマーでなくてもできること
|
||||
聞くことから始めよう
|
||||
|
||||
オープンソースはすべて、他の人々を巻き込むことです。
|
||||
あなたはチームに加わろうとしており、それにはコミュニティとその仕組みを理解する必要があります。
|
||||
プロジェクトに参加して「こんにちは、このプロジェクトにはこうしたほうがいいと思います」と言うのは、通常あまり歓迎されません。
|
||||
一部のプロジェクトではそのようなアプローチを歓迎するかもしれませんが、長く続いているプロジェクトでは、その考え方はあまり受け入れられません。
|
||||
プロジェクトのニーズを理解するには、まず聞くことが最も重要です。
|
||||
|
||||
1. メーリングリストに参加する
|
||||
|
||||
多くのプロジェクトでは、メーリングリストが開発に関する主なコミュニケーション手段となっています。
|
||||
大規模なプロジェクトには、複数のメーリングリストがあります。
|
||||
たとえば、PostgreSQLプロジェクトには、少なくとも12のユーザー向けリストと6つの開発者リストがあります。
|
||||
主要なユーザー向けと開発者向けリストをフォローし、まずは「聞くこと」から始めましょう。
|
||||
2. ブログをフォローする
|
||||
|
||||
主要な開発者が運営しているブログでは、今後のリリースや現在進行中の作業についての情報が得られます。
|
||||
Planetサイトは、関連する複数のニュースソースやブログ投稿を一か所でまとめて表示します。
|
||||
たとえば planet.gnome.org や planet.mysql.com のようなサイトがそうです。
|
||||
Googleで「Planet <プロジェクト名>」と検索してみましょう。
|
||||
|
||||
3. IRCチャンネルに参加する
|
||||
|
||||
多くのオープンソースプロジェクトにはIRC（インターネットリレーチャット）チャンネルがあり、開発者やユーザーが問題や開発について話し合っています。
|
||||
プロジェクトのWebサイトで、チャンネル名や使用しているIRCネットワークを確認しましょう。
|
||||
チケットを使った作業
|
||||
|
||||
コードはオープンソースプロジェクトの中心ですが、貢献方法はそれだけではありません。
|
||||
コードの周囲のシステムの保守は、新機能の追加やバグ修正の際に見過ごされがちです。
|
||||
こうした分野に関わることは、プロジェクトへの入り口となります。
|
||||
多くのプロジェクトには、公開されているトラブルチケットシステムがあり、公式Webサイトのトップページやドキュメントからリンクされています。
|
||||
これはユーザーと開発者間の主なコミュニケーション手段です。これを最新に保つことは、大きな貢献となります。
|
||||
一部の操作には特別な権限が必要ですが、多くのプロジェクトリーダーは喜んで協力してくれます。
|
||||
|
||||
4. バグの診断
|
||||
|
||||
バグはしばしば不正確に報告されます。
|
||||
バグを診断して説明することは、開発者が問題の原因を特定する助けになります。
|
||||
たとえば「Xをしたときにソフトが動かない」と報告された場合、再現できるか確認しましょう。
|
||||
特定のブラウザでのみ発生するのか、特定のディストリビューションでのみ発生するのかを絞り込むことが重要です。
|
||||
原因が分からなくても、可能な限り情報を絞り込むことで他の人が修正しやすくなります。
|
||||
見つけたことはすべてチケットに記録しましょう。
|
||||
|
||||
5. 修正されたバグを閉じる
|
||||
|
||||
バグがコードで修正されても、チケットが更新されていないことがあります。
|
||||
このような「ごみ」を掃除するのは時間がかかりますが、プロジェクト全体にとっては非常に重要です。
|
||||
1年以上前のチケットを検索し、バグがまだ存在するか確認してください。
|
||||
リリースの変更ログを確認し、修正されたことが明らかであればチケットを閉じてください。
|
||||
バグが再現できなければそれを記録し、閉じます。再現できれば、続けてオープンにしておきます。
|
||||
コードを使った作業
|
||||
|
||||
経験レベルに関係なく、誰でもコードで貢献できます。
|
||||
貢献するために天才である必要はありません。
|
||||
コードの修正を行う場合は、そのプロジェクトがどのようにコードを受け入れているか確認してください。
|
||||
各プロジェクトには独自のワークフローがあります。
|
||||
たとえば PostgreSQL ではパッチをメーリングリストに送る厳格なルールがありますが、Parrot のようなプロジェクトではもっと簡単です。
|
||||
GitHubを使用している場合は、Pull Requestを通じて貢献できます。
|
||||
修正時は、既存のコードスタイルに従い、責任あるメンバーとして行動してください。
|
||||
|
||||
6. ベータ版やリリース候補版をテストする
|
||||
|
||||
さまざまな環境で動作するソフトウェアには、移植性に関する問題が多く存在します。
|
||||
リリース前にベータ版やRC版が公開された際は、異なる環境でのテストが期待されます。
|
||||
あなたもその一員となり、自分の環境でビルド・実行・テストをして、動作報告を送りましょう。
|
||||
|
||||
7. バグを修正する
|
||||
|
||||
これはコードに貢献したい人のための一般的な方法です。
|
||||
チケットシステムから興味のあるバグを探し、修正に挑戦してください。
|
||||
テストが必要であれば、それも追加しましょう。
|
||||
修正できなかった場合でも、調査内容を記録することが次の人の助けになります。
|
||||
|
||||
8. テストを書く
|
||||
|
||||
ほとんどのプロジェクトにはテストスイートがありますが、十分にカバーされていないこともあります。
|
||||
テストカバレッジツールを使用して未カバー部分を探し、そこに対するテストを追加しましょう。
|
||||
|
||||
9. コンパイラ警告を修正する
|
||||
|
||||
多くのC系プロジェクトでは、ビルド時に警告が出ます。
|
||||
それらの多くは深刻な問題ではありませんが、見た目が悪く、重要な警告を埋もれさせてしまうことがあります。
|
||||
警告を解消するためのコード変更は、プロジェクトにとって役立ちます。
|
||||
|
||||
10. コメントを追加する
|
||||
|
||||
コードを読む中で混乱する箇所があれば、他の人も同じように困る可能性があります。
|
||||
そこにコメントを追加し、パッチとして提出しましょう。
|
||||
ドキュメントで貢献する
|
||||
|
||||
ドキュメントはしばしば軽視されがちであり、経験者の視点で書かれていることが多いため、初心者にはわかりにくいことがあります。
|
||||
新しい視点から欠点を見つけ、改善することができます。
|
||||
|
||||
11. 使用例を作成する
|
||||
|
||||
どんなプロジェクトでも、How-toの使用例は歓迎されます。
|
||||
API、GUIアプリ、CLIツールなど、実用的な例を作りましょう。
|
||||
セットアップ手順のスクリーンショットを追加するのも良いアイデアです。
|
||||
コミュニティとの関わり方
|
||||
|
||||
オープンソースはコードだけではありません。コミュニティこそがそれを支える柱です。
|
||||
|
||||
12. 質問に答える
|
||||
|
||||
他人を助けることは、コミュニティを強くする最高の方法です。
|
||||
特に初心者の質問に親切に答えることで、活発な参加者が増え、プロジェクトの将来が明るくなります。
|
||||
|
||||
13. ブログ投稿を書く
|
||||
|
||||
使っているソフトウェアに関して、経験や問題・解決策を書いてください。
|
||||
他のユーザーが同様の問題に直面したとき、あなたのブログが役立つかもしれません。
|
||||
また、将来そのソフトを使って職探しをする際の実績としても使えます。
|
||||
|
||||
14. Webサイトを改善する
|
||||
|
||||
もしWebデザインのスキルがあれば、プロジェクトのWebサイトを改善することで貢献できます。
|
||||
新しいロゴやバナー、レイアウトの改善など、あなたのスキルが生かされる場面は多くあります。
|
||||
|
||||
最も重要なのは、周囲の人々がどんな話をしているのか、耳を傾けることです。
|
||||
必要なものに気づき、積極的に提案・行動することで、大きなインパクトを残すことができます。
|
||||
|
||||
たとえば、Parrotの開発者がTracからGitHubへチケットを移行するか議論していた際、
|
||||
「コンバーターを書きましょうか？」と申し出たことで、450以上のチケットを失わずに済み、大きな成功となりました。
|
||||
+64
@@ -0,0 +1,64 @@
|
||||
|
||||
# ಓಪನ್ ಸೋರ್ಸ್ ಪ್ರಾಜೆಕ್ಟ್ಗಳಿಗೆ ಹೇಗೆ ಕೊಡುಗೆ ನೀಡುವುದು: ಆರಂಭಿಕರಿಗಾಗಿ ಸಂಪೂರ್ಣ ಮಾರ್ಗದರ್ಶಿ
|
||||
|
||||
**ಸಂಕ್ಷಿಪ್ತವಾಗಿ:** ನೀವು ನಿಮ್ಮ ಮೊದಲ Pull Request ಅನ್ನು ಒಂದು ಓಪನ್ಸೋರ್ಸ್ ಪ್ರಾಜೆಕ್ಟ್ಗೆ ಸಲ್ಲಿಸಲು ಕಾತರರಾಗಿದ್ದರೆ, ಈ ಸೂಚನೆಗಳನ್ನು ಅನುಸರಿಸಿ: [Readme](https://github.com/firstcontributions/first-contributions)
|
||||
|
||||
ಓಪನ್ಸೋರ್ಸ್ ಪ್ರಾಜೆಕ್ಟ್ಗಳಿಗೆ ಕೊಡುಗೆ ನೀಡುವುದು ಒಬ್ಬ ಪ್ರೋಗ್ರಾಮರ್ ಆಗಿ ಬೆಳೆಯಲು, ನಿಮ್ಮ ಪೋರ್ಟ್ಫೋಲಿಯೋವನ್ನು ನಿರ್ಮಿಸಲು ಮತ್ತು ಸಮುದಾಯಕ್ಕೆ ಹಿಂದಿರುಗಿಸಲು ಅತ್ಯುತ್ತಮ ಮಾರ್ಗಗಳಲ್ಲಿ ಒಂದು. ನೀವು ಅನುಭವಸಂಪನ್ನ ಪ್ರೋಗ್ರಾಮರ್ ಆಗಿರಲಿ ಅಥವಾ ಪ್ರಾರಂಭದಲ್ಲೇ ಇರಲಿ, ಓಪನ್ಸೋರ್ಸ್ ಪ್ರಾಜೆಕ್ಟ್ಗಳು ಕಲಿಯಲು, ಸಹಕರಿಸಲು ಮತ್ತು ಸಕಾರಾತ್ಮಕ ಪರಿಣಾಮವನ್ನುಂಟುಮಾಡಲು ಹಲವಾರು ಅವಕಾಶಗಳನ್ನು ಒದಗಿಸುತ್ತವೆ. ಈ ಮಾರ್ಗದರ್ಶಿಯಲ್ಲಿ, ಸರಿಯಾದ ಪ್ರಾಜೆಕ್ಟ್ನ್ನು ಹುಡುಕುವುದರಿಂದ ಹಿಡಿದು ನಿಮ್ಮ ಮೊದಲ ಕೊಡುಗೆಯನ್ನು ನೀಡುವವರೆಗಿನ ಎಲ್ಲಾ ಹಂತಗಳನ್ನು ನೋಡೋಣ.
|
||||
|
||||
## ಏಕೆ ಓಪನ್ಸೋರ್ಸ್ ಪ್ರಾಜೆಕ್ಟ್ಗಳಿಗೆ ಕೊಡುಗೆ ನೀಡಬೇಕು?
|
||||
|
||||
"ಹೇಗೆ" ಎಂಬುದರ ಮೊದಲು, "ಏಕೆ" ಎಂಬುದನ್ನು ತಿಳಿಯೋಣ:
|
||||
|
||||
* **ಕೌಶಲ್ಯ ಅಭಿವೃದ್ಧಿ:** ನೈಜ ಪ್ರಾಜೆಕ್ಟ್ಗಳ ಕೋಡ್ಗಳನ್ನು ನೋಡಿ ಕಲಿಯುವ ಮೂಲಕ ನಿಮ್ಮ ಪ್ರೋಗ್ರಾಮಿಂಗ್, ಡಿಬಗ್ಗಿಂಗ್ ಮತ್ತು ಸಹಕಾರದ ಕೌಶಲ್ಯಗಳು ಬೆಳೆಯುತ್ತವೆ.
|
||||
* **ಪೋರ್ಟ್ಫೋಲಿಯೋ ನಿರ್ಮಾಣ:** ಪ್ರಸಿದ್ಧ ಪ್ರಾಜೆಕ್ಟ್ಗಳಲ್ಲಿ ಕೊಡುಗೆ ನೀಡುವುದು ನಿಮ್ಮ CV ಮತ್ತು GitHub ಪ್ರೊಫೈಲ್ ಅನ್ನು ಬಲಪಡಿಸುತ್ತದೆ.
|
||||
* **ನೆಟ್ವರ್ಕಿಂಗ್:** ಜಗತ್ತಿನಾದ್ಯಂತದ ಡೆವಲಪರ್ಗಳ ಜೊತೆ ಸಂಪರ್ಕ ಬೆಳೆಸಿ, ತಜ್ಞರಿಂದ ಕಲಿಯಿರಿ ಮತ್ತು ಸಮುದಾಯದ ಭಾಗವಾಗಿರಿ.
|
||||
* **ಹಿಂದಿರುಗಿಸುವುದು:** ನಾವು ಪ್ರತಿದಿನ ಬಳಸುವ ಅನೇಕ ಸಾಫ್ಟ್ವೇರ್ಗಳ ಆಧಾರ ಓಪನ್ಸೋರ್ಸ್ ಆಗಿದೆ. ಕೊಡುಗೆ ನೀಡುವುದು ಧನ್ಯವಾದ ಹೇಳುವ ಮಾರ್ಗ.
|
||||
* **ವೃತ್ತಿ ಅವಕಾಶಗಳು:** ಅನೇಕ ಕಂಪನಿಗಳು ಓಪನ್ಸೋರ್ಸ್ ಅನುಭವ ಹೊಂದಿರುವ ಡೆವಲಪರ್ಗಳನ್ನು ಹುಡುಕುತ್ತವೆ ಏಕೆಂದರೆ ಇದು ಪ್ರೊಆಕ್ಟಿವಿಟಿ ಮತ್ತು ತಂಡದ ಕೆಲಸವನ್ನು ತೋರಿಸುತ್ತದೆ.
|
||||
|
||||
## ಹೇಗೆ ಪ್ರಾರಂಭಿಸಬೇಕು?
|
||||
|
||||
### 1. ಸರಿಯಾದ ಪ್ರಾಜೆಕ್ಟ್ ಆಯ್ಕೆಮಾಡಿ
|
||||
|
||||
ನಿಮ್ಮ ಆಸಕ್ತಿಗಳು ಮತ್ತು ಕೌಶಲ್ಯಗಳಿಗೆ ಹೊಂದಿಕೊಳ್ಳುವ ಪ್ರಾಜೆಕ್ಟ್ಗಳನ್ನು ಆರಿಸಿ:
|
||||
|
||||
* **GitHub ಅನ್ವೇಷಿಸಿ:** `good-first-issue`, `help-wanted` ಮುಂತಾದ ಲೇಬಲ್ಗಳಿರುವ ಟಾಸ್ಕ್ಗಳನ್ನು ಹುಡುಕಿ.
|
||||
* **ಪ್ರೋಗ್ರಾಂಗಳಲ್ಲಿ ಭಾಗವಹಿಸಿ:** Google Summer of Code, Hacktoberfest ಮುಂತಾದವು ಉತ್ತಮ ಅವಕಾಶಗಳು.
|
||||
* **ನೀವು ಬಳಸುವ ಉಪಕರಣಗಳು:** ನೀವು ಬಳಸುವ ಲೈಬ್ರರಿ ಅಥವಾ ಫ್ರೇಮ್ವರ್ಕ್ಗಳಲ್ಲಿ ಕೊಡುಗೆ ನೀಡಿ.
|
||||
|
||||
### 2. ಪ್ರಾಜೆಕ್ಟ್ನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಿ
|
||||
|
||||
* **ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ಓದಿ:** README ಮತ್ತು ಕೊಡುಗೆ ಮಾರ್ಗಸೂಚಿಗಳನ್ನು ಗಮನಿಸಿ.
|
||||
* **ಕೋಡ್ನ್ನು ಅಧ್ಯಯನ ಮಾಡಿ:** ಪ್ರಾಜೆಕ್ಟ್ನ ರಚನೆ ಮತ್ತು ಕೋಡಿಂಗ್ ಶೈಲಿಯನ್ನು ತಿಳಿದುಕೊಳ್ಳಿ.
|
||||
* **ಸಮುದಾಯಕ್ಕೆ ಸೇರಿ:** Slack, Discord ಅಥವಾ ಫೋರಮ್ಗಳಲ್ಲಿ ಚರ್ಚೆಗಳಲ್ಲಿ ಭಾಗವಹಿಸಿ.
|
||||
|
||||
### 3. ಚಿಕ್ಕ ಹಂತಗಳಿಂದ ಪ್ರಾರಂಭಿಸಿ
|
||||
|
||||
* **ಬಗ್ಗಳನ್ನು ಸರಿಪಡಿಸಿ:** ಆರಂಭಿಕರಿಗೆ ಅನುಕೂಲಕರವಾದ issues ಹುಡುಕಿ.
|
||||
* **ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ಸುಧಾರಿಸಿ:** ಬಹಳ ಉಪಯುಕ್ತವಾದರೂ ಹೆಚ್ಚಾಗಿ ಗಮನಿಸದೆ ಬಿಡಲಾಗುತ್ತದೆ.
|
||||
* **ಟೆಸ್ಟ್ಗಳನ್ನು ಬರೆಯಿರಿ:** ಕೋಡ್ ತಿಳಿಯಲು ಉತ್ತಮ ವಿಧಾನ.
|
||||
|
||||
### 4. ಉತ್ತಮ ಅಭ್ಯಾಸಗಳನ್ನು ಅನುಸರಿಸಿ
|
||||
|
||||
* **Fork ಮತ್ತು Clone ಮಾಡಿ**
|
||||
* **ಪ್ರತ್ಯೇಕ branch ನಲ್ಲಿ ಕೆಲಸ ಮಾಡಿ**
|
||||
* **ಸ್ವಚ್ಛ ಕೋಡ್ ಬರೆಯಿರಿ**
|
||||
* **ನಿಮ್ಮ ಬದಲಾವಣೆಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ**
|
||||
* **Pull Request ಕಳುಹಿಸಿ:** ಸ್ಪಷ್ಟ ವಿವರಣೆ ನೀಡಿ, ಸಂಬಂಧಿತ issueಗಳನ್ನು ಉಲ್ಲೇಖಿಸಿ ಮತ್ತು feedback ಸ್ವೀಕರಿಸಲು ತೆರೆದಿರಲಿ.
|
||||
|
||||
## ಯಶಸ್ಸಿಗೆ ಸಲಹೆಗಳು
|
||||
|
||||
* **ಸಮರ್ಪಕ ಸಂವಹನ ಮಾಡಿ:** ಗೌರವಪೂರ್ವಕವಾಗಿ ವರ್ತಿಸಿ ಮತ್ತು ಸ್ಪಷ್ಟವಾಗಿ ಪ್ರಶ್ನೆ ಮಾಡಿ.
|
||||
* **ಸ್ಥಿರತೆಯಿಂದಿರಿ:** ಸಣ್ಣ ಕೊಡುಗೆಗಳೂ ಸಮಯದೊಂದಿಗೆ ದೊಡ್ಡ ಪರಿಣಾಮ ಬೀರುತ್ತವೆ.
|
||||
* **ಫೀಡ್ಬ್ಯಾಕ್ನಿಂದ ಕಲಿಯಿರಿ:** ಕೋಡ್ ರಿವ್ಯೂ ಒಳ್ಳೆಯ ಕಲಿಕೆಯ ಅವಕಾಶ.
|
||||
* **ಇತರರಿಗೆ ಸಹಾಯ ಮಾಡಿ:** ನೀವು ಅನುಭವ ಹೊಂದಿದ ಮೇಲೆ ಹೊಸಬರಿಗೆ ಮಾರ್ಗದರ್ಶನ ನೀಡಿ.
|
||||
|
||||
## ಸಾಮಾನ್ಯ ಸವಾಲುಗಳು ಮತ್ತು ಪರಿಹಾರಗಳು
|
||||
|
||||
* **Impostor Syndrome:** ಚಿಕ್ಕ ಕೊಡುಗೆಗಳೂ ಮುಖ್ಯ. ಎಲ್ಲರೂ ಎಲ್ಲಿಂದೋ ಆರಂಭಿಸಿದ್ದಾರೆ.
|
||||
* **ಸಮಯದ ಕೊರತೆ:** ಸಣ್ಣ ಟಾಸ್ಕ್ಗಳಿಂದ ಪ್ರಾರಂಭಿಸಿ. ವಾರಕ್ಕೆ 30 ನಿಮಿಷ ಕೂಡ ಸಾಕು.
|
||||
* **ದೊಡ್ಡ ಕೋಡ್ಬೇಸ್ ಅನ್ನು ನಾವಿಗೇಟ್ ಮಾಡುವುದು:** ಒಂದೊಂದೇ ಘಟಕ concentrate ಮಾಡಿ, documentation ಓದಿ, ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳಿ.
|
||||
|
||||
## ಸಮಾರೋಪ
|
||||
|
||||
ಓಪನ್ಸೋರ್ಸ್ಗೆ ಕೊಡುಗೆ ನೀಡುವುದು ವೈಯಕ್ತಿಕ ಮತ್ತು ವೃತ್ತಿಪರ ಬೆಳವಣಿಗೆಗೆ ದೊಡ್ಡ ಅವಕಾಶ. ಸಣ್ಣ ಹಂತಗಳಿಂದ ಆರಂಭಿಸಿ, ನಿಯಮಿತವಾಗಿರಿ, ಸಮುದಾಯದೊಂದಿಗೆ ಸಂವಹನ ಮಾಡಿ — ಹೀಗೆ ನಿಮ್ಮ ಕೌಶಲ್ಯಗಳನ್ನು ಬೆಳೆಸುತ್ತಾ ಪರಿಣಾಮಕಾರಿ ಕೊಡುಗೆಗಳನ್ನು ನೀಡಬಹುದು. ಪ್ರತಿಯೊಂದು ಕೊಡುಗೆಯೂ ಮಹತ್ವದ್ದೇ. ಇಂದೇ ಪ್ರಾರಂಭಿಸಿ — ನಿಮಗೆ ಇಷ್ಟವಾದ ಪ್ರಾಜೆಕ್ಟ್ ಹುಡುಕಿ, ಮೊದಲ ಕೊಡುಗೆ ನೀಡಿ ಮತ್ತು ಜಾಗತಿಕ ಓಪನ್ಸೋರ್ಸ್ ಚಳುವಳಿಯ ಭಾಗವಾಗಿರಿ!
|
||||
|
||||
@@ -0,0 +1,81 @@
|
||||
## 오픈소스 프로젝트는 프로그래머만 기여할 수 있는 것이 아닙니다. 코딩 실력이 없어도 오픈소스 프로젝트에 참여하고 기여할 수 있는 다양한 방법들이 있습니다.
|
||||
|
||||
## 경청하기
|
||||
|
||||
오픈소스의 모든 것은 다른 사람들과의 상호작용을 포함합니다. 여러분은 팀에 합류하려는 것이므로, 커뮤니티와 그 작동 방식을 이해하는 것이 중요합니다. 프로젝트에 불쑥 끼어들어 "안녕하세요, 이 프로젝트는 이렇게 해야 한다고 생각합니다"라고 말하는 것은 일반적으로 좋게 받아들여지지 않습니다. 그런 접근 방식을 환영하는 프로젝트도 있겠지만, 프로젝트가 오랫동안 진행되어 온 경우 그러한 태도가 받아들여질 가능성은 적습니다.
|
||||
**경청하는 것이 프로젝트에 필요한 것을 아는 가장 좋은 방법입니다.**
|
||||
|
||||
1. **메일링 리스트 가입하기**: 많은 프로젝트에서 메일링 리스트는 프로젝트 개발에 대한 주요 커뮤니케이션 수단입니다. 대규모 프로젝트에는 선택할 수 있는 메일링 리스트가 많습니다. 예를 들어, PostgreSQL 프로젝트는 메일링 리스트 페이지에 사용자 중심 리스트 12개 이상과 개발자 리스트 6개를 보유하고 있습니다. 시작하려면 주요 사용자 중심 리스트와 핵심 개발자 리스트를 팔로우하여 경청하는 것을 추천합니다.
|
||||
|
||||
2. **블로그 팔로우하기**: 핵심 개발자들이 운영하는 블로그는 종종 향후 릴리스에 대한 정보와 그 과정에 대한 정보를 제공합니다. 플래닛 사이트는 프로젝트와 관련된 여러 출처의 뉴스 및 블로그 게시물을 모아 보여줍니다. planet.gnome.org나 planet.mysql.com과 같은 플래닛 사이트가 있다면 거기서부터 시작하세요. Google에서 "planet <프로젝트 이름>"으로 검색해보세요.
|
||||
|
||||
3. **IRC 채널 가입하기**: 많은 오픈소스 프로젝트에는 개발자와 사용자가 문제 및 개발에 대해 논의하는 전용 IRC(Internet Relay Chat) 채널이 있습니다. 프로젝트 웹사이트에서 채널 이름과 IRC 네트워크 세부 정보를 확인하세요.
|
||||
|
||||
|
||||
## 티켓 작업하기
|
||||
|
||||
코드는 모든 오픈소스 프로젝트의 핵심이지만, 코드를 작성하는 것만이 기여하는 유일한 방법이라고 생각하지 마세요. 코드 유지 보수 및 코드를 둘러싼 시스템은 새로운 기능을 만들고 버그를 수정하는 데 급급하여 종종 소홀히 다루어집니다. 이러한 영역을 프로젝트에 발을 들여놓을 수 있는 쉬운 방법으로 살펴보세요. 대부분의 프로젝트에는 프로젝트 웹사이트 첫 페이지에 링크되어 있고 문서에 포함된 공개적으로 볼 수 있는 문제 티켓 시스템이 있습니다. 이는 사용자와 개발자 간의 주요 커뮤니케이션 수단입니다. 이를 최신 상태로 유지하는 것은 프로젝트를 돕는 좋은 방법입니다. 티켓 시스템에서 특별한 권한을 얻어야 할 수도 있는데, 대부분의 프로젝트 리더는 티켓 정리를 돕고 싶다고 말하면 기꺼이 권한을 부여할 것입니다.
|
||||
|
||||
4. **버그 진단하기**: 버그는 종종 제대로 보고되지 않습니다.
|
||||
버그를 진단하고 분류하는 것은 개발자가 문제의 세부 사항을 파악하는 데 드는 수고를 덜어줄 수 있습니다. 사용자가 "X를 하면 소프트웨어가 작동하지 않습니다"라고 보고했다면, 그 문제의 구체적인 내용이 무엇인지 파악하는 데 시간을 투자하세요. 반복 가능한가요? 문제를 반복적으로 발생시킬 수 있는 일련의 단계를 만들 수 있나요? 특정 브라우저에서만 발생하거나 특정 배포판에서만 발생하는 등 문제를 좁힐 수 있나요?
|
||||
|
||||
문제의 원인을 모르더라도, 상황을 좁히기 위해 기울인 노력은 다른 사람이 문제를 해결하는 것을 더 쉽게 만듭니다. 발견한 모든 것을 모든 사람이 볼 수 있도록 버그 시스템의 티켓에 추가하세요.
|
||||
|
||||
5. **수정된 버그 닫기**: 종종 버그는 코드베이스에서 수정되지만, 이에 대해 보고된 티켓은 티켓 시스템에서 업데이트되지 않습니다. 이러한 불필요한 것들을 정리하는 것은 시간이 많이 걸릴 수 있지만, 전체 프로젝트에 매우 중요합니다.
|
||||
|
||||
먼저 1년 이상 된 티켓을 티켓 시스템에서 쿼리하여 버그가 여전히 존재하는지 확인하세요. 프로젝트의 릴리스 변경 로그를 확인하여 버그가 수정되었고 닫을 수 있는지 확인하세요. 수정된 것으로 알려져 있다면 티켓에 버전 번호를 기록하고 닫으세요.
|
||||
|
||||
소프트웨어의 최신 버전으로 버그를 재현해보세요. 최신 버전으로 재현할 수 없다면 티켓에 기록하고 닫으세요. 여전히 존재한다면 티켓에 기록하고 열어 두세요.
|
||||
|
||||
|
||||
|
||||
## 코드 작업하기
|
||||
|
||||
모든 경험 수준의 프로그래머가 프로젝트의 코드를 도울 수 있습니다. 좋아하는 프로젝트에 실질적인 기여를 하기 위해 코딩 천재가 되어야 한다고 생각하지 마세요.
|
||||
|
||||
작업에 코드 수정이 포함된다면, 프로젝트가 기여자로부터 코드를 받는 데 사용하는 방법을 조사하세요. 각 프로젝트마다 고유한 워크플로우가 있으므로, 코드를 제출하기 전에 어떻게 해야 하는지 물어보세요.
|
||||
|
||||
예를 들어, PostgreSQL 프로젝트는 매우 엄격한 프로세스를 따릅니다. 코드 수정은 핵심 개발자들이 변경 사항의 모든 측면을 면밀히 조사하는 메일링 리스트에 패치 형태로 전송됩니다. 반대편에는 Parrot과 같이 코드베이스에 커밋 권한을 쉽게 얻을 수 있는 프로젝트도 있습니다. 프로젝트가 GitHub를 사용하는 경우, GitHub의 풀 리퀘스트 기능을 사용하는 워크플로우가 있을 수 있습니다. 어떤 프로젝트도 똑같지 않습니다.
|
||||
|
||||
코드를 수정할 때마다 커뮤니티의 책임 있는 구성원으로서 행동하고 코드 스타일을 나머지 코드베이스와 일치시키도록 하세요. 추가하거나 수정하는 코드는 다른 코드와 같아야 합니다. 중괄호 스타일이나 들여쓰기를 위한 공백 처리가 마음에 들지 않을 수도 있지만, 기존 표준과 일치하지 않는 코드 변경을 제출하는 것은 무례한 행동입니다. 이는 "당신의 스타일이 마음에 들지 않고 내 스타일이 더 낫다고 생각하므로 내 방식대로 해야 합니다"라고 말하는 것과 같습니다.
|
||||
|
||||
6. **베타 또는 릴리스 후보 테스트하기**: 여러 플랫폼에서 실행되도록 설계된 모든 프로젝트는 온갖 종류의 이식성 문제를 겪을 수 있습니다. 릴리스가 다가오고 베타 또는 릴리스 후보가 게시되면 프로젝트 리더는 많은 다른 사람들이 많은 다른 플랫폼에서 테스트하기를 바랍니다. 여러분은 그 사람들 중 한 명이 되어 패키지가 자신의 플랫폼에서 작동하는지 확인하는 데 도움을 줄 수 있습니다.
|
||||
|
||||
일반적으로 소프트웨어를 다운로드, 빌드 및 테스트하기만 하면 되지만, 흔하지 않은 배포판이나 하드웨어를 사용하고 있다면 프로젝트에 엄청난 가치를 제공할 수 있습니다. 빌드 및 테스트가 작동한다고 보고하는 것만으로도 프로젝트 리더는 임박한 릴리스가 견고하다는 것을 알 수 있습니다.
|
||||
|
||||
|
||||
7. **버그 수정하기**: 이것은 일반적으로 코드 작업을 시작하려는 기여자들의 시작점입니다. 간단합니다. 티켓 시스템에서 흥미롭게 들리는 버그를 찾아 코드에서 수정하려고 시도하세요. 적절하다면 코드에 수정 사항을 문서화하세요. 수정한 코드 부분을 테스트하기 위해 테스트 스위트에 테스트를 추가하는 것이 좋습니다. 일부 프로젝트에서는 버그 수정에 테스트를 포함하도록 요구합니다. 이 익숙하지 않은 코드베이스를 살펴보면서 메모를 계속 작성하세요. 버그를 수정할 수 없더라도 수정 시도의 일환으로 발견한 내용을 티켓에 문서화하세요. 여러분이 발견한 내용은 다음에 오는 사람들에게 도움이 됩니다.
|
||||
|
||||
|
||||
8. **테스트 작성하기**: 대부분의 프로젝트에는 코드를 테스트하는 테스트 스위트가 있지만, 더 많은 테스트를 추가할 수 없는 테스트 스위트는 상상하기 어렵습니다. C 언어용 gcov 또는 Perl용 Devel::Cover와 같은 테스트 커버리지 도구를 사용하여 테스트 스위트에서 테스트되지 않는 소스 코드 영역을 식별하세요. 그런 다음, 테스트를 스위트에 추가하여 해당 영역을 커버하세요.
|
||||
|
||||
|
||||
9. **컴파일러 경고 잠재우기**: 많은 C 기반 프로젝트의 빌드 프로세스는 종종 이상한 컴파일러 경고 플래그를 화면에 뿜어냅니다. 이러한 경고는 일반적으로 문제의 지표는 아니지만 그렇게 보일 수 있습니다. 너무 많은 경고는 컴파일러가 거짓 경고를 하는 것처럼 들리게 할 수 있습니다. 코드가 실제로 버그를 숨기고 있는지 확인하세요. 그렇지 않다면, 소스를 수정하여 잠재우는 것은 이러한 오탐을 숨기는 데 도움이 됩니다.
|
||||
|
||||
|
||||
10. **주석 추가하기**: 코드를 살펴보는 동안 혼란스러운 부분이 있을 수 있습니다. 여러분이 혼란스러웠다면 다른 사람들도 마찬가지일 가능성이 높습니다. 코드에 문서화하고 패치를 제출하세요.
|
||||
|
||||
|
||||
## 문서 작업하기
|
||||
|
||||
문서는 일반적으로 프로젝트에서 소홀히 다루어지는 부분입니다. 또한 프로젝트에 익숙한 사람들의 관점에서 작성되어, 막 시작하는 사람의 관점이 아닌 경우도 있습니다. "이 매뉴얼은 내가 이미 이 패키지를 사용하는 방법을 알고 있다고 기대하는 것 같아"라고 생각한 적이 있다면 제가 무슨 말을 하는지 아실 겁니다. 종종 새로운 시선은 프로젝트와 가까운 사람들이 알아차리지 못하는 문서의 결함을 지적할 수 있습니다.
|
||||
|
||||
11. **예시 만들기**: 예시가 너무 많은 프로젝트는 없습니다. 웹 API든, 루틴 라이브러리든, Gimp와 같은 GUI 앱이든, 명령줄 도구든, 올바른 사용법에 대한 좋은 예시는 수백 페이지의 문서보다 더 명확하고 빠르게 소프트웨어의 올바른 사용법을 설명할 수 있습니다. API나 라이브러리의 경우, 도구를 사용하는 예시 프로그램을 만드세요. 이는 여러분이 작성한 코드에서 최소한의 필수적인 부분만 추출하여 만들 수도 있습니다. 도구의 경우, 일상생활에서 어떻게 사용했는지에 대한 실제 사례를 보여주세요. 시각적인 것을 선호한다면, 애플리케이션 설치 방법과 같은 중요한 프로세스의 화면 캡처를 만드는 것을 고려해 보세요.
|
||||
|
||||
|
||||
|
||||
## 커뮤니티와 함께 작업하기
|
||||
|
||||
오픈소스는 코드에 관한 것만이 아닙니다. 커뮤니티가 오픈소스가 작동하도록 만듭니다. 커뮤니티를 구축하는 데 도움을 줄 수 있는 방법은 다음과 같습니다.
|
||||
|
||||
12. **질문에 답하기**: 커뮤니티를 구축하는 가장 좋은 방법은 다른 사람들을 돕는 것입니다. 특히 막 시작하는 사람들의 질문에 답하는 것은 프로젝트가 성장하고 번성하는 데 매우 중요합니다. 초보자를 돕는 데 시간을 투자하는 것은, 비록 "RTFM(매뉴얼을 읽으세요)"이라고 간단히 대답할 수 있는 질문일지라도, 나중에 또 다른 활발한 커뮤니티 구성원을 얻는 데 도움이 됩니다. 모든 사람은 어디서든 시작하며, 프로젝트는 활력을 유지하려면 꾸준한 인력 유입이 필요합니다.
|
||||
|
||||
13. **블로그 게시물 작성하기**: 블로그가 있다면, 사용하고 있는 프로젝트에 대한 경험에 대해 글을 써보세요. 소프트웨어를 사용하면서 직면했던 문제와 그것을 해결하기 위해 무엇을 했는지 이야기해 주세요. 이렇게 하면 두 가지 방식으로 도움이 됩니다. 하나는 프로젝트를 주변 사람들의 마음에 계속 각인시키는 데 도움이 되고, 다른 하나는 미래에 여러분과 같은 문제를 겪고 웹에서 해결책을 검색하는 모든 사람을 위한 기록을 만드는 데 도움이 됩니다. (기술적인 모험에 대한 블로그는 나중에 해당 소프트웨어를 사용하는 직업을 찾을 때 실제 경험을 보여주는 훌륭한 방법이기도 합니다.)
|
||||
|
||||
14. **웹사이트 개선하기**: 웹 디자인 기술이 있고 웹사이트를 개선하여 프로젝트의 대중적인 이미지를 향상시킬 수 있다면, 이는 잘 보낸 시간입니다. 아마도 프로젝트는 그래픽 전면 개편이나 프로젝트를 식별할 로고가 필요할 수도 있습니다. 이러한 기술은 커뮤니티에 부족할 수 있습니다. 저도 제 프로젝트 웹사이트에 그래픽 디자인 지원을 받을 수 있다면 좋을 것 같습니다.
|
||||
|
||||
15. **기술 문서 작성하기**: 애플리케이션이나 소프트웨어가 어떻게 작동하는지 설명할 수 있다면, 그것에 대한 기술 문서를 작성할 수 있습니다. 특히 일반 대중이 읽을 수 있도록 기술 문서를 업데이트, 개편, 확장 또는 만들고자 하는 오픈소스 프로젝트라면 더욱 그렇습니다. 일반 영어로 더 많이 쓸수록 좋습니다. 가장 좋은 점은 기술 문서를 작성하기 위해 프로그래머가 될 필요가 없다는 것입니다.
|
||||
|
||||
무엇보다도, 주변 사람들이 논의하는 내용을 경청하세요. 절실한 필요를 알아볼 수 있는지 살펴보세요. 예를 들어, 최근 Parrot 개발자 메일링 리스트에서 기존 Trac 설치를 버리고 GitHub를 문제 티켓 시스템으로 사용하기로 결정했습니다. 일부 사람들은 티켓을 GitHub 시스템으로 변환할 방법이 없었기 때문에 이 결정에 반대했습니다. 하루 동안 논쟁이 오고 간 후, 제가 끼어들어 "제가 변환기를 작성하면 어떨까요?"라고 말했습니다. 사람들은 그 아이디어에 열광했습니다. 저는 450개 이상의 티켓에 대한 변환 프로그램을 작성하는 데 시간을 보냈고, 그래서 티켓 기록을 하나도 잃지 않았습니다. 큰 성공이었습니다. 저는 참여할 수 있었고, 핵심 개발자들은 Parrot 작업에 집중할 수 있었습니다.
|
||||
|
||||
16. **다른 사람들을 가르치고 돕기**: 어떤 주제에 대해 더 많이 배우는 가장 좋은 방법은 그것을 가르치려고 노력하는 것입니다. 최고의 교사는 복잡한 내용을 간단한 예시로 설명할 수 있는 사람입니다. 따라서 최고의 학습자가 되고 프로그래밍 세계에서 최고가 되려면 최고의 교사가 되기 위해 노력해야 합니다. 다른 사람들을 가르치는 것은 자신에 대해 더 나은 기분을 느끼게 하고 직업에서 더 나은 기술과 지식을 얻는 데 도움이 될 것입니다. 누군가에게 도움을 받으면 혼자 간직하지 말고 다른 사람들과 공유하세요. 세상을 더 살기 좋은 곳으로 만드세요.
|
||||
+71
@@ -0,0 +1,71 @@
|
||||
# Cum sa contribuiti la proiectele Open Source: Un ghid detaliat pentru incepatori
|
||||
|
||||
Pe scurt: Daca sunteti nerabdator/nerabdatoare sa creati primul Pull Request pe un proiect Open Source, folositi instructiunile de aici: [Readme](https://github.com/firstcontributions/first-contributions)
|
||||
|
||||
Contributiile la proiectele Open Source reprezinta una dintre cele mai bune metode de a te dezvolta ca programator/programatoare, a-ti dezvolta portofoliul si a da ceva inapoi comunitatii. Fie ca esti un programator senior sau doar ai inceput, proiectele Open Source ofera foarte multe oportunitati de a invata, colabora si a avea un impact pozitiv. In acest ghid, vom trece prin tot ceea ce trebuie sa stiti pentru a contribui la proiectele Open Source, de la a gasi proiectul protrivit si pana la a realiza prima contributie.
|
||||
|
||||
## De ce sa contribuiti la proiectele Open Source?
|
||||
|
||||
Inainte sa vorbim despre "cum", sa exploram "de ce". Contribuirea la proiectele Open Source ofera numeroase beneficii:
|
||||
|
||||
* Dezvoltarea abilitatilor: Proiectele Open Source va expun la cod sursa din proiecte reale, ajutandu-va la imbunatatirea abilitatilor dvs. de programare, depanare si colaborare.
|
||||
* Construirea unui Portofoliu: Contributiile la proiectele bine cunoscute va pot imbogati CV-ul si profilul dvs. de pe Github, ajutandu-va sa iesiti in evidenta in fata potentialilor angajatori.
|
||||
* Networking (Colaborarea, socializarea cu scop profesional): Va veti conecta cu dezvoltatori din intreaga lume, veti invata de la experti si veti face parte la randul dvs. din aceasta comunitate globala.
|
||||
* Sa dai inapoi (ca multumire): Proiectele Open Source stau la baza multor aplicatii/programe software pe care le folosim zilnic. Contributiile sunt un mod de a sustine uneltele si tehnologiile pe care va bazati/de care depindeti.
|
||||
* Oportunitati de cariera: Multe companii cauta in mod activ programatori cu experienta pe proiecte Open Source deoarece astfel se demonstreaza initiativa, proactivitatea si lucrul in echipa.
|
||||
|
||||
## Cum sa incepeti sa contribuiti pe proiectele Open Source
|
||||
|
||||
### 1. Alegeti Proiectul potrivit
|
||||
|
||||
Identificarea proiectului potrivit este cruciala. Cautati proiecte care se aliniaza intereselor, nivelurilor abilitatilor si telurilor dvs.. Le puteti gasi intr-unul din modurile urmatoare:
|
||||
|
||||
* Explorati Github: Folositi pagina Github Explore sau cautati topicurile precum "necesita-ajutor", "ajutor-cerut", "good-first-issue", "help-wanted" etc.
|
||||
* Cautati programe dedicate Open Source: Programe ca Google Summer of Code, Hacktoberfest si altele sunt bune pentru incepatori.
|
||||
* Urmariti proiectele dedicate uneltelor/programelor tale (favorite): Contribuie la librarii, frameworks, unelte sau programe pe care deja le folositi.
|
||||
|
||||
### 2. Intelegeti proiectul
|
||||
|
||||
Inainte sa contribuiti, este indicat sa dedicati timp pentru a intelege proiectul:
|
||||
|
||||
* Cititi documentatia: Incepeti cu fisierul README, cele mai bune practici, reguli si indicatii pentru contributii si regulamentul de conduita.
|
||||
* Exploreaza codul sursa: Familiarizati-va cu structura proiectului si stilul de programare (indentari, conventii de nume, etc.).
|
||||
* Alaturati-va comunitatii: Participati la discutiile de pe forumuri, Slack sau Discord pentru a va acomoda mai usor in comunitate.
|
||||
|
||||
### 3. Incepeti cu pasi mici
|
||||
|
||||
Incepeti cu pasi mici, sarcini de lucru pe care le puteti dezvolta, care va vor ajuta sa deveniti mai increzator/increzatoare, precum:
|
||||
|
||||
* Repararea defectelor: Cauta "issues" ((cerinte de) sarcini de lucru) pe pagina dedicata, care au etichete precum "sarcina-buna-de-inceput", "pentru-incepatori", "incepatori", "good-first-issue", "beginner-friendly" etc.
|
||||
* Imbunatatiti documentatia: Actualizarile documentatiei sunt adesea trecute cu vederea, insa aduc multa plus-valoare.
|
||||
* Scrieti teste: Adaugarea de teste (teste unitare, teste de integrare, etc.) este un mod foarte bun de a contribui si a invata mai bine codul sursa.
|
||||
|
||||
### 4. Folositi cele mai bune practici
|
||||
|
||||
Cand contribuiti, este bine sa respectati indicatiile pentru cele mai bune practici:
|
||||
|
||||
* Bifurca si Cloneaza: Bifurcati (fork) si clonati codul sursa (depozitul) pe masina dvs. locala.
|
||||
* Creati o ramura: Lucrati pe o ramura separata pentru a face modificarile dvs..
|
||||
* Scrieti cod curat: Urmariti standardele de a scrie cod sursa si scrieti cod clar, curat, citibil, concis.
|
||||
* Testati modificarile: Asigurati-va ca modificarile dvs. nu vor afecta functionalitatea existenta.
|
||||
* Creati un Pull Request (cerere de unificare cod sursa intre doua ramuri): Faceti o cerere de unificare a versiunii dvs. de cod sursa cu cel existent pe alta ramura (de obicei cea principala), unde trebuie sa aveti o descriere clara a PR-ului, referentiati alte sarcini de lucru corelate si fiti deschisi la feedback.
|
||||
|
||||
## Sfaturi pentru a avea succes in proiectele Open Source
|
||||
|
||||
Comunicati eficient si eficace: Fiti respectuosi si comportati-va in mod profesional in toate interactiunile. Puneti intrebari cand nu sunteti siguri de cerinte. Aveti rabdare in timpul procesului de evaluare/revizuire.
|
||||
|
||||
Fiti consistenti: Contributiile regulate, chiar si cele mici, pot avea un impact mare in timp.
|
||||
|
||||
Invatati din feedback: Evaluarile de cod sursa sunt un prilej de invatare. Acceptati rezultatele acestor evaluari si va veti imbunatati abilitatile.
|
||||
|
||||
Dati inapoi (ceva comunitatii): Odata ce sunteti comfortabil(a) cu procesul de PR, ajutati-i si pe altii in acest proces, raspundeti-le la intrebari sau chiar fiti mentor pentru incepatori.
|
||||
|
||||
## Provocari comune si cum sa le depasiti
|
||||
|
||||
* Sindromul Impostorului: Multi incepatori simt ca nu au destule abilitati pentru a contribui. Retineti ca toti au inceput de undeva si ca pana si contributiile mici conteaza.
|
||||
* Gasirea timpului necesari: Incepeti cu sarcini de lucru mici, pe care le puteti face. Pana si 30 de minute pe saptamana pot face o diferenta.
|
||||
* Navigarea unui depozit mare de cod sursa: Impartiti procesul de invatare: Incepeti prin a citi in detaliu documentatia - Concentrati-va pe intelegerea unei singure componente la un moment dat - Folositi toate uneltele pentru depanare de care dispuneti - Nu ezitati sa puneti intrebari pentru clarificari
|
||||
|
||||
## Concluzie
|
||||
|
||||
Contributia la proiectele Open Source este o calatorie/aventura/un proces care va ofera imense posibilitati de dezvoltare personala si profesionala. Incepand cu pasi mici, ramanand consistenti si interactionand cu comunitatea, puteti face contributii de impact in timp ce va imbunatatiti abilitatile. Tineti minte ca proiectele Open Source se dezvolta prin colaborare si ca fiecare contributie - indiferent de cat de mica ar fi - ajuta la imbunatatirea mediului digital. Sunteti gata sa incepeti? Gasiti un proiect care va atrage, realizati prima contributie si alaturati-va miscarii globale Open Source astazi!
|
||||
+94
@@ -0,0 +1,94 @@
|
||||
# ஓபன் சோர்ஸிற்குப் பயனளிக்க எப்படி: ஒரு விரிவான வழிகாட்டி (குவிகட்டிய தொடக்கத்திற்காக)
|
||||
|
||||
**TL;DR** - நீங்கள் ஓபன் சோர்ஸ் திட்டத்தில் உங்கள் முதல் புல் ரிக்வஸ்டை செய்ய விரும்பினால், [Readme](https://github.com/firstcontributions/first-contributions) லுள்ள வழிமுறைகளைப் பின்பற்றுங்கள். நான் ஒரு சிறிய பிழையை திருத்தும் பங்களிப்பை என் முதல் பங்களிப்பாகச் செய்கிறேன்.
|
||||
|
||||
ஓபன் சோர்ஸிற்குப் பயனளிப்பது ஒரு மென்பொருள் டெவலப்பராக வளரவும், உங்கள் போர்ட்ஃபோலியோவை உருவாக்கவும், சமூகத்திற்குப் பங்களிக்கவும் சிறந்த வழிகளில் ஒன்றாகும். நீங்கள் அனுபவம் வாய்ந்த நிரலாளராக இருந்தாலும், அல்லது புதியதாக இருந்தாலும், ஓபன் சோர்ஸ் உங்களுக்கு நிறைய கற்றல், இணைப்பு, மற்றும் தாக்கம் செலுத்தும் வாய்ப்புகளை வழங்குகிறது.
|
||||
|
||||
இந்த வழிகாட்டியில், சரியான திட்டத்தைத் தேர்ந்தெடுப்பதிலிருந்து உங்கள் முதல் பங்களிப்பைச் செய்வது வரை, ஓபன் சோர்ஸில் பங்களிப்பதற்கான அனைத்து முக்கிய விஷயங்களையும் ஆராய்வோம்.
|
||||
|
||||
---
|
||||
|
||||
## ஏன் ஓபன் சோர்ஸில் பங்களிக்க வேண்டும்?
|
||||
|
||||
"எப்படி" என்பதைப் பார்க்கும் முன், "ஏன்" என்பதை ஆராய்வோம். ஓபன் சோர்ஸில் பங்களிப்பது பல நன்மைகளை வழங்குகிறது:
|
||||
|
||||
- **திறமைகளை மேம்படுத்துதல்** – உண்மையான புரொஜெக்ட் கோடுகளைப் பார்க்க வாய்ப்பு கிடைக்கும், எங்கேயும் சேர முடியாத அனுபவம் கிடைக்கும்.
|
||||
- **போர்ட்ஃபோலியோ உருவாக்கம்** – பிரபலமான ஓபன் சோர்ஸ் திட்டங்களில் பங்களிப்பது உங்கள் ரெஸ்யூமேயை மெருகூட்டும்.
|
||||
- **நெட்வொர்க்கிங்** – உலகளாவிய டெவலப்பர்களுடன் இணைவது, புதிய விஷயங்களைப் பழகுவது.
|
||||
- **சமூகத்திற்குப் பங்களிக்க** – நாம் தினமும் பயன்படுத்தும் மென்பொருள்களுக்கு உதவிக்கரம் நீட்டும் வாய்ப்பு.
|
||||
- **வேலை வாய்ப்புகள்** – ஓபன் சோர்ஸ் அனுபவம் கொண்டவர்களை பல நிறுவனங்கள் விரும்பி பணியமர்த்துகின்றன.
|
||||
|
||||
---
|
||||
|
||||
## ஓபன் சோர்ஸில் பங்களிக்க எப்படி தொடங்கலாம்?
|
||||
|
||||
### 1. சரியான திட்டத்தைத் தேர்ந்தெடுங்கள்
|
||||
|
||||
உங்களுக்குப் பொருத்தமான திட்டத்தை கண்டுபிடிப்பது முக்கியம். இதைப் பற்றிச் சில வழிகள்:
|
||||
|
||||
- **GitHub-ஐ ஆராயுங்கள்** – ["good-first-issue"](https://github.com/search?q=label%3Agood-first-issue) போன்ற தொடக்க நபர்களுக்கான குறிச்சொற்களைப் பயன்படுத்தி தேடுங்கள்.
|
||||
- **ஓபன் சோர்ஸ் நிகழ்ச்சிகளைப் பின்பற்றுங்கள்** – Google Summer of Code, Hacktoberfest போன்றவை சிறந்த தொடக்க புள்ளிகள்.
|
||||
- **உங்களுக்குப் பழக்கமான கருவிகளைத் தேர்வு செய்யுங்கள்** – நீங்கள் பயன்படுத்தும் புத்தகங்கள், libraries, frameworks ஆகியவற்றில் பங்களிக்கலாம்.
|
||||
|
||||
---
|
||||
|
||||
### 2. திட்டத்தைப் புரிந்துகொள்ளுங்கள்
|
||||
|
||||
பங்களிக்க முன்பாக, திட்டத்தை முழுமையாகப் புரிந்துகொள்ள முயற்சி செய்யுங்கள்:
|
||||
|
||||
- **README மற்றும் வழிமுறைகளை வாசிக்கவும்** – பங்களிப்பு வழிகாட்டி, கோட்பாடு (code of conduct) போன்றவற்றைப் பாருங்கள்.
|
||||
- **கோட்பணியை ஆராயுங்கள்** – கோப்புகளின் அமைப்பு, கோடிங் ஸ்டைல் போன்றவற்றை அறிந்து கொள்ளுங்கள்.
|
||||
- **சமூகத்தில் ஈடுபடுங்கள்** – Forums, Slack, Discord போன்ற இடங்களில் கலந்துரையாடுங்கள்.
|
||||
|
||||
---
|
||||
|
||||
### 3. சிறிய பங்களிப்புகளுடன் தொடங்குங்கள்
|
||||
|
||||
முதலில் எளிதான விடயங்களில் பங்களிக்கலாம்:
|
||||
|
||||
- **பிழைகளை சரிசெய்யுங்கள்** – "good-first-issue" அல்லது "beginner-friendly" போன்ற குறிச்சொற்களைப் பயன்படுத்தி சரிபாருங்கள்.
|
||||
- **ஆவணங்களை மேம்படுத்துங்கள்** – Documentation முக்கியமான பங்களிப்பு வழியாக இருக்கலாம்.
|
||||
- **Unit Testing எழுதுங்கள்** – Code coverage அதிகரிக்க இது உதவும்.
|
||||
|
||||
---
|
||||
|
||||
### 4. சிறந்த நடைமுறைகளைப் பின்பற்றுங்கள்
|
||||
|
||||
ஒரு நிரல்பாக பங்களிக்கும்போது, திட்ட விதிமுறைகளைப் பின்பற்றுங்கள்:
|
||||
|
||||
- **Fork & Clone செய்யுங்கள்** – உங்கள் கணக்கில் repository-ஐ fork செய்து, அதை local க்கு clone செய்யுங்கள்.
|
||||
- **Branch-ஐ உருவாக்குங்கள்** – தனியான branch-ல் வேலை செய்யுங்கள்.
|
||||
- **சுத்தமான கோட்களை எழுதுங்கள்** – திட்டத்திற்கேற்ப coding style-ஐ பின்பற்றுங்கள்.
|
||||
- **Test செய்யுங்கள்** – உங்கள் மாற்றங்கள் ஏதாவது பிரச்சனை ஏற்படுத்துகிறதா என்று சரிபாருங்கள்.
|
||||
- **Pull Request (PR) சமர்ப்பியுங்கள்** – PR-க்கு சரியான விளக்கம், issue reference, மற்றும் தயார் இருக்கும் மனப்பான்மை ஆகியவற்றுடன் சமர்ப்பியுங்கள்.
|
||||
|
||||
---
|
||||
|
||||
## ஓபன் சோர்ஸில் வெற்றி பெற சில குறிப்புகள்
|
||||
|
||||
✅ **தெளிவாக தொடர்புகொள்ளுங்கள்** – கேள்விகள் கேளுங்கள், புல்ல ரிக்வஸ்டுக்கு மறுமொழி கொடுப்பவர்களுக்கு நன்றி சொல்லுங்கள்.
|
||||
✅ **தொடர்ச்சியாக பங்களியுங்கள்** – சிறிய சிறிய பங்களிப்புகள் கூட பெரிய தாக்கத்தை ஏற்படுத்தும்.
|
||||
✅ **விமர்சனத்திலிருந்து கற்றுக்கொள்ளுங்கள்** – Code review மூலம் மேம்படுங்கள்.
|
||||
✅ **மற்றவர்களுக்கு உதவுங்கள்** – புல்ல ரிக்வஸ்டுகளை மதிப்பாய்வு செய்யுங்கள், புதியவர்களை வழிநடத்துங்கள்.
|
||||
|
||||
---
|
||||
|
||||
## பொதுவான சவால்கள் & அதை சமாளிக்க வழிகள்
|
||||
|
||||
❌ **Imposter Syndrome (நான் போதுமான திறமையுள்ளவரா? 🤔)**
|
||||
➡️ எல்லோருக்கும் இது வரும். சிறிய பங்களிப்புகளாலும் பெரிய தாக்கத்தை ஏற்படுத்தலாம்.
|
||||
|
||||
❌ **நேரம் இல்லாமை**
|
||||
➡️ ஒரு வாரத்திற்கும் 30 நிமிடங்கள் செலுத்தினாலும், நீங்கள் மெல்ல வளர முடியும்.
|
||||
|
||||
❌ **பெரிய கோட்பணியை புரிந்துகொள்வது கடினம்**
|
||||
➡️ டாக்குமென்டேஷனை வாசியுங்கள், ஒரு பிரிவில் கவனம் செலுத்துங்கள், Debugging tool-களை பயன்படுத்துங்கள்.
|
||||
|
||||
---
|
||||
|
||||
## முடிவுரை
|
||||
|
||||
ஓபன் சோர்ஸில் பங்களிப்பது வளர்ச்சிக்கு மிக நல்ல வழியாகும். சிறிய செயல்களில் தொடங்குங்கள், தொடர்ந்து பங்களியுங்கள், சமூகத்தில் ஈடுபடுங்கள். ஒவ்வொரு பங்களிப்பும் ஓபன் சோர்ஸை மேம்படுத்த உதவுகிறது.
|
||||
|
||||
🚀 **தொடங்க தயார்?**
|
||||
உங்களுக்கு பிடித்த திட்டத்தை தேடுங்கள், உங்கள் முதல் பங்களிப்பைச் செய்யுங்கள், மற்றும் உலகளாவிய ஓபன் சோர்ஸ் இயக்கத்தில் சேருங்கள்! 🎉
|
||||
+73
@@ -0,0 +1,73 @@
|
||||
# ఓపెన్ సోర్స్కు ఎలా సహకరించాలి: ప్రారంభకులకు సమగ్ర మార్గదర్శి
|
||||
|
||||
TL;DR మీరు ఓపెన్ సోర్స్ ప్రాజెక్ట్కి మీ మొదటి పుల్ అభ్యర్థనను చేయాలనుకుంటున్నట్లయితే, [Readme](https://github.com/firstcontributions/first-contributions)లోని సూచనలను అనుసరించండి.
|
||||
|
||||
డెవలపర్గా ఎదగడానికి, మీ పోర్ట్ఫోలియోను రూపొందించడానికి మరియు కమ్యూనిటీకి తిరిగి ఇవ్వడానికి ఓపెన్ సోర్స్కు సహకారం అందించడం అనేది అత్యంత బహుమతినిచ్చే మార్గాలలో ఒకటి. మీరు అనుభవజ్ఞుడైన ప్రోగ్రామర్ అయినా లేదా ఇప్పుడే ప్రారంభించినా, ఓపెన్ సోర్స్ తెలుసుకోవడానికి, సహకరించడానికి మరియు ప్రభావం చూపడానికి అంతులేని అవకాశాలను అందిస్తుంది. ఈ గైడ్లో, సరైన ప్రాజెక్ట్ను కనుగొనడం నుండి మీ మొదటి సహకారం అందించడం వరకు ఓపెన్ సోర్స్కు సహకరించడం గురించి మీరు తెలుసుకోవలసిన ప్రతిదానిని మేము మీకు తెలియజేస్తాము.
|
||||
|
||||
## ఓపెన్ సోర్స్కి ఎందుకు సహకరించాలి?
|
||||
|
||||
"ఎలా"లోకి ప్రవేశించే ముందు, "ఎందుకు" అనేదాన్ని అన్వేషిద్దాం. ఓపెన్ సోర్స్కు సహకారం అందించడం వలన అనేక ప్రయోజనాలను అందిస్తుంది:
|
||||
|
||||
* నైపుణ్యాభివృద్ధి: ఓపెన్ సోర్స్ ప్రాజెక్ట్లు మిమ్మల్ని వాస్తవ ప్రపంచ కోడ్బేస్లకు బహిర్గతం చేస్తాయి, మీ కోడింగ్, డీబగ్గింగ్ మరియు సహకార నైపుణ్యాలను మెరుగుపరచడంలో మీకు సహాయపడతాయి.
|
||||
* పోర్ట్ఫోలియో బిల్డింగ్: ప్రసిద్ధ ప్రాజెక్ట్లకు విరాళాలు మీ రెజ్యూమ్ మరియు GitHub ప్రొఫైల్ను మెరుగుపరుస్తాయి, తద్వారా మీరు సంభావ్య యజమానులకు ప్రత్యేకంగా నిలుస్తారు.
|
||||
* నెట్వర్కింగ్: మీరు ప్రపంచవ్యాప్తంగా ఉన్న డెవలపర్లతో కనెక్ట్ అవుతారు, నిపుణుల నుండి నేర్చుకుంటారు మరియు గ్లోబల్ కమ్యూనిటీలో భాగం అవుతారు.
|
||||
* గివింగ్ బ్యాక్: ఓపెన్ సోర్స్ మనం రోజూ ఉపయోగించే చాలా సాఫ్ట్వేర్లకు శక్తినిస్తుంది. మీరు ఆధారపడే సాధనాలు మరియు సాంకేతికతలకు మద్దతు ఇవ్వడానికి సహకారం అందించడం ఒక మార్గం.
|
||||
* కెరీర్ అవకాశాలు: చాలా కంపెనీలు ఓపెన్ సోర్స్ అనుభవంతో డెవలపర్లను చురుకుగా కోరుకుంటాయి, ఎందుకంటే ఇది చొరవ మరియు జట్టుకృషిని ప్రదర్శిస్తుంది.
|
||||
|
||||
## ఓపెన్ సోర్స్ కంట్రిబ్యూషన్లతో ఎలా ప్రారంభించాలి
|
||||
|
||||
### 1. సరైన ప్రాజెక్ట్ను ఎంచుకోండి
|
||||
|
||||
సరైన ప్రాజెక్ట్ను కనుగొనడం చాలా ముఖ్యం. మీ ఆసక్తులు, నైపుణ్యం స్థాయి మరియు లక్ష్యాలకు అనుగుణంగా ఉండే ప్రాజెక్ట్ల కోసం చూడండి. వాటిని ఎలా కనుగొనాలో ఇక్కడ ఉంది:
|
||||
|
||||
* GitHubని అన్వేషించండి: GitHub యొక్క అన్వేషణ పేజీని ఉపయోగించండి లేదా "గుడ్-ఫస్ట్-ఇష్యూ" లేదా "హెల్ప్-వాంటెడ్" వంటి అంశాల కోసం శోధించండి.
|
||||
* ఓపెన్ సోర్స్ ప్రోగ్రామ్లను తనిఖీ చేయండి: గూగుల్ సమ్మర్ ఆఫ్ కోడ్ లేదా హ్యాక్టోబర్ఫెస్ట్ వంటి ప్రోగ్రామ్లు ప్రారంభకులకు గొప్పవి.
|
||||
* మీ సాధనాలను అనుసరించండి: మీరు ఇప్పటికే ఉపయోగిస్తున్న లైబ్రరీలు, ఫ్రేమ్వర్క్లు లేదా సాధనాలకు సహకరించండి.
|
||||
|
||||
### 2. ప్రాజెక్ట్ను అర్థం చేసుకోండి
|
||||
|
||||
సహకరించే ముందు, ప్రాజెక్ట్ను అర్థం చేసుకోవడానికి సమయాన్ని వెచ్చించండి:
|
||||
|
||||
* డాక్యుమెంటేషన్ను చదవండి: README ఫైల్, సహకార మార్గదర్శకాలు మరియు ప్రవర్తనా నియమావళితో ప్రారంభించండి.
|
||||
* కోడ్బేస్ను అన్వేషించండి: ప్రాజెక్ట్ నిర్మాణం మరియు కోడింగ్ శైలితో మిమ్మల్ని మీరు పరిచయం చేసుకోండి.
|
||||
* సంఘంలో చేరండి: కమ్యూనిటీ కోసం ఒక అనుభూతిని పొందడానికి ఫోరమ్లు, స్లాక్ లేదా డిస్కార్డ్పై చర్చల్లో పాల్గొనండి.
|
||||
|
||||
### 3. చిన్నగా ప్రారంభించండి
|
||||
|
||||
విశ్వాసాన్ని పెంపొందించడానికి చిన్న, నిర్వహించదగిన పనులతో ప్రారంభించండి:
|
||||
|
||||
* బగ్లను పరిష్కరించండి: "మంచి-మొదటి సమస్య" లేదా "బిగినర్స్-ఫ్రెండ్లీ" అని లేబుల్ చేయబడిన సమస్యల కోసం చూడండి.
|
||||
* డాక్యుమెంటేషన్ను మెరుగుపరచండి: డాక్యుమెంటేషన్ అప్డేట్లు తరచుగా విస్మరించబడతాయి కానీ చాలా విలువైనవి.
|
||||
* పరీక్షలు రాయండి: పరీక్షలను జోడించడం అనేది కోడ్బేస్ గురించి తెలుసుకోవడానికి మరియు సహకరించడానికి ఒక గొప్ప మార్గం.
|
||||
|
||||
### 4. ఉత్తమ పద్ధతులను అనుసరించండి
|
||||
|
||||
సహకరించేటప్పుడు, ప్రాజెక్ట్ మార్గదర్శకాలకు కట్టుబడి ఉండండి:
|
||||
|
||||
* ఫోర్క్ మరియు క్లోన్: రిపోజిటరీని ఫోర్క్ చేసి మీ స్థానిక మెషీన్కు క్లోన్ చేయండి.
|
||||
* ఒక శాఖను సృష్టించండి: మీ మార్పుల కోసం ప్రత్యేక శాఖలో పని చేయండి.
|
||||
* క్లీన్ కోడ్ వ్రాయండి: ప్రాజెక్ట్ యొక్క కోడింగ్ ప్రమాణాలను అనుసరించండి మరియు స్పష్టమైన, సంక్షిప్త కోడ్ను వ్రాయండి.
|
||||
* మీ మార్పులను పరీక్షించండి: మీ మార్పులు ఇప్పటికే ఉన్న కార్యాచరణను విచ్ఛిన్నం చేయలేదని నిర్ధారించుకోండి.
|
||||
* ఒక పుల్ అభ్యర్థన (PR) సమర్పించండి: స్పష్టమైన PR వివరణ, సూచన సంబంధిత సమస్యలను వ్రాయండి మరియు అభిప్రాయానికి సిద్ధంగా ఉండండి.
|
||||
|
||||
## ఓపెన్ సోర్స్లో విజయం కోసం చిట్కాలు
|
||||
|
||||
ప్రభావవంతంగా కమ్యూనికేట్ చేయండి: అన్ని పరస్పర చర్యలలో గౌరవప్రదంగా మరియు వృత్తిపరంగా ఉండండి. అవసరాల గురించి అస్పష్టంగా ఉన్నప్పుడు ప్రశ్నలు అడగండి. సమీక్షకులకు వారి సమయం మరియు అభిప్రాయానికి ధన్యవాదాలు. సమీక్ష ప్రక్రియలో ఓపికగా ఉండండి
|
||||
|
||||
స్థిరంగా ఉండండి: రెగ్యులర్ కంట్రిబ్యూషన్లు, చిన్నవి కూడా, కాలక్రమేణా పెద్ద ప్రభావాన్ని చూపుతాయి.
|
||||
|
||||
అభిప్రాయం నుండి నేర్చుకోండి: కోడ్ సమీక్షలు నేర్చుకునే అవకాశం. అభిప్రాయాన్ని స్వీకరించండి మరియు మీ నైపుణ్యాలను మెరుగుపరచండి.
|
||||
|
||||
తిరిగి ఇవ్వండి: మీరు సౌకర్యవంతంగా ఉన్న తర్వాత, PRలను సమీక్షించడం, ప్రశ్నలకు సమాధానం ఇవ్వడం లేదా కొత్తవారికి మార్గదర్శకత్వం చేయడం ద్వారా ఇతరులకు సహాయం చేయండి.
|
||||
|
||||
## సాధారణ సవాళ్లు మరియు వాటిని ఎలా అధిగమించాలి
|
||||
|
||||
* ఇంపోస్టర్ సిండ్రోమ్: చాలా మంది ప్రారంభకులు తమకు సహకరించడానికి తగినంత నైపుణ్యం లేదని భావిస్తారు. గుర్తుంచుకోండి, ప్రతి ఒక్కరూ ఎక్కడో ఒకచోట ప్రారంభించబడతారు మరియు చిన్న విరాళాలు కూడా ముఖ్యమైనవి.
|
||||
* సమయాన్ని కనుగొనడం: చిన్న, నిర్వహించదగిన పనులతో ప్రారంభించండి. వారానికి 30 నిమిషాలు కూడా తేడా రావచ్చు.
|
||||
* పెద్ద కోడ్బేస్లను నావిగేట్ చేయడం: అభ్యాస ప్రక్రియను విచ్ఛిన్నం చేయండి: - డాక్యుమెంటేషన్ను పూర్తిగా చదవడం ద్వారా ప్రారంభించండి - ఒక సమయంలో ఒక భాగాన్ని అర్థం చేసుకోవడంపై దృష్టి పెట్టండి - కోడ్ అమలును ట్రేస్ చేయడానికి డీబగ్గింగ్ సాధనాలను ఉపయోగించండి - స్పష్టత కోసం అడగడానికి వెనుకాడకండి
|
||||
|
||||
## తీర్మానం
|
||||
|
||||
ఓపెన్ సోర్స్కు సహకరించడం అనేది అపారమైన వ్యక్తిగత మరియు వృత్తిపరమైన వృద్ధిని అందించే ప్రయాణం. చిన్నగా ప్రారంభించడం ద్వారా, స్థిరంగా ఉండటం మరియు సంఘంతో సన్నిహితంగా ఉండటం ద్వారా, మీరు మీ నైపుణ్యాలను మెరుగుపరుచుకుంటూ అర్ధవంతమైన సహకారాన్ని అందించవచ్చు. గుర్తుంచుకోండి, ఓపెన్ సోర్స్ సహకారంతో అభివృద్ధి చెందుతుంది మరియు ప్రతి సహకారం-ఎంత చిన్నదైనా-మెరుగైన డిజిటల్ ప్రపంచాన్ని నిర్మించడంలో సహాయపడుతుంది. మునిగిపోవడానికి సిద్ధంగా ఉన్నారా? మిమ్మల్ని ఉత్తేజపరిచే ప్రాజెక్ట్ను కనుగొనండి, మీ మొదటి సహకారాన్ని అందించండి మరియు ఈరోజే గ్లోబల్ ఓపెన్ సోర్స్ ఉద్యమంలో చేరండి!
|
||||
|
||||
## చివరి సమాధా
|
||||
Reference in New Issue
Block a user