Skip to main content

Recorded History

Saturday, September 5, 2020

3 minutes

Any code of your own that you haven't looked at for six or more months might as well have been written by someone else.
— Eagleson's Law

The BitKeeper / SourcePuller feud spawned the development of Git in 2005. The concept of distributed source control had been around for a while but Linus Torvalds had unique insights on how to implement a system to improve on the designs of some of the earlier systems.

Audit of who did what when. signed commit - git blame somebody else

Repository Workflows

Distributed architecture enables many modes.

Branching Models

It took five years of everyone experimenting with Git for anything approaching a good workflow to emerge. For a while, everyone got excited about git-flow. GitHub flow, Git V

Like most things, there’s not a one-size-fits-all solution. Understand your processes and requirements.

With the rise of CI / CD practices, more and more are gravitating towards a trunk-based development process to shorten their feedback loops.


An atomic commit is the smallest individual changeset that will not break the build; it is not the entire feature in a single commit. A feature implementation will consist of many atomic commits; you may have changes grouped across business logic, configuration, documentation and the presentation layer. Having these changes as reductive as possible will make things easy for you to rollback changes as and when necessary but will also simplify the steps needed by git itself when it comes to combine your work into another branch. There will be far fewer conflicts.

Using new syntaxt switch - checkout

project>feature $ git fetch project>feature $ git rebase origin/main project>feature $ git switch main project>main $ git merge feature –no-ff

Atomic commit: Branch from master - known to work Do the work, single commit - doesn’t work Where did the error creep in? To me, seems a not very useful practice to encourage.

alternatively Atomic commit is the smallest iteration on the feature Multiple commits deliver the feature When it doesn’t work, use git bisect to pinpoint where the error crept in

Merge Strategies

Tell a story of the life of your project.

Merge commit rather than squashing.

Yes you migt say, even if you squash your commits the work will still be available in the reflog but only until you tidy up. Pruning old branches is just good housekeeping.

Prefering a particular practice on the basis of subjective aesthetics at the expense of discarding information isn’t the best trade-off in my opinion.

Top tip: turn on rerere - this will record the resolution of any merge conflicts so that they can be automaticaly re-applied should the same signature be encountered again in some future operation.


global ignore

Template - main branch