Nathan Wailes - Blog - GitHub - LinkedIn - Patreon - Reddit - Stack Overflow - Twitter - YouTube
Version-control (VCS) / git / gerrit
- Nathan Wailes
Owned by Nathan Wailes
To do
- Learn exactly how git works: how does it track individual lines?
Learning resources
- Learn Git Branching
- rec'd by Andy
- Eric Sink - Version Control By Example
- Pull requests
- A heavily-annotated implementation of Git in JavaScript
- John Wiegley - Git from the Bottom Up
- rec'd here
- Think Like (a) Git
- rec'd here
- https://trunkbaseddevelopment.com/
- Main idea: You should have people committing to a shared branch (or short-lived branches off that main branch) instead of having long-lived separate branches.
Thoughts on git
Tools
- Meld - A visual diff and merge tool.
- SourceTree
Concepts
Forks vs. Branches
- "Fork" is a GitHub concept; it isn't a Git command.
- If you have the permission to create and push to a branch on the original repo that's probably what you want to do. Forking is for when you don't have permission to create/push to a branch on the original repo.
- Forking is basically a remote-clone operation. The original repo is the original 'remote' / 'origin' repo (and you presumably don't have control of it), and you're cloning it into a new remote/origin repo that you control.
- If you intend to have some kind of permanent divergence in the path of the repo from the original, that is a situation to fork.
- Previously, I'd thought that the main reason to use forks rather than just having people work on branches is when you want to be able to introduce a formal / mandatory code-review step before someone can update the canonical version of a project.
- But I've since worked on a project where I did not fork the repo, but instead pushed to a branch of the main repo, and created a PR from that branch, and I did not have permission to push directly to the master branch. So a fork is not needed to restrict access to particular branches.
Rebasing
- From "Learn Git Branching": The second way of combining work between branches is rebasing. Rebasing essentially takes a set of commits, "copies" them, and plops them down somewhere else. While this sounds confusing, the advantage of rebasing is that it can be used to make a nice linear sequence of commits. The commit log / history of the repository will be a lot cleaner if only rebasing is allowed.
- From what I can tell, it seems the best reason to rebase isn't "to keep things in order", which was the impression I'd gotten from the explanations I heard at Infer and from "Learn Git Branching"; it's that if you check out a branch and make 100 commits to it, then merge that into master, then delete the branch, you don't have those individual commits anymore; you just have the smooshed-together mega-commit. So you lose the granularity of having many small code changes with the rationale for each in its commit message.