Pinned Loading

1. Good practices for version control w... Good practices for version control with Git

   1

   # Ten good practices for version control with Git

   2

   1. **SYNC FIRST** Always check whether there's already an update to the branch you're working on, ideally as often as possible, but definitely before you push. You can inspect changes to all checked out branches with `git remote update`, and then compare commit logs with `git log $local..$remote`, for e.g.  `git log dev..origin/dev` (it shows what commits remote has that local doesn't). If required, compare actual changes with git `diff $local..$remote` (it shows how remote differs from local).

   3

   2. **VERIFY REMOTE(S)** Make sure you're using the right remote. Note that `origin` is only the de facto name of the first or only _tracked_ remote, and it might've been set to something else, which you can check with `git remote -v`. Sometimes local and remote branches may be named differently, but only when you chose to do this at the time of the first push, where `git push -u $tracked-remote $branch` established which remote to track for a local, and where `$branch` may have been a different name from the local you were pushing from. Normally you won't choose to do this, but can happen if you mistyped something.

   4

   3. **DON'T PULL BLIND** Never pull before checking if there's an update on your branch, otherwise Git will do a merge commit of changes from remote into your local, and you will end up pushing these unwanted merges. I've observed this happening often, and it makes reviewing code history difficult sometimes. You can `git add .` and `git stash` ALL of your work before pulling, and then `git stash pop` to re-apply, before a `git pull`. You may have to resolve any conflicts that arise. The less parameters here the better, so always check out the branch you want to pull into first, and don't specify any remote/origin when pulling, assuming the branch names are the same.

   5

   4. **REBASE ON PULL** A safe habit to get into is using `git pull --rebase` instead of just `git pull`, which will apply your work on top of the remote automatically. Here too you'll have to resolve any conflicts that arise. If you've made a lot of changes, it's better to switch to another (feature) branch, keep the working branch up-to-date, and merge changes from it into your feature branch later on, when you'll have time to resolve any conflicts.

2. meaningfy-ws/rdf-differ-ws meaningfy-ws/rdf-differ-ws Public

   Configurable change reporting for RDF vocabularies

   HTML 7

3. OP-TED/ted-rdf-mapping-eforms OP-TED/ted-rdf-mapping-eforms Public

   TED-RDF Mapping Suites for eForms Notices

   Makefile 1

4. meaningfy-ws/semic-styleguide-rdf-validator meaningfy-ws/semic-styleguide-rdf-validator Public

   SEMIC Style Guide RDF Validator

   Python 1