DEV Community: varbSan

A Simplified Convention for Naming Branches and Commits in Git

varbSan — Thu, 19 May 2022 19:00:29 +0000

There are many excellent naming conventions regarding git branches and commits.

But what if you want something very lean and simple?

Here is a proposition.

Branch Naming Convention

The Git Branching Naming Convention article is an excellent base.
However, you can simplify even more.

Category

A git branch should start with a category. Pick one of these: feature, bugfix, hotfix, or test.

feature is for adding, refactoring or removing a feature
bugfix is for fixing a bug
hotfix is for changing code with a temporary solution and/or without following the usual process (usually because of an emergency)
test is for experimenting outside of an issue/ticket

Reference

After the category, there should be a "/" followed by the reference of the issue/ticket you are working on. If there's no reference, just add no-ref.

Description

After the reference, there should be another "/" followed by a description which sums up the purpose of this specific branch. This description should be short and "kebab-cased".

By default, you can use the title of the issue/ticket you are working on. Just replace any special character by "-".

To sum up, follow this pattern when branching:

git branch <category/reference/description-in-kebab-case>

Examples:

You need to add, refactor or remove a feature: git branch feature/issue-42/create-new-button-component
You need to fix a bug: git branch bugfix/issue-342/button-overlap-form-on-mobile
You need to fix a bug really fast (possibly with a temporary solution): git branch hotfix/no-ref/registration-form-not-working
You need to experiment outside of an issue/ticket: git branch test/no-ref/refactor-components-with-atomic-design

Commit Naming Convention

For commits, you can combine and simplify the Angular Commit Message Guideline and the Conventional Commits guideline.

Category

A commit message should start with a category of change. You can pretty much use the following 4 categories for everything: feat, fix, refactor, and chore.

feat is for adding a new feature
fix is for fixing a bug
refactor is for changing code for peformance or convenience purpose (e.g. readibility)
chore is for everything else (writing documentation, formatting, adding tests, cleaning useless code etc.)

After the category, there should be a ":" announcing the commit description.

Statement(s)

After the colon, the commit description should consist in short statements describing the changes.

Each statement should start with a verb conjugated in an imperative way. Statements should be seperated from themselves with a ";".

To sum up, follow this pattern when committing:

git commit -m '<category: do something; do some other things>'

Examples:

git commit -m 'feat: add new button component; add new button components to templates'
git commit -m 'fix: add the stop directive to button component to prevent propagation'
git commit -m 'refactor: rewrite button component in TypeScript'
git commit -m 'chore: write button documentation'

References

sources

article: Git Branching Name Convention
article: Conventional Commits 1.0.0
article: Commit Message Guideline
article: A Successful Git Branching Model

What is HTTP? (... for newbies)

varbSan — Mon, 31 Jan 2022 08:22:25 +0000

Intro

HTTP stands for Hypertext Transfer Protocol. It is the protocol allowing "clients" and "servers" to exchange information on the web at the Application Layer[^1].
For example, your computer is the client asking for the data of this very web page to a server, another computer over the internet. For the server to understand the client and vice versa they need to follow the same "standards": the HTTP protocol.

Interactions between server and client can take 2 forms: an HTTP request or an HTTP response. These requests and responses are carried and can be altered by proxies. The protocol is improving over time, new versions have been released since its birth in 1991.

Let's dive deeper into this!

What is an HTTP request?

An HTTP request is how the client can "talk" to the server.
This request contains a request line, a header, and optionally a body. You specify the method in the request line so the server knows what type of action is excepted. There are 8 methods but the main 5 are:

"GET" to retrieve data from the server
"POST" to submit data from the server
"DELETE" to erase data from the server
"PUT" to completely update data from the server.
"PATCH" to partially update data from the server.

The request header contains meta-information about the request and the client itself, like the browser and the OS used.

E.g. after you complete a sign-up form with your username and password, you click on submit. Clicking on the submit button triggers an HTTP request. The first line of the request informs the server it's a post request, the body of the request contains the username and the password so the server can process this information.

In addition to the method, the request line contains the url targeted and the HTTP protocol version the client wants to use using.

What is an HTTP response ?

An HTTP response is how the server can talk back to the client after an HTTP request.
This HTTP response contains a status code, a header and an optional body.

The status code gives information about how the request was processed by the server

A status code in between 100 and 199 provides information
A status code in between 200 and 299 states the request was successful
A status code in between 300 and 399 informs there is a redirection
A status code in between 400 and 499 informs of an error coming from the client
A status code in between 500 and 599 informs of an error coming from the server

The response header contains meta-information about the response and the server itself.
The body contains the most important information: usually the HTML content for the webpage the client asked for.

What are proxies?

Proxies are computers in-between the client and the server. They carry the HTTP request and response. They can be routers, or modems or more. They can act as caches, gateways etc.
The point is the HTTP message get handled by many computers between the client and the server. We already know many computers handle the data travelling at the Transport Layer[^2], but proxies refer to computers handling the data at the Application Layer. They handle the HTTP message itself.
E.g. when an image get cached for you. A proxy does the caching in between you and the server.

How new versions improved HTTP?

In 1991, HTTP 0.9 was the first HTTP protocol. It just had the GET method, and no header. Only HTML was supported in the response body.

In 1996, HTTP 1.0 was released. The POST method was added to the options for the request line. Meaning, you could now, not only retrieve, but also submit data to a server. The request and response were given a header. Status codes were introduced. And finally, the response body could include images and videos besides HTML text. This made "HTTP" a misnomer. HMTP (for Hyper Media Transfer Protocol) would have been more accurate but we kept the HTTP acronym for some reason.
Even though HTTP 1.0 added many features some issues remained. The main one was related to the Transport Layer. Long story short, the connection between server and client was closed after each request. In consequence, Three-way Handshake[^3] had to be repeated for each request, causing performance issues.
E.g., loading a page with multiple images was unecessary slow because the client and the server needed to have a back and forth in 3 steps to establish the connection.

In 1999, HTTP 1.1 was released. The DELETE method was added. And performance was improved by the addition of persistent connections between server and client by default. Pipelining was also added, enabling the client to send many request to a server without waiting to receive the first responses.

In 2015, HTTP 2.0 made the protocol improve again in performance, security and more.

In Short

HTTP is the protocol running the Web. It allows clients and servers to "talk" to each other through requests and responses.

These interactions are handled by intermediates called proxies.

Although the base stays the same, HTTP has had several versions of itself since being born in 1991. Each version improved the previous one by adding features, increasing performance, and reinforcing security.

References

Footnotes
[1]: See Application Layer
[2]: See Transmission Control Protocol (TCP)
[3]: See Three-way Handshake, which is a back and forth between client and server in 3 steps to establish TCP connection.

Sources