I love Git and version control. And I use version control over any project I do. I follow a series of rules when dealing with Git.
Commit as often as you can. Ideally after each micro-iteration, when something new is working.
This way, at the end of the day you can just rebase the whole branch and squash all of the micro-commits in a whole commit implementing the whole new features.
Good git workflow to make changes to new projects: clone, fork (
hub fork), 'git checkout -b my-feature', work, commit, 'git push -u nikitavoloboev my-feature', work, commit, 'git push'.
If you’re doing things right, there’s only two kinds of branches anyways, master and feature branches. Feature branches can be squashed and rebased off master (minimizing the issue of merge conflicts and making for easier management of the commit history) and merged to master from there without requiring further conflict resolution. (Trunk-Based Development)
A Git branch is just a pointer to a commit. Git commits, however, also contain the hash of the parent commit(s), so by referring to that commit you also refer too all ancestors.
Squash + rebase (for feature branches) are good for PRs. No one cares that it took you 20 tries to get the feature right, what matters is what went into the pull request, which is usually one commit.
Gitbase - SQL interface to Git repositories.
Gitea - Easiest, fastest, and most painless way of setting up a self-hosted Git service.
clog-cli - Generate beautiful changelogs from your Git commit history.
gitbatch - Manage your git repositories in one place.
Conventional Commits - Specification for adding human and machine readable meaning to commit messages.
git absorb - Git commit --fixup, but automatic.
ghq - Manage remote repository clones.
gitin - Commit/branch/status explorer for git.