Your commits should be descriptive, meaning they should have a subject line and a description.
The commits should also be specific, that is, code changes that are related are committed together. One might be tempted to write a lot of code and then commit them in a single batch. This makes code changes confusing as the subject and description will not catch everything that changed.
About the subject
- Subject line should not be longer than 70 characters as it is just a summary of what changed
- It should be in active voice e.g
rename functions with prefix
- begins one empty line below the subject
- should describe what changed and why
- should provide any warnings, for example, what might break
If you make many changes to the code and want to stage only a few of files to follow the convention of committing related changes, you can specify the files to stage by passing the file names or wilcards to
git add command.
Committing staged files
To confirm you have staged the correct files, do
git status and check the green list of files. If you are satisfied, do
git commit and then enter the subject and description in the editor window that pops up and confirm.
To check commit history, run
There are various conventions as far as git branching goes. The following are the common branching conventions.
Mainline Development Model
This carries the famous mantra, “Always be integrating”. Features:
- few branches
- relatively small commits
- high quality testing and QA standards
The consequence of this convention is that code is quickly integrated to the main branch.
State, Release, and Feature Branches Model
- Different types of branches
- Fulfil different types of jobs
Long-Running vs Short-Lived Branches
Examples are: main, develop, staging etc
- exist throughout project lifetime
- often mirror stages of development cycle
- common convention followed is that no direct commits happen
- created for new features, bug fixes, refactor, experiements etc
- they are deleted after they are merged or rebased to the long-running branches
This is a versy simple and lean strategy with one long running branch (main) and different feature branches
This strategy has more structure and more rules. It’s long-running branches are main, develop branches while short-lived branches are feature, release, hot-fixes and so on.
The idea of pull requests is to communicate about code. It invites other collaborators in the project to provide feedback before merging is done. Pull request are also used where a contributor has no write access to the repository.
Merge conflicts occur when integrating commits from different sources mostly when changes contradict. This means the same line changed in different commits. You can clean up the mentioned files or abort the merge/rebase. There are also automatic tools such as kaleidoscope.
Merge vs Rebase
A fast-forward merge happens when you want to merge a branch B to a branch A and branch A has no new commits while branch B has some new commits. Both branches end up sharing the same history.
When both branches to be merged have new commits, a merge commit will be used during the merge. The branches will not share their history.
This creates a straight line of commits. Example:
git rebase branch-B
The above command will remove all commits from branch A then apply those of branch B and finally appends the commits of branch A in front (made to be most recent) and hence it is a history rewrite. The commits of A will be descendants of branch B’s last commit.
⚠️ This history rewrite is only safe for those branches which have not been pushed upstream.
There you have it! Thank you for reading. Feel free to leave comments or suggestions below. 🎉
comments powered by Disqus