Skip to content

GitHub (GitLab) Workflow Cheat Sheet

Kjell Wooding edited this page May 18, 2021 · 2 revisions

Here are some common tasks in git/github/gitlab. See also Configuring SSH Access to Github and the Git Tutorial.

Note: This cheat sheet assumes you call your primary branch main. As of October 1, 2020, this will be the default for new github prjects. For older repos, replace master wherever you see "main" below.

Wondering how to use git/GitHub/GitLab effectively with easydata?

Here's our suggestion for a reliable git workflow.

Create a standard setup

Walk softly, and carry a personal Fork

First, we strongly recommend work from your own fork. Instructions for doing this are included in the README that shipped with your easydata-based repo.

Swimming Upstream

Next, you should configure your git remotes so that origin refers to your personal github fork, and upstream refers to the source repo. Again, the README tells you how.

Can't see the forest for the branches

To make life easiest, use your main branch only for tracking changes in the upstream repo, and do all your development work in branches. This combination makes it much easier not only to stay up to date with changes the project repo, but also makes it easier to submit Pull Requests (PRs) against the upstream project repo should you want to contribute.

Here's a tip for keeping your branches a little cleaner.

The workflow below includes explicit "--prune" options, which deletes local copies of branches if they have been deleted by either your origin or upstream remote repositories. If you prefer prune deleted branches automatically for a particular repo, configure git like this:

git config remote.upstream.prune true
git config remote.origin.prune true

Add a --global flag to that command to enable this behavior for all your repos. As always, StackOverflow has some more to say on the subject.

Our reliable git workflow

We suggest you start each day by doing this:

Where was I? What was I doing? Did I check it in?

git branch
git status
git add -p   # accept or reject parts of the patch
git commit -m "your commit message here"

Did I do any work elsewhere?

Did you do work on your branch, but on a different machine? Make sure your local branch is up-to-date with your fork:

git checkout main
git fetch origin --prune
git merge origin/main

What happened upstream?

Next, check if the upstream repo has been updated:

git checkout main
git fetch upstream --prune
git merge upstream/main
git push origin main
make update_environment

Update your local branches

Now that your main is up-to-date, you should use it to update your working branches. If you are already developing in a branch called, e.g. my_branch, do this before writing any more code:

git checkout my_branch
git merge main
git push origin my_branch

Create a clean working branch by doing a:

git checkout main
git checkout -b new_branch_name

Clean up, clean up, everybody, everywhere

Finally, clean up any of your old branches that are fully merged.

git branch --merged main
git branch -d {name_of_merged_branch}

This should be enough to get you going!