Create wiki page to guide developers how to remove unwanted files during the Pull Request process

[roslynwythe]

Overview

We need to write a wiki page providing guidance for developers who learn during a pull review that they have included changes to files that were not pertinent to the issue so that the reviewer can simply link to that page.

Action Items

• [ ] We are currently in the process of moving the old wiki to the new website-wiki repo, so we will not be making any changes or additions to the old wiki at this time. Thus, we will be adding wiki content through a different process now. Read How to Contribute to the Wiki
• [ ] Describe common scenarios that can cause unwanted commits to appear in a pull request, for example:
  • [ ] If an issue branch is created while a previous issue branch is checked out, the new issue branch will contain extraneous commits
  • [ ] If some file changes were not committed in a branch, those changes can persist and will be included in a commit if a developer runs git add --all or git add ..
• [ ] Describe the use of git reset to remove commits and give examples of when to use it
• [ ] Describe the need to use git push --force to push commits after git reset and give examples of when to use it

Resources/Instructions

• https://git-scm.com/doc

[JessicaLucindaCheng]

@roslynwythe I see there is a draft label. I made some edits but it looks good to me now. Was there anything else you wanted to add to this issue?

Edit: It's ready for prioritization.

[github-actions[bot]]

Hi @Brayheart, thank you for taking up this issue! Hfla appreciates you :)

Do let fellow developers know about your:- i. Availability: (When are you available to work on the issue/answer questions other programmers might have about your issue?) ii. ETA: (When do you expect this issue to be completed?)

You're awesome!

P.S. - You may not take up another issue until this issue gets merged (or closed). Thanks again :)

[Brayheart]

Availability:: I can work on this Monday/Wednesday/Friday in the afternnons. ETA: End of next week, March 22nd.

[Brayheart]

Git Command Quick Reference

Before we address specific scenarios of unwanted commits in pull requests, let's understand some important Git commands and their use cases.

git add --all and git add .

Use Case:

These commands add changes from all tracked and untracked files in the repository (git add --all) or add changes from the current directory and all subdirectories (git add .).

Important Note:

Be cautious when using these commands as they can add unwanted files to your commit. Always review which files are being added using git status.

git reset

Use Case:

This command is used to undo changes by un-staging files (git reset), moving back to a previous commit and discarding changes in the working directory (git reset --hard commit-hash), or moving back to a previous commit while keeping the changes in the working directory (git reset --soft commit-hash).

Examples:

• git reset removes all files from the staging area.
• git reset file.txt un-stages a specific file.
• git reset commit-hash reverts the repo to the state of the specified commit.
• For a broader rollback, git reset --hard HEAD~2 will revert the repository to the state of two commits ago, discarding all changes in the working directory introduced by the last two commits.

git push --force

Use Case:

After using git reset, you might need to update the remote repository with your local history, which could require a force push.

Important Note:

Use this command with caution as it can overwrite history on the remote. It is best used in personal branches or when you're certain no one else is working on the branch.

Examples:

• git push origin branch-name --force forcefully updates the remote branch with your local branch.

Now, let's move on to handling specific unwanted commit scenarios.

Handling Unwanted Commits in Pull Requests

When working with version control systems like Git, it's not uncommon to encounter situations where unwanted commits appear in a pull request. Below are some common scenarios and the steps to handle them.

Accidental Commit on the Wrong Branch

Problem:

Commits meant for one branch are mistakenly made on another branch.

Solution:

1. Identify the commit hash using git log.
2. Switch to the correct branch using git checkout correct-branch.
3. Cherry-pick the commit to the correct branch with git cherry-pick commit-hash.
4. Remove the commit from the wrong branch using git reset --hard HEAD~1 or git revert commit-hash.

Unintentional Inclusion of Local Configuration Files

Problem:

Local configuration files are committed to the repository by mistake.

Solution:

1. Add the file to .gitignore to prevent future issues.
2. Remove the file from the repository with git rm --cached filename.
3. Commit the removal and .gitignore update.

Inclusion of Work-in-Progress (WIP) Commits

Problem:

WIP commits are included in a pull request before they are ready.

Solution:

1. Use git reset to unstage commits and work on them further.
2. Once ready, commit the changes with a proper message.

Merge Commits After Pulling from the Main Branch

Problem:

A rebase operation may cause commits from other branches to appear in the pull request. This can happen if the rebase is done against an incorrect base branch or if there is a mistake while resolving merge conflicts.

Solution:

1. Use git rebase --abort to cancel the rebase if you encounter problems.
2. Carefully review the rebase plan with git rebase -i. This interactive mode allows you to curate and modify the sequence of commits that will be reapplied on top of the branch you are rebasing onto.

Rebase Gone Wrong

Problem:

A rebase operation causes commits from other branches to appear in the pull request.

Solution:

1. Use git rebase --abort to stop the rebase if issues arise.
2. Carefully review the rebase plan with git rebase -i before proceeding.

Committing Generated Files

Problem:

Generated files are accidentally added to commits.

Solution:

1. Add patterns for generated files to .gitignore.
2. Use git clean -f to remove untracked files from the working directory.

By being vigilant and using these strategies, you can avoid including unwanted commits in your pull requests.

[ExperimentsInHonesty]

@Brayheart I am moving this issue to the in progress column. In future, please move the issue you have self-assigned to that column.

[ExperimentsInHonesty]

@Brayheart checking in on you. Its been two weeks since you commented on this issue. If you need a review by the dev leads, please move it to the questions column, and add ready for dev lead, with a note saying you are done and need a review.

[Brayheart]

Hi @ExperimentsInHonesty,

I've added the "How to remove unwanted files during the Pull Request process" link to the wiki page to assist developers with their pull requests. Could you review the addition and let me know if it meets the project’s needs? Also, is there anything more I need to do on my end to close out this ticket?

Thanks!

[github-actions[bot]]

@Brayheart

Please add update using the below template (even if you have a pull request). Afterwards, remove the 'To Update !' label and add the 'Status: Updated' label.

1. Progress: "What is the current status of your project? What have you completed and what is left to do?"
2. Blockers: "Difficulties or errors encountered."
3. Availability: "How much time will you have this week to work on this issue?"
4. ETA: "When do you expect this issue to be completed?"
5. Pictures (optional): "Add any pictures of the visual changes made to the site so far."

If you need help, be sure to either: 1) place your issue in the Questions/In Review column of the Project Board and ask for help at your next meeting, 2) put a "Status: Help Wanted" label on your issue and pull request, or 3) put up a request for assistance on the #hfla-site channel. Please note that including your questions in the issue comments- along with screenshots, if applicable- will help us to help you. Here and here are examples of well-formed questions.

_{You are receiving this comment because your last comment was before Tuesday, April 9, 2024 at 12:06 AM PST.}

[Brayheart]

Just commenting, as far as I understand this issue is resolved, just need guidance on how to resolve this issue!

[drakenguyen4000]

@Brayheart It looks like you just marked it off correctly. Just mention that you need review.

[roslynwythe]

@Brayheart this is well written and covers all the necessary points. I have two comments:

• under git reset, please include an example such as git reset --hard HEAD~2 with explanation
• regarding "rebase gone wrong", I'm just wondering, what would be a scenario in which this could happen?

When you reply, please add ready for dev lead label and put it back into the questions column. Thanks

[roslynwythe]

Thank you @Brayheart for providing a great resource for new developers.