Listing all available branches with the most recent messages is a good starting point.
git branch --all --verbose
If you can see that commit messages looking pretty different, as if everyone saying "hey! my style is better than yours! not going to change own tho", then, probably, you're a lucky person surrounded by superstars.
Another goal here is to identify a branching strategy. Meditate a bit on these names trying to see the patterns.
Going deeper:
git rev-list --count origin/master
git rev-list --count --no-merges origin/master
git rev-list --count --merges origin/master
That prints the total number of commits for a branch of interest. The --merge
and --no-merge
switches find out a number of merge commits. In our example near the 25% of commit objects are merge commits. What could it point to? First of all, it could say nothing. Maybe it's a pull request policy or kinda auto-merge strategy. However, it is important to remember that merge is a reification of a conflict which during resolution could impose a bug. So from this perspective less is better.
Next. git for-each-ref
and shell automate repetitive research. This will print the above info for every branch in a repository:
git for-each-ref \
--sort=-committerdate \
--shell \
--format='"%(refname:short)' \
refs/remotes/ \
| xargs -I REF sh -c 'printf "%-40s %10s %10s\n" "REF" `git rev-list --count REF` `git rev-list --count --merges REF`'
Yet another goody will show you date and author of the last commit per remote branch. Nice way to figure out outdated branches.
git for-each-ref \
--sort=-committerdate \
--format='%(align:35)%(refname:short)%(end) %(committerdate:short) %(align:20)%(authorname)%(end) %(objectname:short)' \
refs/remotes
From there you can get your coworker's names and ideas that they were working out some time ago. In more informal company there may be nicknames instead of first/last pair.
Number of contributions per author sorted and with email addresses git shortlog -sne
. Use it either with --no-merges
or without.
Deeper. Let's find the most frequently updated files in the branch. Be sure to play with --since
, --after
, --before
options of a git log
command if you have a huge history and/or interested in only recently applyed changes. It could be --since="4 weeks 3 days 2 hours 1 minutes"
or --after="2020-02-02"
.
git log --pretty=format: --name-only | sort | uniq -c | sort -r | head -30
This list sometimes provides you insights about what matter most for project or company because here is the place where first domain terminology comes up. These files are also helping you to see habits and possible design issues. Look at the first line with 154 changes. Maybe it’s a Fat Controller, sort of a God Object? This might lead you that short OOAD training for the team would be a good investment. This fatty file living in the repository, of course, might be an okay thing. You may just see a throw away prototype or auto generated code. Simple review would not take much time but you'll become more informed and prepared person.
Another way to reveal the habits are reading single file history. Take one from the list above and see how it evolved. The clean history will help you understand the direction and purpose of any code change. Dirty and useless history may signal you that requirements change requests and code changes were orbiting different stars. The messages below taken from a real commercial project:
Pretty formatted log messages possible via an alias in .gitconfig
:
# ~/.gitconfig
[alias]
lg = log --all --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative
These small steps are still a very beginning in understanding other people minds and culture that they strive for.