11. VCS - Git¶

11.2.1. Syncing the github fork with upstream¶

1. Clean up:

   git stash
   git checkout master # -f
   

2. Update upstream:

   git fetch upstream
   

3. Merge upstream:

   git merge upstream/master
   

4. Get current work:

   git stash pop / apply
   git stash clear # if anything left on stash
   

11.2.2. Cloning a github fork¶

git clone git@github.com:wolfmanx/REPOSITORY.git

11.2.3. Adding an upstream repository¶

git remote add upstream https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git

Example:

sheckley:.../3rd-party/w2ui/w2ui$ git remote -v
origin      git@github.com:wolfmanx/w2ui.git (fetch)
origin      git@github.com:wolfmanx/w2ui.git (push)
upstream    https://github.com/vitmalina/w2ui.git (fetch)
upstream    https://github.com/vitmalina/w2ui.git (push)

11.4.1. Find the first commit of a branch¶

git log master..branch --oneline | tail -1

E.g.:

git log master..i18n-default-locale --oneline | tail -1
# 40f5c99 option i18n.notrans for language alias of C locale

git diff 40f5c99~1 i18n-default-locale >tg2-i18n-notrans.patch

11.4.2. Delete commits¶

See git rebase - Delete commits from a branch in Git - Stack Overflow

Assuming you are sitting on that commit, then this command will wack it…

git reset --hard HEAD~1

The HEAD~1 means the commit before head.

Or, you could look at the output of git log, find the commit id of the commit you want to back up to, and then do this:

git reset --hard <sha1-commit-id>

If you already pushed it, you will need to do a force push to get rid of it…

git push origin HEAD --force

However, if others may have pulled it, then you would be better off starting a new branch. Because when they pull, it will just merge it into their work, and you will get it pushed back up again.

If you already pushed, it may be better to use git revert, to create a “mirror image” commit that will undo the changes. However, both commits will be in the log.

FYI – git reset --hard HEAD is great if you want to get rid of WORK IN PROGRESS. It will reset you back to the most recent commit, and erase all the changes in your working tree and index.

Lastly, if you need to find a commit that you “deleted”, it is typically present in git reflog unless you have garbage collected your repository.

11.4.3. How to modify existing, unpushed commits¶

Best answer on Stack Overflow is: git - How to modify existing, unpushed commits?:

Question:

I wrote the wrong thing in a commit message. Alternatively, I’ve forgotten to include some files.

How can I change the commit message/files? The commit has not been pushed yet.

Amending the most recent commit message

git commit --amend

will open your editor, allowing you to change the commit message of the most recent commit. Additionally, you can set the commit message directly in the command line with:

git commit --amend -m "New commit message"

However, this can make multi-line commit messages or small corrections more cumbersome to enter.

Make sure you don’t have any working copy changes staged before doing this or they will get committed too. (Unstaged changes will not get committed.)

Changing the message of a commit that you’ve already pushed to your remote branch

If you’ve already pushed your commit up to your remote branch, then you’ll need to force push the commit with:

git push <remote> <branch> --force
# Or
git push <remote> <branch> -f

Warning: force-pushing will overwrite the remote branch with the state of your local one. If there are commits on the remote branch that you don’t have in your local branch, you will lose those commits.

Warning: be cautious about amending commits that you have already shared with other people. Amending commits essentially rewrites them to have different SHA IDs, which poses a problem if other people have copies of the old commit that you’ve rewritten. Anyone who has a copy of the old commit will need to synchronize their work with your newly re-written commit, which can sometimes be difficult, so make sure you coordinate with others when attempting to rewrite shared commit history, or just avoid rewriting shared commits altogether.

Use interactive rebase

Another option is to use interactive rebase. This allows you to edit any message you want to update even if it’s not the latest message.

In order to do a git squash, follow these steps:

# X is the number of commits to the last commit you want to be able to edit
git rebase -i HEAD~X

Once you squash your commits - choose the e/r for editing the message

Important note about Interactive rebase

When you use the git rebase -i HEAD~X there can be more than X commits. Git will “collect” all the commits in the last X commits and if there was a merge somewhere in between that range you will see all the commits as well so the outcome will be X+.

Good tip:

If you have to do it for more than a single branch and you might face conflicts when amending the content set up the git rerere and let git resolve those conflicts automatically for you.

11.7.1. Step 3: Configure remotes¶

When a repository is cloned, it has a default remote called origin that points to your fork on GitHub, not the original repository it was forked from. To keep track of the original repository, you need to add another remote named upstream:

cd Spoon-Knife
# Changes the active directory in the prompt to the newly cloned "Spoon-Knife" directory

git remote add upstream https://github.com/octocat/Spoon-Knife.git
# Assigns the original repository to a remote called "upstream"

git fetch upstream
# Pulls in changes not present in your local repository, without modifying your files

More Things You Can Do

You’ve successfully forked a repository, but get a load of these other cool things you can do: Push commits

Once you’ve made some commits to a forked repository and want to push it to your forked project, you do it the same way you would with a regular repository:

git push origin master
# Pushes commits to your remote repository stored on GitHub

Pull in upstream changes

If the original repository you forked your project from gets updated, you can add those updates to your fork by running the following code:

git fetch upstream
# Fetches any new changes from the original repository

git merge upstream/master
# Merges any changes fetched into your working files

What is the difference between fetch and pull?

There are two ways to get commits from a remote repository or branch: git fetch and git pull. While they might seem similar at first, there are distinct differences you should consider.

Pull:

git pull upstream master
# Pulls commits from 'upstream' and stores them in the local repository

When you use git pull, git tries to automatically do your work for you. It is context sensitive, so git will merge any pulled commits into the branch you are currently working in. One thing to keep in mind is that git pull automatically merges the commits without letting you review them first. If you don’t closely manage your branches you may run into frequent conflicts.

Fetch & Merge:

git fetch upstream
# Fetches any new commits from the original repository

git merge upstream/master
# Merges any fetched commits into your working files

When you git fetch, git retrieves any commits from the target remote that you do not have and stores them in your local repository. However, it does not merge them with your current branch. This is particularly useful if you need to keep your repository up to date but are working on something that might break if you update your files. To integrate the commits into your local branch, you use git merge. This combines the specified branches and prompts you if there are any conflicts.