Intro to git 2

git show (information about a commit)

  • git show 60b26f9
  • git show 60b26f964d541f9bf223a760dac3c80f869e989e
  • git show 0.1
  • git show bugfix58

git diff

between working directory (HEAD) and another commit:

  • git diff 60b26f9
  • git diff HEAD^
  • git diff

between two commits

  • git diff HEAD^ HEAD
  • git diff v0.1 v0.2
  • git diff v0.2 bugfix58

relative commits:

parent commits with ^

  • HEAD^
  • main^
  • v0.1^
  • 60b26f9^

A few parents down a given commit

  • HEAD~2
  • main~3
  • v0.2~2
  • 60b26f9~4

git reset: undo a commit

Moves both HEAD and the current branch back to the previous commit tip

The modifications from that reset-ed commit may be left as modifications in the working directory after HEAD is moved onto the parent commit, depending on

  • git reset --mixed (default)
  • git reset --hard
  • git reset --soft

git restore some_work.py

restore removes modifications in the working directory

git status suggests how to do restore

git restore –staged some_work.py

restore removes modifications from the staging area

git status suggests how to do restore

git cherry-pick

Each commit gives defines file modifications, insertions/deletions (“patch”), between itself and the parent commit

Cherry-pick applies this modification on top a different parent commit

For instance, if branch bugfix59 fixed two bugs in two different commits, we can “cherry-pick” the commit that fixes only one of the bugs and apply it onto the current branch.

git revert

Git revert computes the reverse of a commit, and creates a new commit to apply this reversion on top of the commit where HEAD currently is

Example: a bug was inserted with a commit long time ago. We have released several versions since then, we now wish to create a new commit that reverses the insertion of the bug.

Cherry-picks the reverse of a past commit, applies the reverse modifications in a new commit

git rebase

rebase is an alternative to merge, to avoid merge commits and instead maintain a linear history

Images: credits to https://git-scm.com/book/en/v2/Git-Branching-Rebasing

initial state

git checkout master; git merge experiment

git checkout master
git merge experiment

git checkout experiment; git rebase master

$ git checkout experiment
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: added staged command

git checkout master; git merge experiment

$ git checkout master
$ git merge experiment # now a fast-forward merge!

Thanks to the fast-forward merge, we have now a simple linear history

Remote repositories:

Remote repositories are distinct git repositories that share some commit history

Remote repositories also have

  • commits,
  • branches,
  • tags

Example workflow

  • A central github repository contains the latest company-wide release (“main branch”)
  • Developers have their own repository on their laptops, with some shared history with the central repo

To merge her code (on laptop) onto the main repository,

  • the developer obtains the latest history (main branch) by doing git pull origin main:main
  • merges her work onto main on her laptop
  • push the main branch (with her modifications) back to the central repository:
    git push origin main:main

Pull-request

  • A central github repository contains the latest company-wide release (“main branch”)
  • Developers have their own repository on their laptops, with some shared history with the central repo

Alternatively, the developer

  • sends her code to the central repository in a specific branch (say, feature5),
    ``git push origin feature5:feature5
  • opens a pull-request on github to propose merging feature5 onto main,
  • invites company developers can discuss the pull-request, see file changes, comments in the github website
  • merges feature5 onto main directly on github after everyone agrees

Email from company CTO

Dear Alice and Bob,

Thanks for your work on your laptop on feature4 and bugfix58.

  1. In the meantime, our main branch on the central github repository has integrated changes from Caroline. Please pull these new changes and rebase your work; when done, please open a pull-request on github so we can review and merge your work.

  2. You will find some work by Jerry on the github repo in branch doomed. This leads nowhere so we will throw away most of the code in that branch. We only need the modifications in the commit Quickfix to be integrated in our main branch. Please cherry-pick that commit (only this one) from Jerry’s doomed branch, and create a new quickfix branch with corresponding pull-request on github.