Git notes

Table of Contents

git_2x.png

Figure 1: from https://xkcd.com/1597/

Tools

Using Git:

Using Git in GitLab:

To receive email notification when a new issue, comment, or new merge requests are generated, change the "Global notification setting" to "Watch" in the pulldown menu (unless your global setting is already to be alerted for changes in any repository) as illustrated in the figure below.

Sorry, your browser does not support SVG.

To receive email notification when changes are pushed to the repository, use the "Email On Push" service accessed through Settings → Integration.

emails_on_push_service.png

Basic operations

  • add: add files to repository
  • commit: store changes
  • push: sync to remote repositories
  • pull: sync from remote repositories
  • merge: merge branches

Magit keybindings

Some help pages: [1] [2] [3] [4] [5]

Working with a single repository

Typical operations.

git add .
git commit -m "message"
git push -u origin master

The commit message might more generally be expounded in an editor.

Single line summary

Detailed text...

Undo last commit. Refs [1] [2] [3]. To just undo last commit:

git reset --soft HEAD~1

To roll back to previous commit in local repo (i.e., change files back):

git reset --hard HEAD~1

After making the necessary changes, use git add and git commit. If the last changes were already pushed to the remote server:

git push origin master --force

Note that the master branch may be protected in GitLab - you will get a error:

remote: GitLab: You are not allowed to force push code to a protected branch on this project.
(pre-receive hook declined GitLab: You don't have permission)

You will need to go to Settings –> Repository –> Protected Branches and unprotect it.

Branches

Use branches to develop new features or to contain development work separate from the main (master) branch.

Create new branch.

git checkout -b {dev}

View branches.

git branch -a

First merge in development branch {dev} to check for conflicts, and then merge into master. Ref [1].

git checkout {dev} # switches to branch
git merge master
# >>> resolve any merge conflicts if there are any <<<
git checkout master
git merge {dev}

See also git --theirs.

Working with group repositories

To maintain projects in group repositories (https://gitlab.com/aprl) together with your own, there are two strategies:

The last instance is illustrated in the following sections. (Only pushing to two repositories can be specified.) GitLab provides a mechanism to set up project pages in "public/", which requires you to push to both repositories (GitLab runner does not deploy if a project is only mirrored).

Setup description

Example: two repositories, {user} and aprl.

Setting up the repository

Instructions taken from refs [1] [2] [3].

Use {project} as an example. First, set repository of the origin (this is often done already during setup):

git remote set-url origin git@gitlab.com:{user}/{project}.git

Add repo to push to (normally, start here):

git remote set-url origin --add git@gitlab.com:aprl/{project}.git

Add repo to pull from:

git remote add aprl git@gitlab.com:aprl/{project}.git

Inspect

git remote -v

Merge group changes in aprl to {user} repository

Fetch + merge is preferred over pull, but fetch will not create local branches tracking remote branches. Therefore, pull may be preferred in these cases.

git fetch --all
git pull --all

Inspect

git branch -a

Simple case. Merge changes from aprl to {user} master branch.

git checkout master
git merge remotes/aprl/master

General case. Store changes from aprl to {tmp} and merge {user} master there to check for errors, then merge these changes back to {user} master.

git checkout remotes/aprl/master
git checkout -b {tmp}
git merge master
# >>> resolve conflicts <<<
git checkout master
git merge {tmp}

Push

git push -vu origin master

Pull/fetch (pull merges; fetch does not):

git fetch --all

Tagging

Tag major releases. (E.g., associated with manuscript submission or post-revision.)


Generated by Org-mode 9.2.3 with Emacs 26