mirror of
https://github.com/LucasVbr/first-contributions.git
synced 2026-05-14 01:31:50 +00:00
Merge branch 'main' into additional-info
This commit is contained in:
Roshan Jossy
@@ -101,7 +101,7 @@ Menjawab pertanyaan, terutama dari seseorang yang baru saja memulai, sangat pent
|
||||
Waktu yang Anda luangkan untuk membantu seorang pemula, bahkan jika mereka mengajukan pertanyaan di mana Anda dapat dengan mudah menjawab “RTFM” dengan cepat, akan terbayar di kemudian hari dengan mendapatkan anggota aktif lainnya di dalam komunitas.
|
||||
Semua orang memulai dari suatu tempat, dan proyek membutuhkan arus masuk orang yang konstan jika ingin tetap hidup.
|
||||
|
||||
13. **Tulislah sebuah postingan blog:
|
||||
13. **Tulislah sebuah postingan blog**:
|
||||
Jika Anda memiliki sebuah blog, tulislah tentang pengalaman Anda dengan proyek yang Anda gunakan.
|
||||
Ceritakan tentang masalah yang Anda hadapi dengan menggunakan perangkat lunak dan apa yang Anda lakukan untuk menyelesaikannya.
|
||||
Anda akan membantu dengan dua cara, yaitu dengan membantu menjaga proyek tetap berada di benak orang lain di sekitar Anda,
|
||||
|
||||
@@ -1,73 +1,73 @@
|
||||
# .gitignore
|
||||
## Understanding .gitignore
|
||||
|
||||
The .gitignore file is a text file that tells Git which files or folders to ignore in a project.
|
||||
The `.gitignore` file is an essential component of Git's workflow. It tells Git which files and folders to ignore, preventing unnecessary or sensitive data from being tracked in your repository.
|
||||
|
||||
A local .gitignore file is usually placed in the root directory of a project. You can also create a global .gitignore file and any entries in that file will be ignored in all of your Git repositories.
|
||||
## Why Use .gitignore?
|
||||
|
||||
## Why .gitignore
|
||||
Now you may wonder why would you want git to ignore certain files and folders. Its because you don't want files like build files, cache files, other local configuration files like node modules, compilation files, temporary files IDE's create, etc to be tracked by git. It's usually used to avoid committing transient files from your working directory that aren't useful to other collaborators.
|
||||
Certain files should not be included in version control because they are either:
|
||||
- Temporary or system-generated (e.g., cache, build files, logs)
|
||||
- Large dependencies that can be reinstalled (e.g., `node_modules`)
|
||||
- Personal or sensitive configuration files (e.g., API keys, environment variables)
|
||||
- IDE or editor-specific files (e.g., `.vscode/`, `.idea/`)
|
||||
|
||||
## Getting started
|
||||
To create a local .gitignore file, create a text file and name it .gitignore (remember to include the . at the beginning). Then edit this file as needed. Each new line should list an additional file or folder that you want Git to ignore.
|
||||
Ignoring these files keeps the repository clean, reduces conflicts, and prevents security risks.
|
||||
|
||||
The entries in this file can also follow a matching pattern.
|
||||
## Creating a .gitignore File
|
||||
|
||||
```
|
||||
* is used as a wildcard match
|
||||
/ is used to ignore path names relative to the .gitignore file
|
||||
# is used to add comments to a .gitignore file
|
||||
To create a `.gitignore` file:
|
||||
1. In your project root directory, create a new text file named `.gitignore`.
|
||||
2. List the files and folders you want to ignore, one per line.
|
||||
3. Save the file.
|
||||
|
||||
This is an example of what the .gitignore file could look like:
|
||||
### Basic Syntax for .gitignore
|
||||
- `*` → Wildcard for matching multiple files.
|
||||
- `/` → Specifies path relative to `.gitignore`.
|
||||
- `#` → Adds comments.
|
||||
|
||||
### Example .gitignore File:
|
||||
```sh
|
||||
# Ignore Mac system files
|
||||
.DS_store
|
||||
.DS_Store
|
||||
|
||||
# Ignore node_modules folder
|
||||
node_modules
|
||||
# Ignore dependency folders
|
||||
node_modules/
|
||||
venv/
|
||||
|
||||
# Ignore log and cache files
|
||||
*.log
|
||||
.cache/
|
||||
|
||||
# Ignore environment files
|
||||
.env
|
||||
|
||||
# Ignore all text files
|
||||
*.txt
|
||||
|
||||
# Ignore files related to API keys
|
||||
.env
|
||||
|
||||
# Ignore SASS config files
|
||||
.sass-cache
|
||||
|
||||
```
|
||||
To add or change your global .gitignore file, run the following command:
|
||||
|
||||
```
|
||||
## Global .gitignore (For All Projects)
|
||||
To create a global `.gitignore` file (applies to all repositories):
|
||||
```sh
|
||||
git config --global core.excludesfile ~/.gitignore_global
|
||||
|
||||
```
|
||||
This will create the file ~/.gitignore_global. Now you can edit that file the same way as a local .gitignore file. All of your Git repositories will ignore the files and folders listed in the global .gitignore file.
|
||||
Then, edit `~/.gitignore_global` as you would a local `.gitignore`.
|
||||
|
||||
## How to Untrack Files Previously Committed from New Gitignore
|
||||
## Removing Files from Git Tracking
|
||||
|
||||
To untrack a single file, ie stop tracking the file but not delete it from the system use:
|
||||
If a file was already committed before adding it to `.gitignore`, you need to remove it from tracking:
|
||||
|
||||
- **Untrack a single file** (but keep it locally):
|
||||
```sh
|
||||
git rm --cached filename
|
||||
```
|
||||
|
||||
- **Untrack all ignored files**:
|
||||
```sh
|
||||
git rm -r --cached .
|
||||
git add .
|
||||
git commit -m "Updated .gitignore"
|
||||
```
|
||||
|
||||
To undo `git rm --cached filename`, use:
|
||||
```sh
|
||||
git add filename
|
||||
```
|
||||
git rm --cached filename
|
||||
```
|
||||
|
||||
To untrack every file in .gitignore:
|
||||
|
||||
First, commit any outstanding code changes, and then run:
|
||||
|
||||
```
|
||||
git rm -r --cached
|
||||
```
|
||||
|
||||
This removes any changed files from the index(staging area), then run:
|
||||
|
||||
```
|
||||
git add .
|
||||
```
|
||||
Commit it:
|
||||
|
||||
```
|
||||
git commit -m ".gitignore is now working"
|
||||
```
|
||||
|
||||
To undo ```git rm --cached filename```, use ```git add filename```
|
||||
|
||||
@@ -1,53 +1,75 @@
|
||||
# WHY USING BRANCHES DURING CONTRIBUTING
|
||||
## Why Use Branches When Contributing?
|
||||
Git branches are an essential tool for collaboration in software development. They allow multiple developers to work on different features or bug fixes simultaneously without interfering with the main project code. By using branches, you can experiment freely, test new ideas, and merge only the best changes into the main project.
|
||||
|
||||
## What are branches.
|
||||
## What Are Branches?
|
||||
A **branch** in Git is essentially a separate line of development. It allows you to create an isolated version of the project where you can make changes without affecting the main codebase. When you're ready, you can merge your branch back into the main project.
|
||||
|
||||
Branches are simply pointers to a commit.
|
||||
### How Branches Work
|
||||
Every branch is just a pointer to a specific commit in the project history. When you create a new branch, Git duplicates the state of the current branch, allowing you to work independently. New commits are added to this branch's history without affecting the main branch.
|
||||
|
||||
When you branch out, git is essentially making a new state of your current code, upon which you can work, without affecting the important main state of the code (which is in master branch).
|
||||
- To switch between branches, use `git checkout`.
|
||||
- To combine changes from one branch into another, use `git merge`.
|
||||
|
||||
When you are happy with your experiments, and want to merge you experiments in main code, you run git merge
|
||||
<branch name> master.
|
||||
This will tell git, to add in all changes from your experiment branch into master.
|
||||
## Why Use Branches?
|
||||
Branches make collaboration **structured and efficient**. Without them, all changes would be made directly to the main project, leading to confusion, errors, and conflicting code.
|
||||
|
||||
This way, while working in an open source project with a number of contributors, it becomes easy to merge the best suited code without altering the main code or master branch.
|
||||
### Example: The Car Paint Job Analogy
|
||||
Imagine a car manufacturing team deciding on the default color for a new car model. Initially, the car is set to be **olive green**. However, a few team members want to see how it looks in **red**.
|
||||
|
||||
## How it works?
|
||||
- Instead of repainting the original car, they create a **prototype** with red paint.
|
||||
- If the red color is approved, it replaces the original color (i.e., the branch is merged into the main project).
|
||||
- If the red color is rejected, the prototype is discarded (i.e., the branch is deleted).
|
||||
|
||||
A branch represents an independent line of development. Branches serve as an abstraction for the edit/stage/commit process. You can think of them as a way to request a brand new working directory, staging area, and project history. New commits are recorded in the history for the current branch, which results in a fork in the history of the project.
|
||||
Similarly, in Git, branches allow developers to test new features without directly modifying the main codebase.
|
||||
|
||||
The git branch command lets you create, list, rename, and delete branches. It doesn’t let you switch between branches or put a forked history back together again. For this reason, git branch is tightly integrated with the git checkout and git merge commands.
|
||||
## Feature Branching
|
||||
Instead of having one branch per developer, it's better to create **one branch per feature**. This keeps things organized and prevents unnecessary conflicts.
|
||||
|
||||
## Why to use branches?
|
||||
### Example: Alice & Bob's Feature Development
|
||||
- **Alice** is working on **Feature A** and makes several commits.
|
||||
- She then switches to **Feature C** and makes more commits.
|
||||
- Meanwhile, **Bob** finishes **Feature B** and wants to start working on **Feature A**.
|
||||
- Bob pulls in Alice’s branch, but now his branch contains **Feature A, Feature B, and some incomplete parts of Feature C**.
|
||||
- When he tries to merge his branch, he faces conflicts because Feature C is unfinished.
|
||||
|
||||
If the question "Why do we use branching in version control like git?" still persists in your mind, here's a quick explanation:
|
||||
To avoid this:
|
||||
- Alice should have separate branches for **Feature A** and **Feature C**.
|
||||
- Bob should have separate branches for **Feature B** and **Feature A**.
|
||||
|
||||
Let's take a simple example to understand the branching strategy. A production car needs a paint job before its launch. Prior to its official sale, it was decided that the car would come in 'olive green' color as default. But some of the members in the manufacturing team decided to showcase the car in 'red' color. Hence an ambiguous situation arises and to avoid this problem branching was introduced.The red color paint job is like a branch to the master repository 'Car'. Pushing this branch will suggest the red color. If merged with the master repository the car will get the red color otherwise it will continue with olive green. Merging a contributors branch to the master repo of the organization depends on the project head.
|
||||
This way, they can work without interfering with each other's progress.
|
||||
|
||||
## Example
|
||||
|
||||
Alice is working on Feature A and Bob is working on Feature B. Alice is halfway done with Feature A and has made a few commits in alice. However, Feature A is quite hard to implement so Alice decides that she should rather work on Feature C and makes a few commits onto alice. Bob finished Feature B and decides that he would like to tackle Feature A and so pulls alice into bob.
|
||||
|
||||
After Bob finishes Feature A he would like to merge bob into master. However, bob now contains Feature A, Feature B and parts of Feature C, but Feature C is not ready to be merged! It's easy to see that a workflow like this can lead to many confusing merge conflicts.
|
||||
|
||||
The trick is that instead of having personal branches one should have feature branches. Alice should have a branch for Feature A and Feature C and Bob should have a branch for Feature B and Feature A. That way they both can work on different features without tramping on each other's toes.
|
||||
|
||||
## How to create branches?
|
||||
|
||||
#### Create a branch
|
||||
## Creating and Managing Branches
|
||||
|
||||
### Create a New Branch
|
||||
```sh
|
||||
git branch my-new-branch
|
||||
```
|
||||
git branch AnyBranchName
|
||||
This creates a new branch named `my-new-branch` without switching to it.
|
||||
|
||||
### Switch to a Branch
|
||||
```sh
|
||||
git checkout my-new-branch
|
||||
```
|
||||
This moves you to `my-new-branch`, allowing you to work on it.
|
||||
|
||||
A new branch will be created named AnyBranchName and all the file changes in this branch will not be affected in the main branch.
|
||||
For detailed explanation refer [How to create branch](https://www.atlassian.com/git/tutorials/using-branches)
|
||||
|
||||
#### Delete the branch
|
||||
|
||||
```
|
||||
git branch -d AnyBranchName
|
||||
### Create and Switch to a Branch (Shortcut)
|
||||
```sh
|
||||
git checkout -b my-new-branch
|
||||
```
|
||||
This creates and switches to the new branch in a single step.
|
||||
|
||||
Branch name AnyBranchName will be deleted from the git repository.
|
||||
Refer to [Removing branch from your repository](https://github.com/jashnimje/first-contributions/blob/7dcae72208e4b42fcf834b4f189fa8ee78238077/additional-material/git_workflow_scenarios/removing-branch-from-your-repository.md)
|
||||
### Delete a Branch (After Merging)
|
||||
```sh
|
||||
git branch -d my-new-branch
|
||||
```
|
||||
This removes `my-new-branch` if it has already been merged.
|
||||
|
||||
### Force Delete a Branch (Without Merging)
|
||||
```sh
|
||||
git branch -D my-new-branch
|
||||
```
|
||||
Use this with caution! It deletes the branch even if it has unmerged changes.
|
||||
|
||||
## Additional Resources
|
||||
- [Git Branching Guide (Atlassian)](https://www.atlassian.com/git/tutorials/using-branches)
|
||||
- [Removing a Branch from Your Repository](https://github.com/jashnimje/first-contributions/blob/7dcae72208e4b42fcf834b4f189fa8ee78238077/additional-material/git_workflow_scenarios/removing-branch-from-your-repository.md)
|
||||
|
||||
@@ -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 আপডেট করে এটি ঠিক করতে পারেন।
|
||||
Reference in New Issue
Block a user