/

Tech-study-notes 0.1.6

On this page

Git

For learning how to use git:

Git Workflows

A Git workflow encourages effective collaboration, makes software development process more efficient, and facilitates continuous delivery. By choosing a singular Git workflow, teams can pave the way for smoother conflict resolution and a more coherent code base.

Centralized

A centralized Git workflow enables all team members to make changes directly to the main branch, with every change logged in a running history. This works well for small teams (or beginners), because team members can communicate easily in order to avoid contributing to the same piece of code simultaneously.

Limitations: If multiple developers commit to the same branch, it’s challenging to find a stable moment to release changes. Consequently, developers must keep unstable changes local until they’re ready for release.

Feature Branching

Rather than commit directly to the main branch, developers create a branch for each feature, make changes, submit a merge request (or pull request), and then merge it into main. This has the benefit of keeping a clean main branch without unfinished features.

Teams of any size can use this feature branching, because it permits multiple developers to work on the same feature simultaneously.

GitFlow

This workflow doesn’t add any new concepts beyond the Feature Branch Workflow, while it assigns specific roles to different branches and defines how and when they should interact. Here you would use a develop branch with feature branches.

GitFlow

The main branch should always be releasable to production, and there should never be untested / incomplete code on it. When the develop branch is ready to go to production, a contributor creates a release branch where testing and bug fixing occur before being merged back to the develop branch.

The release branch makes the code review process easier, because there’s a dedicated place to resolve conflicts when merging into the main branch. With this strategy, the main branch always reflects production.

Trunk-Based Development

Trunk-based development facilitates concurrent development on a single branch called trunk. Developers work directly on trunk or on short-lived branches, and when they are ready to release, they use release branches.

Trunk Based

Trunk-based development decreases the likelihood of merge conflicts and keeps code clean, because there are many frequent, small merges made each day.

Personal Branching

Personal branching is similar to feature branching, but rather than have a single branch per feature, it’s per developer. This approach works well if team members work on different features and bugs.

Every user can merge back to the main branch whenever their work is done.

Advantages:

This strategy can work well for small teams in which every team member develops their own part of the application.

Forking

A forking approach to version control starts with a complete copy of the repository. Forking effectively creates a local copy of a Git repository and provides the ability to create a new collaboration structure.

This workflow is popular for projects that have multiple developers contributing to it, particularly open source projects. After all, keeping track and providing privileges to collaborate to a repository with thousands of contributors is difficult to maintain.

If a maintainer enables contributors to try their changes on their forked copy, managing change proposals is easier and safer.

Benefits:

Images sources: Toptal – Trunk Based Development vs Git Flow

Branch naming conventions

Source: https://conventional-branch.github.io/

Conventional Branch refers to a structured and standardized naming convention for Git branches which aims to make branch more readable and actionable

Key Points

  1. Purpose-driven Branch Names: Each branch name clearly indicates its purpose, making it easy for all developers to understand what the branch is for.
  2. Integration with CI/CD: By using consistent branch names, it can help automated systems (like Continuous Integration/Continuous Deployment pipelines) to trigger specific actions based on the branch type (e.g., auto-deployment from release branches).
  3. Team Collaboration: It encourages collaboration within teams by making branch purpose explicit, reducing misunderstandings, and making it easier for team members to switch between tasks without confusion.

Prefixes

The branch specification supports the following prefixes and should be structured as:

<type>/<description>

Rules

  1. Use Lowercase Alphanumerics, Hyphens, and Dots: Always use lowercase letters (a-z), numbers (0-9), and hyphens (-) to separate words. Avoid special characters, underscores, or spaces. For release branches, dots (.) may be used in the description to represent version numbers (e.g., release/v1.2.0).
  2. No Consecutive, Leading, or Trailing Hyphens or Dots: Ensure that hyphens and dots do not appear consecutively (e.g., feature/new—login, release/v1.-2.0), nor at the start or end of the description (e.g., feature/-new-login, release/v1.2.0.).
  3. Keep It Clear and Concise: The branch name should be descriptive yet concise, clearly indicating the purpose of the work.
  4. Include Ticket Numbers: If applicable, include the ticket number from your project management tool to make tracking easier. For example, for a ticket issue-123, the branch name could be feature/issue-123-new-login.

Branch examples

Branch NameValidNotes
main✅Trunk branch
master✅Trunk branch
develop✅Trunk branch
feature/add-login-page✅New feature
feat/add-login-page✅Short alias for feature
bugfix/fix-header-bug✅Bug fix
fix/header-bug✅Short alias for bugfix
hotfix/security-patch✅Urgent fix
release/v1.2.0✅Release with version
chore/update-dependencies✅Non-code task
feature/issue-123-new-login✅Feature with ticket number
Feature/Add-Login❌Uppercase letters not allowed
feature/new—login❌Consecutive hyphens not allowed
feature/-new-login❌Leading hyphen in description
feature/new-login-❌Trailing hyphen in description
release/v1.-2.0❌Hyphen adjacent to dot
fix/header bug❌Spaces not allowed
fix/header_bug❌Underscores not allowed
unknown/some-task❌Unknown prefix type

Commit messages conventions

Source: https://www.conventionalcommits.org/en/v1.0.0/

The Conventional Commits specification is a lightweight convention that provides an easy set of rules for creating an explicit commit history, which makes it easier to write automated tools on top of.

The commit message should be structured as follows:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

The commit contains the following structural elements, to communicate intent to the consumers of your library:

Additional types are not mandated by the Conventional Commits specification, and have no implicit effect in Semantic Versioning (unless they include a BREAKING CHANGE). A scope may be provided to a commit’s type, to provide additional contextual information and is contained within parenthesis, e.g., feat(parser): add ability to parse arrays.

Commit examples