13  Miscellaneous

This section contains miscellaneous troubleshooting information that does not have a natural home elsewhere, at the moment.

13.1 Partial Push

Sometimes you make a lot of commits locally that you haven’t pushed to the remote. If this happens, occasionally, you may want to push only a subset of the commits to the remote. This could be because you’re not sure that all of the commits are complete enough to be shared, and you may want to edit them later on. It could also be that you tried a regular push, but it failed, and pushing only a subset of the commits is a way to troubleshoot the problem.

git push origin commit-id:branch-name

13.2 Forking/Duplicating Your Own Repository

It’s not possible to fork your own repository on GitHub. However, you can create a copy of it. The steps are as follows:

  • Create a new repository on GitHub.
  • Clone your original repository to your local machine.
  • Add the new repository as a remote (origin).
  • Add the old repository as the upstream (i.e. the origin of the material)
    • This allows you to track changes to the original repository, and pull them into your new repository.
  • Push the local copy of the new repository to the new remote.
  • Check for other branches in the original repository
    • Checkout each branch in turn
    • Push each branch to the new remote
    • Repeat for all branches
git clone git@github.com:arnold-c/psu-intro-to-git.git psu-intro-to-git-copy
cd psu-intro-to-git-copy
git remote set-url origin git@github.com:arnold-c/psu-intro-to-git-copy.git
git remote add upstream git@github.com:arnold-c/psu-intro-to-git.git
git push -u origin main
git branch -a # list all branches in the original (remote) repository
# git checkout other-branch-name
# git push -u origin other-branch-name

13.3 Deleting Files from Git History

Occasionally you will make a commit that includes a file you didn’t mean to e.g., a .env file that contains API keys or secrets. If you realize your mistake before you’ve pushed to the repository, then it’s a generally a pretty easy fix, though how easy depends on if you have made any commits since the bad commit.

13.3.1 Most Recent (Local) Commit

Important

This approach assumes that the addition of the file is only thing that happens in the commit. If this is not true, follow the interactive rebase workflow laid out in the next section

Simply reset the HEAD to the previous comment.

git reset --<type> HEAD~1 #note the tilde, not hyphen

Here <type> should be replaced by one of soft, mixed, or hard, depending on whether you would to keep the changes in the commit. Note that you can replace HEAD~1 (which points to the commit 1 before the HEAD, or the most recent commit position) with a SHA-1 commit hash (shown in git log --oneline) See this excellent documentation by Atlassian on the various methods you can use to reset the working tree, as well as a visual description to help gain an understanding of the way Git handles these requests. You probably want to use --mixed (the default, in case you forget to added the type to the git reset command) as you added the secrets to your project for a reason.

You will then want to add the file to your .gitignore file so Git doesn’t track it in the future.

13.3.2 A Few (Local) Commits Deep

If, however, you have made a number of changes and commits between accidentally including a file in a commit and when you notice your mistake, you can use an interactive rebase. An interactive rebase allows you to go back to a specific commit and then replay them in sequence, as well as making modifications to specific commits as you wish. We will use it to go back to the troublesome commit that includes our file erroneously, remove the file from the commit, and then continue onwards.

git rebase -i 2967e6d #You could also use HEAD~4 to show the HEAD and 3 prior commits

This will provide you with a list of commits between the commit you are choosing as your starting point (the troublesome one) and the HEAD.

pick 2967e6d # Render after making collaboration changes -- HEAD~3
pick c40f66d # Add description of merge collaborations -- HEAD~2
pick 6dc271f # Add todos and delete old merge conflict page -- HEAD~1
pick 1b3ab13 # Add description of git reset to misc -- HEAD

Then you will want to change one of the pick to edit i.e., the first one in the list if probably the one with the problematic file commit.

edit 2967e6d # Render after making collaboration changes -- HEAD~3
pick c40f66d # Add description of merge collaborations -- HEAD~2
pick 6dc271f # Add todos and delete old merge conflict page -- HEAD~1
pick 1b3ab13 # Add description of git reset to misc -- HEAD

Saving this will put you back into the terminal and start the rebase. You can then use git rm <file> to delete the file from the git history.

Then to replay the next, OK, commits using the following commands

git commit --amend --no-edit  # Update the commit without changing the message
git rebase --continue         # Move to the next commit

You will then probably want to add that file into the .gitignore to prevent accidentally tracking it in the future.

If you want to see a visual description of the interactive rebase, see this article by Atlassian.

Note

You could also use git cherry-pick to move the problematic commit to the HEAD and then follow the instructions above to apply git reset. This has the same assumptions surrounding the lack of other files being involved in the commit, and that no later commits also include that file. Read more about how cherry-pick works here

13.3.3 Commits That Have Been Pushed

If, unfortunately, you only notice the mistake after you have already pushed the file to your remote, you will need to do some destructive actions. This will require you notifying your colleagues as they will need to fetch the updates you make so you are all working on a common version of the code, and potentially dealing with merge conflicts introduced.

There are 4 main ways this can be done:

  1. An interactive rebase, as described above followed by git push --force to overwrite the remote history
  2. git filter-branch
  3. bfg
  4. [git filter-repo]

We are going to use bfg as it’s quicker for larger files, and simpler, so you (and I) are less likely to mess up irrevocably.