Git Branching – Rebasing
In Git, there are two main ways to integrate changes from one branch into another: the merge
and the rebase
.
In Git, there are two main ways to integrate changes from one branch into another: the merge
and the rebase
.
Specify the type of commit:
feat: The new feature you’re adding to a particular application
fix: A bug fix
style: Feature and updates related to styling
refactor: Refactoring a specific section of the codebase
test: Everything related to testing
docs: Everything related to documentation
chore: Regular code maintenance.[ You can also use emojis to represent commit types]
Separate the subject from the body with a blank line
Your commit message should not contain any whitespace errors
Remove unnecessary punctuation marks
Do not end the subject line with a period
Capitalize the subject line and each paragraph
Use the imperative mood in the subject line
Use the body to explain what changes you have made and why you made them.
Do not assume the reviewer understands what the original problem was, ensure you add it.
Do not think your code is self-explanatory
Follow the commit convention defined by your team
The script would:
– extract all file versions to /tmp/all_versions_exported
– take 1 argument – relative path to the file inside git repo
– give result filenames numeric prefix (sortable)
– mention inspected filename in result files (to tell apples apart from oranges:)
– mention commit date in the result filename (see output example below)
– not create empty result files
A specification for adding human and machine readable meaning to commit messages.
The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of. This convention dovetails with SemVer, by describing the features, fixes, and breaking changes made in commit messages.
But, in reality, these efforts started years ago, in 2014, when the Drupal project first moved in to replace «master/slave» terminology with «primary/replica.»
Drupal’s move was followed by the Python programming language, Chromium (the open-source browser project at the base of Chrome), Microsoft’s Roslyn .NET compiler, and the PostgreSQL and Redis database systems.
…términos como «master/slave» se llevan usando años no solo en el ámbito del desarrollo, sino también al hablar por ejemplo de las viejas configuraciones de discos duros.
Dichos conceptos siempre han suscitado cierta controversia por sus connotaciones raciales, y ahora varias empresas están impulsando cambios para dejar de usar esos términos y sustituirlos por otros más neutros. Por ejemplo usar «principal» (main), «por defecto» (default), «raíz» (root) o «primario» (primary) para sustituir al concepto de «maestro» (master).
Lo mismo ocurre con las «listas negras» y las «listas blancas» que por ejemplo usamos para admitir o bloquear ciertas palabras en los comentarios que llegan a un blog. En lugar de esos conceptos se quieren usar «lista de permitidos» y «lista de exluidos/denegados».
The concept of submodules is brilliant. It essentially allows you to attach an external repository inside another repository at a specific path.