how to make multiple pr for multiple issues that are presented in an similar project in an org

[Harish-2003]

i have made an pull request to an organization and i want to make again an pull request for the other issue so someone said that i can able to make another pull request by creating an new branch in my forked repo but i have a doubt that, during my creation of second pr my previous pull request is not merged , and after sometime what if both pull request were accepted by the orgs like is it okay doesn't the project have merge conflicts are something like that?

[Princegupta101]

@Harish-2003
If your first pull request hasn't been merged yet and you want to work on another issue, you can create a new branch in your forked repository, make the necessary changes for the new issue, and then create a new pull request from that branch.

If both pull requests modify the same files or lines of code, there might be merge conflicts when one of them gets merged before the other. In such cases, the project maintainers will usually resolve the conflicts during the review process. You can help minimize conflicts by keeping your pull requests focused on specific changes and regularly updating your branches with changes from the main repository.

If you encounter any merge conflicts or have concerns about how to proceed with multiple pull requests, you can always communicate with the project maintainers to coordinate and resolve any issues.

[Harish-2003]

what if the changes made on different files?

[Princegupta101]

If the changes made in your different pull requests are on different files, it significantly reduces the likelihood of merge conflicts. When changes are made to separate files, they can usually be merged without conflicts, as Git is designed to handle concurrent changes to different parts of the codebase efficiently.

[Harish-2003]

thanks for the information bro @Princegupta101

[Ojas-Arora]

Creating multiple pull requests for multiple issues in a project is a common scenario, especially in larger projects or during events like GSSOC. Here's a step-by-step guide on how to handle it:

1. Create a New Branch for Each Issue:

   • Start by creating a new branch in your forked repository for each issue you want to address. This ensures that changes for each issue are isolated.

   • You can create a new branch using the following command:

     git checkout -b new-branch-name

2. Make Changes for the New Issue:

   • Make the necessary changes in this branch to address the new issue. Commit your changes regularly as you work on it.

3. Push the Branch to Your Fork:

   • Once you've made the changes and committed them, push the new branch to your forked repository:

     git push origin new-branch-name

4. Create a New Pull Request:

   • Go to the repository on GitHub and create a new pull request from your newly pushed branch.
   • Make sure to reference the new issue in the pull request description for clarity.

5. Repeat for Each Issue:

   • Repeat the process for each issue you want to address, creating a new branch, making changes, pushing the branch, and creating a new pull request.

Regarding your concern about potential conflicts if both pull requests are accepted:

• If your first pull request hasn't been merged yet and you make changes in a new branch for another issue, there shouldn't be any conflict as long as the changes in your new branch don't overlap with the changes in the first pull request.

• If there are changes in the main repository that conflict with your first pull request while you're working on the second issue, you might need to update your first branch to resolve conflicts before merging it. You can do this by pulling changes from the main repository into your branch:

  git checkout first-branch-name
  git pull upstream main

  Resolve any conflicts and push the changes back to your fork.

• Similarly, if there are conflicts with your second pull request, you would resolve them in the same way, by updating your second branch with the latest changes from the main repository.

By following these steps and keeping each issue's changes isolated in separate branches, you should be able to manage multiple pull requests effectively without running into conflicts.