Collaboration

Forking

Forking a repository is creating a copy of another user's repository in your GitHub account. This is useful when you want to contribute to a project but don't have direct access to push changes.

Why Use Forking?

• You can freely experiment with changes without affecting the original repository.
• It allows contributors to work on a project without needing permission.
• You can send pull requests to the original repository when your changes are ready.

Pull Request

A Pull Request (PR) is a way to propose changes to a repository. It allows developers to collaborate, review, and discuss code changes before merging them into the main project.

Steps

1. Fork the Repository.
2. Clone the Forked Repository
3. Add the original repository as an upstream remote (to fetch updates from the original repo)
4. Create a New Branch
5. Make Changes & Commit
6. Push Changes to New Branch
7. Visit your Forked Repository
8. You'll see a message about your newly pushed branch. Click "Compare & pull request."
9. Select the base branch (usually main or develop) and your feature branch.
10. Provide a title and description of the changes.
11. Click "Create pull request."

Review PR

1. Navigate to the repository, click on the Pull Requests tab and select the PR you want to review.
2. Read the title and description, under stand the purpose.
3. Click on the File changed tab and examine the modifications.
4. Approve or Request Changes
   • If the code is good, click "Approve" and submit the review.
   • If the code needs fixes, click "Request changes" and explain what should be improved.
   • If unsure, click "Comment" to start a discussion.
5. Merge the PR
   1. Click "Merge pull request".
   2. Choose between:
      • Merge commit (keeps all commits).
      • Squash and merge (combines commits into one).
      • Rebase and merge (applies commits individually).

Squashing commits

Squashing commits means combining multiple commits into a single commit before merging a pull request (PR). This helps keep the commit history clean, making it easier to track changes and understand the project's development.

Why Squash Commits?

1. Clean Git History – A single commit per PR keeps the history simple and easier to read.
2. Removes Unnecessary Commits – Intermediate commits like "fixed typo" or "debugging" are removed.
3. Easier Reverts – If something goes wrong, reverting a single commit is simpler than dealing with multiple commits.
4. Better Collaboration – Other developers can easily review a single meaningful commit rather than a list of small commits.

How to work

1. Explore the commit with git log --oneline

   abc1234 Fixed typo
   def5678 Updated feature file
   ghi9012 Initial commit for new feature

2. Squash Commits Using Interactive Rebase

   Before merging the PR, squash commits using interactive rebase

   git rebase -i HEAD~3

   This opens an interactive editor with something like:

   pick ghi9012 Initial commit for new feature
   pick def5678 Updated feature file
   pick abc1234 Fixed typo

   Change pick to squash (s) for the second and third commits:

   pick ghi9012 Initial commit for new feature
   squash def5678 Updated feature file
   squash abc1234 Fixed typo

   Save and close the editor. Git will prompt you to edit the commit message. You can keep only the essential part, like:

   Added new feature with updates and typo fixes

3. Push the Squashed Commit

   After squashing, force-push the changes:

   git push origin feature-branch --force