Git and GitHub Tips

Rejected Pull Request, aka Do not Push Changes You Made on Classmate's Files Scenario In a shared repo, you open and play with a file submitted by classmates. Maybe you opened up their Jupyter Notebook files and ran them. Which is fine! We are sharing code after all, and I want everyone to feel free to try other people's code. But then, if you are not careful, you could end up including these files in your pull requests. Basically: You use the now-forbidden git add * or git add . Classmates' files are then committed and pushed to your fork. You submit your pull request, which was meant as a submission of your own homework file. Then, on my end, I see: Yep, in addition to your todo7_narae.md, your pull request includes 5 extra files, which are the edits you made on your classmates' files! I will then have to reject the request. You will know it because I would have closed the pull request without merging. Prevention First of all, always git-add the files you want by name: git add my_file_name.txt. Do not use * or .. For everything you do in git, there are ways to undo it. Git is a version control system after all! Check out the linked reference page. Important!! You can and should wipe out any changes you made to your classmates' files. From the same git page: git checkout -- classmate_file_you_edited is the magic command! Below, I had made changes to Alicia's file, but I don't want to commit them, so I checked out an earlier version of her file, thereby discarding my changes. After git checkout --, my git status is clean. So, that will be the thing to do -- discard any changes you made on classmates' files, and do not commit them. Remedy But, what if you have already committed those changes? In that case, the best option is to restore the files from UPSTREAM. Meaning, you want to overwrite your local copy with the one from our shared GitHub organization repo. First, make note which files need restoring. If your previous pull request got rejected, see which unintended files were included in your pull request. Next, "fetch" the master branch of upstream. It means downloading the files without actually incorporating ("merging") them into your working directory: git fetch upstream master Then, checkout problem files individually from the fetched upstream copy: git checkout upstream/master -- classmate_file_you_edited Check your status: git status. Depending on where you are, you might need to commit in order to complete the process and get to a clean, settled state. Don't forget to push the changes to your own GitHub fork: git push or git push origin master. Now create a new pull request. While doing so, make sure only your own files are included in the request. If not, close your request and take care of the trouble file. Pull Trouble Scenario You are trying to update your local Class-Practice-Repo by pulling from upstream. But you run into trouble -- git reports MERGE CONFLICTS! What to do? Cause First of all, what's causing this? Simple. You have a changed file locally, which you might or might not have committed, and the file coming from upstream has a different set of changes. Chances are the offending file belongs to someone else: you changed it, but the owner of the file made changes of his/her own. Prevention You should take care not to commit changes you made on someone else's file; discard them instead. See the "prevention" paragraph of the previous section. Remedy Assuming the problem file belongs to someone else, you should discard your local version in favor of the one coming from the upstream repo. That will be our overall strategy. First, you should complete the pulling process, conflicts and all. After this, the problem file will become an amalgam of two conflicting versions. Rather than manually adjudicating it afterwards, we will simply get rid of the file entirely. Throughout the whole process, make note of which file is causing trouble. If it's your own file, or if you want to keep the file for whatever reason, copy it to somewhere outside of the repo for safe keeping. You can copy it back after the dust settles. If you are in the middle of merging (you probably are), you might be presented with commit message windows. Do whatever necessary to get through. Once you are back on the command line, check your status: git status. Git will report on conflicting files. Now, git-delete each of the trouble files: git rm trouble_making_file Check your status again. Commit to finish the merge process. Now you are in a clean state, except you are missing the file locally. Let's restore it from UPSTREAM. First, "fetch" the master branch of upstream. It means downloading the repo files without actually incorporating ("merging") them into your working directory: git fetch upstream master Then, checkout the problem file (or files) individually from the fetched upstream copy: git checkout upstream/master -- file_to_restore Check your status: git status. You will need to commit in order to complete the process and get to a clean, settled state. But one last thing: your own GitHub fork is out of sync. You should update it. Push to your own GitHub fork: git push If it gets rejected citing conflicts, you might have to resort to force-push: git push origin master --force