Git Etiquette: Best practices
or Mind your Git Manners
Irina Gulina
Tomas Tomecek
Senior Software Quality Engineer        Principal Software Engineer
i
v-t Red Hat
History, why we are here?
• Red Hat does lots of projects with Universities
• Main feedback on students:
"We often see students don't have the experience of working in Git in team/collaborative projects"
2
4^ Red Hat
Workflow in a personal GIT repo Workflow in a team GIT repo
3
Red Hat
Agenda
• Commit
• Push
• PR/MR submitting and review
• Quiz
Happy Birthday, Git!
Source: https://octodex.github.com/
Commit content
• Do: One commit = One logical change
1e4faa0   Fix login timeout BZ 2r5asy8  Add foo login step
• Don't: Two and more changes in one commit 1e4faa0   Fix login timeout BZ, add foo login step
Commit content
• Separate whitespace changes from code changes, especially unrelated.
o Mixing those is a great way to introduce a bug and o Complicates code review
8
4^ Red Hat
What is a 'bad' commit message?
dcc2d35	address comments	<-	what comments?
b7aac30	fix issue #123	<-	of what project?
0b7a4e4	various docs fixes	<-	what docs? why?
1e4faa0	ui bug fix	<-	what was the bug?
fc3d081	readme update	<-	why?
d21660dc	ToDo	<-	t)(§) (§)(§)
0b7a4e4	Mix fixes and cleanups	<-	
5h3d28g	refactoring	<-	®
Uninformative, look-elsewhere commit messages (titles)
9
4^ Red Hat
Poor quality code can be refactored A terrible commit message lasts
forever.
10
Red Hat
For whom do you write commit messages?
11
4tRed Hat
Why should I write "good7 commit messages?
• To help to understand the code change o What has been changed?
o Why is that change necessary?
• To speed up the reviewing process
• To help to locate a bug
• To write a good release note or script it
12
4^ Red Hat
What is a commit message?
• Title/subject line
• Body
Commit message example
commit <commit_id>
Author: <author_name> <author_email> Commit Title or Subject line Date: Mon Apr 2 15:10:03 2020-0400 _________
. Commit Body
Change how workers are represented
* Don't serialize the 'gracefully_shutdown' field
* Create a new 'missing' property and serialize it
* In the status API, list both online and missing workers
Requires PR: https://github.com/<project>/pull/921 closes #354498
https://bugzilla.redhat.com/show_bug.cgi7id=354498
14
4^ Red Hat
Usage of a commit title
• git log —pretty=oneline
• git rebase —interactive
• merge.summary
• gitshortlog
• git format-patch, git send-email,...
• reflogs
• GUI tools for committing and browsing
• GitHub, SourceForge, Bitbucket, GitLab,... service
15
4^ Red Hat
What constitutes a good commit message?
• git commit -m "Fix login timeout bug"
• git commit or git commit —verbose
Redirect user to the requested page after login https://link/to/issue/tracker
16
4^ Red Hat
What constitutes a good commit message?
• Capital letter, 50/72, no punctuation in the end
$ git commit
A brief summary of the commit
A paragraph describing what changed and its impact."
What constitutes a good commit message?
• Present Tense and Imperative Mood
cf31dl2 Adds unit tests for login 7a9kj4f Fixed unit tests 101q2wd Update unit tests Ib7hn61 Removing unit test
"If accepted, this commit will <your commit message goes here>"
Ticket number in commit messages
• Ticketing system != git log
o "TICKET-123456 add missing params to class" o "Add missing meta fields to response"
□ Takes space in 50 chars limit title
□ Look-elsewhere for details message, I'm lazy
□ May be not available for interested user or reviewer (permissions, outage)
Signing off your commits
• Kernel requires you to "sign-off" your code changes:
o  kernel.org/.../submittina-patches.html#sian-vour-work-the-developer-s-cer tificate-of-oriain
• In general: please make sure your proposal conforms to contribution guidelines
commit a6b88effc8b24d7216a762a42f365adeb31c903c Build SRPMs in Copr
Signed-off-by: Tomas Tomecek <ttomecek@nedhat.com>
20
4^ Red Hat
What constitutes a good commit message?
• Clear Title - What is commit about?
• Present Tense and Imperative Mood
• No punctuation in a title
• Clear Body - What and why is it needed/changed vs how?
• 50/72
• Reference to an issue in a body message
• Follow the commit convention defined by the team
21
4^ Red Hat
How to contribute to a team/community repo?
FORK IT
Red Hat
How to fork
• Click Fork in a team repo
• Target your personal namespace
)VEF    Use Git or checkout with SVN using the web URL.
4^ Red Hat
Git remotes
I     I Clone your fork via SSH
$ git clone
git@github.com:TomasTomecek/packit. git
Cloning into ' packit'... remote: Enumerating objects: 13351, done, remote: Counting objects: 100% (436/436), done, remote: Compressing objects: 100% (321/321), done.
remote: Total 13351 (delta 238), reused 255 (delta 115), pack-reused 12915 Receiving objects: 100% (13351/13351), 22.10 MiB | 5.31 MiB/s, done.
Resolving deltas: 100% (9359/9359), done.
I     I Add HTTPS remote upstream $ git remote add \
upstream https://github.com/packit/packit.git $ git remote -v
origin git@github.com:TomasTomecek/packit.git upstream https://github.com/packit/packit.git
$ cd packit
4^ Red Hat
How to fork
25
4^ Red Hat
Pull-Request
1 origin		Clone	david
			
		Push	
David's account
Pull-Request
Clair's account
GitHub
Fork a community/team repo
In your local Fork do whatever you want, BUT
Mind branch naming (if they are for PR/MR)
o Bad branch name: Irina, ^ ~ main
o Good branch name: docs_on_upgrade_featur
Mind commit titles
28
4t Red Hat
IF YOU DO FORCE PUSH...
May the force stay with you.
29
Red Hat
You have a great freedom... to change your history locally.
30
Red Hat
Git push —force trap
• It's ok to force push to your local branch
• It's ok to force push to your (unmerged*) PR
• It's not ok to force push to a public branch
Git push —force consequences
• Lost data
• Altered history
• Not happy colleagues
• Lost karma points
How to avoid unwanted force push
• Protect important branches
• Backup
• Use git checkout-b
• Use --force-with-lease, carefully
• Use PR revert
Submitting a change
Red Hat
Why do we use PR/MR workflow?
• Share changes
• Get review and feedback
• Encourage quality
• Test and collaborate consistently
Creating a PR
When you push from your local to your origin, every time it will ask you to create a MR/PR
Irina Gulina > RHSAP > Repository
0  You pushed to mytest just now
Create merge request
Ansible_Design_...
rhsap / j + v
History
Find file      Web IDE      & *
Clone v
37
4^ Red Hat
Creating a MR/PR
When you push from your local to your origin, every time it will ask you to create a MR/PR
®ccsp-sap > RHSAP
Q)   You pushed to my_test at Irina Gulina / RHSAP 3 minutes ago
Create merge request
R     RHSAP ® j
Project ID: 53076 £.
38
4^ Red Hat
Creating a PR
• When you push from your local to your origin, every time it will ask you to create a MR/PR
Irina Gulina > RHSAP > Merge requests > New
New merge request
From my test into main  Change branches
Title
fvly test
Start the title with Draft: to prevent a merge request draft from m Add description templates to help your contributors to communicate
Re<
Creating a PR
• When you push from your local to your origin, every time it will ask you to create a MR/PR
Irina Gulina > RHSAP > Merge requests > New
New merge request
Source branch
igulina/rhsap my test
Oadd emptyjile Irina authored 5 minutes ago
Compare branches and continue
40
4t Red Hat
Target branch		
		
ccsp-sap/rhsap	main	
		
I Ö95ae6aa | ß
What constitutes a good PR/MR?
• Complete piece of work
• Adds value in some way
• Solid title
• Body explains the change
• Clear commit history
• Small
• Meets project's contribution guidelines
What constitutes a good PR/MR?
< > Code      O Issues      1*1 Pull requests l       0 Actions ) Projects
iki      Q Security      [_^ Insights
solve issues #38, 91, 96...102, 104, 106...111 #110
fro Merged
CENSORED
[□ on Jan 27, 2021
Q) Conversation   5        -o Commits   26 Checks   0        d) Files changed 79
42
Red Hat
Contributors (before submitting a PR/MR)
• Follow the repo's conventions (especially templates)
• Double check your code (and TODOs)
• Your change is documented
• Keep changes small
• Separate branch (don't create from main)
• Be clear and specif ic
• And kind, please
Contributors (after submitting a PR/MR)
• Check your ego and be polite o @username ping!
o @username review please
• Ensure your branch can be merged and tests pass
• Use —amend, —fixup or rebase -i
• Don't merge your own PR
WIP PR/MR
• WIP = Work in progress
• Don't overuse WIP label
• Remove WIP label when ready
• "This is ready for review, please."
Reviewing a PR
46
4t Red Hat
PR Reviewers
• Be kind and polite
o @username ping, error here!
o @username s/f oo/bar/, because bar can...
• Check commit history
• Don't fix issues
• Collaborate, don't command
• Ensure the branch can be merged
• CI Tests pass
• Don't merge WIPs
• Follow project's merge process
48
Source: https://octodex.github.com/
Red Hat
QUESTIONS?
Irina Gulina, QE igulina@redhat.com
49
4t Red Hat
Thank you
IP linkedin.com/company/red-hat
Red Hat is the world's leading provider of enterprise open source software solutions. Award-winning support, training, and consulting services make Red Hat a trusted adviser to the Fortune 500.
youtube.com/user/RedHatVideos
, facebook.com/redhatinc
twitter.com/RedHat
v-t Red Hat