SlideShare a Scribd company logo
THAMARA HESSEL
I’m coder
GIT
Best Practices
3
Contents
▪ Commit - Best Practices
– The golden rules
– Good full example
▪ Rebase
– Rebase Interactive
▪ Merge
Commit
5
Commit - Best Practices
A project long term success should depend on the
way the “project log” is maintained.
It’s up to the users of the project to be the
maintainers. It’s easy to be sidetracked and forget
about doing the right thing, but it’s always better to
be respectful of your own work. You never
know when you will have to consult it later.
bugfix minor changes wtf
BUG-9284
more work Work on feature GRE-3958
Fix
Change X constant to be 10
Fix
oopsie
6
The golden rules
1. Separate subject from body with a blank line
2. Limit the subject line to 50 characters
3. Capitalize the subject line
4. Use the imperative mood in the subject line
5. Wrap the body at 72 characters
6. Use the body to explain what and why vs. how
7
1 - Separate subject from body with a blank line
git commit --help
Though not required, it’s a good idea to begin the commit message with a single short
(less than 50 character) line summarizing the change, followed by a blank line and then a more
thorough description
Sometimes there’s no need for a body in a commit, but only when the line you wrote is already specific
enough
For example:
➔ Fix typo in price list page
➔ Correct facebook redirect due to wrong token
8
2 - Limit the subject line to 50 characters
It’s not a hard limit per say, but should be an indicator.
Most of the tools when parsing the “Subject” of the commit limit it to 50 characters like mentioned
on the git commit manpage
Why?
Because if you’re writing more than that probably what you’re trying to do shouldn’t be in a single
commit.
Also a good indicator is if you put the word “and” on your subject.
9
3 - Capitalize the subject line
Begin all lines with a Capital letter
You’re starting a “Composition” you should never start it with a lowercase.
10
4 - Use the imperative mood in the subject line
Spoken or written as if giving a command or instruction
Update - Change - Add - Remove - Improve - Include - Implement - Fix … something
Git itself uses the imperative command when you do certain commands you can notice this:
➔ Merge branch ‘x’
➔ Revert "Wrong commit made"
➔ Merge pull request #123 from someuser/somebranch
11
4 - Use the imperative mood in the subject line - CONTINUE
For example
If applied, this commit will:
➔ refactor subsystem X for readability
➔ update getting started documentation
➔ remove deprecated methods
Notice how this doesn’t work for the other non-imperative forms. If applied, this commit will:
➔ fixed bug with Y
➔ changing behavior of X
➔ more fixes for broken stuff
➔ sweet new API methods
12
5 - Wrap the body at 72 characters
You should do 72 characters the same reason you do in the code to be easier to read.
Most log tools or viewing tools hard limit to 80 characters so with 72 and spaces you get
to that limit.
13
6 - Use the body to explain what and why vs. how
For me the most important thing!
Please always explain what and why you did, what you did and not how you did it!
Because if your commit is concise enough, I don’t need to go and see your code from top to bottom
just to understand why you did what you did.
14
Good full example
❏ 50 characters
❏ Capitalize
❏ A blank line
❏ Imperative mood
❏ 72 characters
❏ Body to explain what and why vs. how
Rebase
16
Rebase
Why rebase? To maintain a clean log.
There’s no point to create useless merge commits when all you’re doing is updating your branch with the
one you want to merge unto later.
So a simple rule of thumb is to rebase with the target branch and rebase often. Everyday you’re working you
should rebase your branch into your target branch and one last target before merging into it.
17
Rebase Interactive
When you’re working on a feature, you should always commit often it’s a good practice. But when
you’re finished, you should always squash it into a single commit.
after . . .
18
Rebase Interactive - continued
Possible commands:
➔ p, pick
➔ r, reword
➔ e, edit
➔ s, squash
➔ f, fixup
➔ x, exec
➔ d,drop
Merge
20
Merge
Merge is a great operation but it should be used correctly.
Please don’t merge directly into a feature branch from develop or master. Use rebase for it.
Merge is supposed to tell a story. It’s great when you want to make a release or a hotfix. In that way you
can identify exactly what you released by tagging the merge commit with a version
If you are consistently merging your “developing” code with a stable branch, it’s gonna do more harm
than good.
END (Q&A)
22

More Related Content

Similar to Git style best practices - OLX

Maintainable Javascript carsonified
Maintainable Javascript carsonifiedMaintainable Javascript carsonified
Maintainable Javascript carsonified
Christian Heilmann
 
The View - 30 proven Lotuscript tips
The View - 30 proven Lotuscript tipsThe View - 30 proven Lotuscript tips
The View - 30 proven Lotuscript tips
Bill Buchan
 
Dev buchan 30 proven tips
Dev buchan 30 proven tipsDev buchan 30 proven tips
Dev buchan 30 proven tips
Bill Buchan
 
Don't RTFM, WTFM - Open Source Documentation - German Perl Workshop 2010
Don't RTFM, WTFM - Open Source Documentation - German Perl Workshop 2010Don't RTFM, WTFM - Open Source Documentation - German Perl Workshop 2010
Don't RTFM, WTFM - Open Source Documentation - German Perl Workshop 2010
singingfish
 

Similar to Git style best practices - OLX (20)

Software development best practices & coding guidelines
Software development best practices & coding guidelinesSoftware development best practices & coding guidelines
Software development best practices & coding guidelines
 
Maintainable Javascript carsonified
Maintainable Javascript carsonifiedMaintainable Javascript carsonified
Maintainable Javascript carsonified
 
Best Practices in Software Development
Best Practices in Software DevelopmentBest Practices in Software Development
Best Practices in Software Development
 
Femmengeeniring_Kateryna Mishchenko.pdf
Femmengeeniring_Kateryna Mishchenko.pdfFemmengeeniring_Kateryna Mishchenko.pdf
Femmengeeniring_Kateryna Mishchenko.pdf
 
Good Coding Practices with JavaScript
Good Coding Practices with JavaScriptGood Coding Practices with JavaScript
Good Coding Practices with JavaScript
 
The View - 30 proven Lotuscript tips
The View - 30 proven Lotuscript tipsThe View - 30 proven Lotuscript tips
The View - 30 proven Lotuscript tips
 
Being dangerous with git
Being dangerous with gitBeing dangerous with git
Being dangerous with git
 
Dev buchan 30 proven tips
Dev buchan 30 proven tipsDev buchan 30 proven tips
Dev buchan 30 proven tips
 
Siebel best practices
Siebel best practicesSiebel best practices
Siebel best practices
 
C# coding standards, good programming principles & refactoring
C# coding standards, good programming principles & refactoringC# coding standards, good programming principles & refactoring
C# coding standards, good programming principles & refactoring
 
Working with others using git and Github
Working with others using git and GithubWorking with others using git and Github
Working with others using git and Github
 
YAGNI Principle and Clean Code
YAGNI Principle and Clean CodeYAGNI Principle and Clean Code
YAGNI Principle and Clean Code
 
Git Makes Me Angry Inside
Git Makes Me Angry InsideGit Makes Me Angry Inside
Git Makes Me Angry Inside
 
AN EXERCISE IN CLEANER CODE - FROM LEGACY TO MAINTAINABLE
AN EXERCISE IN CLEANER CODE - FROM LEGACY TO MAINTAINABLEAN EXERCISE IN CLEANER CODE - FROM LEGACY TO MAINTAINABLE
AN EXERCISE IN CLEANER CODE - FROM LEGACY TO MAINTAINABLE
 
AN EXERCISE IN CLEANER CODE - FROM LEGACY TO MAINTAINABLE - CFObjective() 2017
AN EXERCISE IN CLEANER CODE - FROM LEGACY TO MAINTAINABLE - CFObjective() 2017AN EXERCISE IN CLEANER CODE - FROM LEGACY TO MAINTAINABLE - CFObjective() 2017
AN EXERCISE IN CLEANER CODE - FROM LEGACY TO MAINTAINABLE - CFObjective() 2017
 
CPP03 - Repetition
CPP03 - RepetitionCPP03 - Repetition
CPP03 - Repetition
 
Creating Stable Assignments
Creating Stable AssignmentsCreating Stable Assignments
Creating Stable Assignments
 
Principled And Clean Coding
Principled And Clean CodingPrincipled And Clean Coding
Principled And Clean Coding
 
Put to the Test
Put to the TestPut to the Test
Put to the Test
 
Don't RTFM, WTFM - Open Source Documentation - German Perl Workshop 2010
Don't RTFM, WTFM - Open Source Documentation - German Perl Workshop 2010Don't RTFM, WTFM - Open Source Documentation - German Perl Workshop 2010
Don't RTFM, WTFM - Open Source Documentation - German Perl Workshop 2010
 

More from Thamara Hessel

More from Thamara Hessel (9)

Liderar e ser liderado(a) - o que você precisa saber sobre liderança técnica
Liderar e ser liderado(a) - o que você precisa saber sobre liderança técnicaLiderar e ser liderado(a) - o que você precisa saber sobre liderança técnica
Liderar e ser liderado(a) - o que você precisa saber sobre liderança técnica
 
What do software engineers do
What do software engineers do What do software engineers do
What do software engineers do
 
Arquitetura e qualidade de codigo
Arquitetura e qualidade de codigoArquitetura e qualidade de codigo
Arquitetura e qualidade de codigo
 
Composer - tricks and tips
Composer - tricks and tipsComposer - tricks and tips
Composer - tricks and tips
 
Code review Effective - kwan
Code review  Effective - kwanCode review  Effective - kwan
Code review Effective - kwan
 
Object calisthenics
Object calisthenics  Object calisthenics
Object calisthenics
 
Git - Saia do Básico!
Git - Saia do Básico!Git - Saia do Básico!
Git - Saia do Básico!
 
Qualidade de código
Qualidade de códigoQualidade de código
Qualidade de código
 
Refactoring sem complicação!
Refactoring sem complicação!Refactoring sem complicação!
Refactoring sem complicação!
 

Recently uploaded

Future Visions: Predictions to Guide and Time Tech Innovation, Peter Udo Diehl
Future Visions: Predictions to Guide and Time Tech Innovation, Peter Udo DiehlFuture Visions: Predictions to Guide and Time Tech Innovation, Peter Udo Diehl
Future Visions: Predictions to Guide and Time Tech Innovation, Peter Udo Diehl
Peter Udo Diehl
 

Recently uploaded (20)

Free and Effective: Making Flows Publicly Accessible, Yumi Ibrahimzade
Free and Effective: Making Flows Publicly Accessible, Yumi IbrahimzadeFree and Effective: Making Flows Publicly Accessible, Yumi Ibrahimzade
Free and Effective: Making Flows Publicly Accessible, Yumi Ibrahimzade
 
How Red Hat Uses FDO in Device Lifecycle _ Costin and Vitaliy at Red Hat.pdf
How Red Hat Uses FDO in Device Lifecycle _ Costin and Vitaliy at Red Hat.pdfHow Red Hat Uses FDO in Device Lifecycle _ Costin and Vitaliy at Red Hat.pdf
How Red Hat Uses FDO in Device Lifecycle _ Costin and Vitaliy at Red Hat.pdf
 
Optimizing NoSQL Performance Through Observability
Optimizing NoSQL Performance Through ObservabilityOptimizing NoSQL Performance Through Observability
Optimizing NoSQL Performance Through Observability
 
Custom Approval Process: A New Perspective, Pavel Hrbacek & Anindya Halder
Custom Approval Process: A New Perspective, Pavel Hrbacek & Anindya HalderCustom Approval Process: A New Perspective, Pavel Hrbacek & Anindya Halder
Custom Approval Process: A New Perspective, Pavel Hrbacek & Anindya Halder
 
Designing for Hardware Accessibility at Comcast
Designing for Hardware Accessibility at ComcastDesigning for Hardware Accessibility at Comcast
Designing for Hardware Accessibility at Comcast
 
Choosing the Right FDO Deployment Model for Your Application _ Geoffrey at In...
Choosing the Right FDO Deployment Model for Your Application _ Geoffrey at In...Choosing the Right FDO Deployment Model for Your Application _ Geoffrey at In...
Choosing the Right FDO Deployment Model for Your Application _ Geoffrey at In...
 
10 Differences between Sales Cloud and CPQ, Blanka Doktorová
10 Differences between Sales Cloud and CPQ, Blanka Doktorová10 Differences between Sales Cloud and CPQ, Blanka Doktorová
10 Differences between Sales Cloud and CPQ, Blanka Doktorová
 
Syngulon - Selection technology May 2024.pdf
Syngulon - Selection technology May 2024.pdfSyngulon - Selection technology May 2024.pdf
Syngulon - Selection technology May 2024.pdf
 
Top 10 Symfony Development Companies 2024
Top 10 Symfony Development Companies 2024Top 10 Symfony Development Companies 2024
Top 10 Symfony Development Companies 2024
 
Agentic RAG What it is its types applications and implementation.pdf
Agentic RAG What it is its types applications and implementation.pdfAgentic RAG What it is its types applications and implementation.pdf
Agentic RAG What it is its types applications and implementation.pdf
 
Future Visions: Predictions to Guide and Time Tech Innovation, Peter Udo Diehl
Future Visions: Predictions to Guide and Time Tech Innovation, Peter Udo DiehlFuture Visions: Predictions to Guide and Time Tech Innovation, Peter Udo Diehl
Future Visions: Predictions to Guide and Time Tech Innovation, Peter Udo Diehl
 
The Metaverse: Are We There Yet?
The  Metaverse:    Are   We  There  Yet?The  Metaverse:    Are   We  There  Yet?
The Metaverse: Are We There Yet?
 
IoT Analytics Company Presentation May 2024
IoT Analytics Company Presentation May 2024IoT Analytics Company Presentation May 2024
IoT Analytics Company Presentation May 2024
 
Buy Epson EcoTank L3210 Colour Printer Online.pdf
Buy Epson EcoTank L3210 Colour Printer Online.pdfBuy Epson EcoTank L3210 Colour Printer Online.pdf
Buy Epson EcoTank L3210 Colour Printer Online.pdf
 
Buy Epson EcoTank L3210 Colour Printer Online.pptx
Buy Epson EcoTank L3210 Colour Printer Online.pptxBuy Epson EcoTank L3210 Colour Printer Online.pptx
Buy Epson EcoTank L3210 Colour Printer Online.pptx
 
SOQL 201 for Admins & Developers: Slice & Dice Your Org’s Data With Aggregate...
SOQL 201 for Admins & Developers: Slice & Dice Your Org’s Data With Aggregate...SOQL 201 for Admins & Developers: Slice & Dice Your Org’s Data With Aggregate...
SOQL 201 for Admins & Developers: Slice & Dice Your Org’s Data With Aggregate...
 
PLAI - Acceleration Program for Generative A.I. Startups
PLAI - Acceleration Program for Generative A.I. StartupsPLAI - Acceleration Program for Generative A.I. Startups
PLAI - Acceleration Program for Generative A.I. Startups
 
The Value of Certifying Products for FDO _ Paul at FIDO Alliance.pdf
The Value of Certifying Products for FDO _ Paul at FIDO Alliance.pdfThe Value of Certifying Products for FDO _ Paul at FIDO Alliance.pdf
The Value of Certifying Products for FDO _ Paul at FIDO Alliance.pdf
 
Speed Wins: From Kafka to APIs in Minutes
Speed Wins: From Kafka to APIs in MinutesSpeed Wins: From Kafka to APIs in Minutes
Speed Wins: From Kafka to APIs in Minutes
 
AI revolution and Salesforce, Jiří Karpíšek
AI revolution and Salesforce, Jiří KarpíšekAI revolution and Salesforce, Jiří Karpíšek
AI revolution and Salesforce, Jiří Karpíšek
 

Git style best practices - OLX

  • 3. 3 Contents ▪ Commit - Best Practices – The golden rules – Good full example ▪ Rebase – Rebase Interactive ▪ Merge
  • 5. 5 Commit - Best Practices A project long term success should depend on the way the “project log” is maintained. It’s up to the users of the project to be the maintainers. It’s easy to be sidetracked and forget about doing the right thing, but it’s always better to be respectful of your own work. You never know when you will have to consult it later. bugfix minor changes wtf BUG-9284 more work Work on feature GRE-3958 Fix Change X constant to be 10 Fix oopsie
  • 6. 6 The golden rules 1. Separate subject from body with a blank line 2. Limit the subject line to 50 characters 3. Capitalize the subject line 4. Use the imperative mood in the subject line 5. Wrap the body at 72 characters 6. Use the body to explain what and why vs. how
  • 7. 7 1 - Separate subject from body with a blank line git commit --help Though not required, it’s a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough description Sometimes there’s no need for a body in a commit, but only when the line you wrote is already specific enough For example: ➔ Fix typo in price list page ➔ Correct facebook redirect due to wrong token
  • 8. 8 2 - Limit the subject line to 50 characters It’s not a hard limit per say, but should be an indicator. Most of the tools when parsing the “Subject” of the commit limit it to 50 characters like mentioned on the git commit manpage Why? Because if you’re writing more than that probably what you’re trying to do shouldn’t be in a single commit. Also a good indicator is if you put the word “and” on your subject.
  • 9. 9 3 - Capitalize the subject line Begin all lines with a Capital letter You’re starting a “Composition” you should never start it with a lowercase.
  • 10. 10 4 - Use the imperative mood in the subject line Spoken or written as if giving a command or instruction Update - Change - Add - Remove - Improve - Include - Implement - Fix … something Git itself uses the imperative command when you do certain commands you can notice this: ➔ Merge branch ‘x’ ➔ Revert "Wrong commit made" ➔ Merge pull request #123 from someuser/somebranch
  • 11. 11 4 - Use the imperative mood in the subject line - CONTINUE For example If applied, this commit will: ➔ refactor subsystem X for readability ➔ update getting started documentation ➔ remove deprecated methods Notice how this doesn’t work for the other non-imperative forms. If applied, this commit will: ➔ fixed bug with Y ➔ changing behavior of X ➔ more fixes for broken stuff ➔ sweet new API methods
  • 12. 12 5 - Wrap the body at 72 characters You should do 72 characters the same reason you do in the code to be easier to read. Most log tools or viewing tools hard limit to 80 characters so with 72 and spaces you get to that limit.
  • 13. 13 6 - Use the body to explain what and why vs. how For me the most important thing! Please always explain what and why you did, what you did and not how you did it! Because if your commit is concise enough, I don’t need to go and see your code from top to bottom just to understand why you did what you did.
  • 14. 14 Good full example ❏ 50 characters ❏ Capitalize ❏ A blank line ❏ Imperative mood ❏ 72 characters ❏ Body to explain what and why vs. how
  • 16. 16 Rebase Why rebase? To maintain a clean log. There’s no point to create useless merge commits when all you’re doing is updating your branch with the one you want to merge unto later. So a simple rule of thumb is to rebase with the target branch and rebase often. Everyday you’re working you should rebase your branch into your target branch and one last target before merging into it.
  • 17. 17 Rebase Interactive When you’re working on a feature, you should always commit often it’s a good practice. But when you’re finished, you should always squash it into a single commit. after . . .
  • 18. 18 Rebase Interactive - continued Possible commands: ➔ p, pick ➔ r, reword ➔ e, edit ➔ s, squash ➔ f, fixup ➔ x, exec ➔ d,drop
  • 19. Merge
  • 20. 20 Merge Merge is a great operation but it should be used correctly. Please don’t merge directly into a feature branch from develop or master. Use rebase for it. Merge is supposed to tell a story. It’s great when you want to make a release or a hotfix. In that way you can identify exactly what you released by tagging the merge commit with a version If you are consistently merging your “developing” code with a stable branch, it’s gonna do more harm than good.
  • 22. 22