Git is a popular version control system.

# Tricks

# Writing a Git Commit Message

[Article Reference](https://chris.beams.io/posts/git-commit/)

- Concise and consistent length and form
- Communicate clear context about a change to fellow developers. Ensure
  that other developers understand **why** a change was made.

## Rules

- Separate subject from body with a blank line if the body is to be
  used.
- Limit subject line to 50 characters
- Capitalize subject line
- Do not end with period
- Use imperative mood; I 'do' this. Rationale: If applied, the commit
  will change these aspects of the code. Git's own built-in conventions
  use this form.
- Wrap at 72 characters
- Use the body to explain 'what' and 'why' as necessary

# Organization Thoughts

github organization:

- one repo per course - as most courses require partner work

= repo for coding challenge practice problems

- managing research notes: ??? i am thinking a single org file for all
  of this
- \- that is, an org file in each project for the research notes
  pertaining to that project,
- \- and anotherorg file for misc. research ?? i will have to see how my
  research is used

<https://danieltakeshi.github.io/2017/07/15/how-i-organize-my-github-repositories/>

# Rewriting

It's a good idea to reformat commits to make them more readable.

``` bash
git reset HEAD~${number of commits to go back}
```

# Tricks

<http://joeyh.name/blog/entry/how_to_publish_git_repos_that_cannot_be_republished_to_github/>
:: cheeky way to abuse DMCA to avoid GitHub using your Git repos
<https://sourcehut.org/blog/2020-10-29-how-mailing-lists-prevent-censorship/>
using the mailing list model over the built-in issue model, and how this
naturally federated and local first procedure is superior to github's
standard issue approach <https://sagegerard.com/git-debugging.html>: use
git bisect while referencing maintainers of specific parts of code to
narrow down to the code you should care about, then ask the maintainers
about it - while putting in a minimum of effort.
<https://labs.consol.de/development/git/2017/02/22/gitignore.html> using
.gitignore the right way

## Patch previous commits with rebases

<https://stackoverflow.com/questions/9103396/how-do-i-edit-a-previous-git-commit>
If you need to change commit history:

- Make another commit to make the change
- Rebase starting at the commit you want to change
- Squash the new commit with the old one in the history
- Remove the second commit message (or merge it…)

This did change the commit time for my latest commit, which is something
to watch out for.

# How Git Works

[Neat writeup on the Git patience diff
algorithm](https://blog.jcoglan.com/2017/09/19/the-patience-diff-algorithm/)
["Distributed, offline-first bug tracker embedded in git, with
bridges"](https://github.com/MichaelMure/git-bug) [Prototype Git GUI for
Filmmaking](https://github.com/jskjott/git-for-filmmakers) ["Pull
github, bitbucket, and trac issues into
taskwarrior"](https://github.com/ralphbean/bugwarrior) [Text-mode
interface for git](https://github.com/jonas/tig) [bcongdon/git-trophy: ?
Create a 3D Printed Model of Your Github
Contributio](https://github.com/bcongdon/git-trophy)

# Worktrees

- A git repository can have multiple working trees - allowing you to
  check out more than one workspace at a time!
  - Among other things, this allows you to work on multiple branches at
    once without having multiple copies of the file, and maps git
    branches or tags to other directories on your system. Use it to
    check on different efforts on projects without messing up your
    current editing environment - to look at code from other branches
    locally and simultaneously, for example!
- \`git worktree add \$PATH\` :: Adds a new branch with a name
  associated with the final component of \$PATH. \`git worktree remove\`
  and \`git worktree prune\` both allow you to cut off external
  worktrees.
- Flow example: latest develop, latest branch of work, and a third for
  reviewing pull requests and/or the work from other developers.

# Github

[track changes to a patch over
time](https://github.com/git-series/git-series) [git
flow](https://github.com/nvie/gitflow): git extensions for high level
repository operations [explore git cli with natural language
search](https://github.com/itsrainingmani/gitexplore) [github is
sinking](https://yarmo.eu/post/github-sinking)

## READMEs

[ A curated list of awesome Github Profile READMEs
📝](https://github.com/abhisheknaiidu/awesome-github-profile-readme)
<https://github.com/pifafu/pifafu/blob/main/readME.md> i love the font
choice and the gif here!

# Code Review

[How to do a code review \|
eng-practices](https://google.github.io/eng-practices/review/reviewer/)

# Alternatives

fossil  
git with additional features such as task management. it seems like a
superset of git's system. [Fossil vs.
Git](https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki)
[Incrementally converting from git to fossil while working on the git
repo](https://blog.nil.im/?78)

[repo](https://gerrit.googlesource.com/git-repo/+/refs/heads/master/README.md)  
Google's tool for managing monorepos.

[Pijul](https://pijul.org/)  
A distributed version control system

[Bazaar](http://bazaar.canonical.com/en/)  
Canonical's version control system