Branch naming conventions and guidelines

The documentation should cover naming conventions for core- and story branch names and prefixes and references to gitflow.

`svengreb` GitHub account migration

With the retirement of the Arctic Ice Studio personal & Nord project brand this project will also move to the real-in-person identity “Sven Greb“ in the context of the repository to the svengreb GitHub account.

Initial style guide and project documentation

Add the initial commit message style guide and project documentation.

CHANGELOG header
Project assets
README section Introduction
README section Structural Split of Changes with Bad Practices
README section Commit Messages with Elements and their Structure including all components

Tag naming conventions and guidelines

The documentation should cover naming conventions for tag names and prefixes and references to the used versioning specification ArcVer.

Migrate to MIT license

Currently the project code is licensed under the Apache 2.0 license. This often causes problems when developers want to use the project or code parts of it in another project (mainly code editors and UI frameworks) licensed under a less restricted license.

Therefore the project will migrate to the MIT license which is more open, unrestricted and the most used license for open source projects (Facebook recently also re-licensed React).

GitHub Flow migration

Historical Background

Back on July 22 2017, this style guide for Git was created that also includes the compliance with Git Flow. Generally this branching model is really dynamic and can help a larger team to keep the overview of different story implementations while being able to build and deploy version backports. Using develop as the main branch also helps to make sure the master branch always contains stable versions.

Anyway, the model also comes with disadvantages like the overhead of keeping both develop and master in sync when tagging a new release version. The main target groups for this model are larger teams that work on projects with legacy support.

I've adapted to Git Flow because I liked the idea of having one branch that reflects the actual development state, but after using it for over 6 years I don't see any advantages in it anymore compared to other great models like GitHub Flow. I've checked the original Git Flow blog post of Vincent Driessen again and was amazed that he recently (March 5, 2020) added an update at the top of the post that exactly matches my opinion regarding the fact that Git Flow is not suitable these days, comes with too much overhead and that he now recommends to use GitHub Flow instead:

Note of reflection (March 5, 2020)

This model was conceived in 2010, now more than 10 years ago, and not very long after Git itself came into being. In those 10 years, git-flow (the branching model laid out in this article) has become hugely popular in many a software team to the point where people have started treating it like a standard of sorts — but unfortunately also as a dogma or panacea.

During those 10 years, Git itself has taken the world by a storm, and the most popular type of software that is being developed with Git is shifting more towards web apps — at least in my filter bubble. Web apps are typically continuously delivered, not rolled back, and you don't have to support multiple versions of the software running in the wild.

This is not the class of software that I had in mind when I wrote the blog post 10 years ago. If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team.

If, however, you are building software that is explicitly versioned, or if you need to support multiple versions of your software in the wild, then git-flow may still be as good of a fit to your team as it has been to people in the last 10 years. In that case, please read on.

To conclude, always remember that panaceas don't exist. Consider your own context. Don't be hating. Decide for yourself.

This update perfectly reflects the way I thought about the Git Flow model quite a while now.
Therefore I've finally decided to switch to GitHub Flow and retire the good old develop in favor of master as the one and only single-source-of-truth™️.

Migration Tasks

Since all Arctic Ice Studio projects adhere to this guide each repository must gradually adapt to this change one after the other. Large projects like Nord with all of it's port projects will require a lot more time and effort to migrate regarding the goal and tooling compatibility of the actual project.
Smaller projects like my igloo dotfile repository, snowsaw as well as this style guide repository itself are way easier and can be done within the next few weeks.

To ensure the migration is documented and the status of each repository can be tracked, this issue will be kept open and used as umbrella ticket.

Private repositories are tracked internally as well on external (private) systems while the following affected public repositories and the corresponding issue are listed below.

From `master` to `main`

Many communities, like on GitHub and GitLab as well as the wider Git community, renamed the default branch from master to main.
Historically, the default name for this initial branch was master. This term came from Bitkeeper, a predecessor to Git. Bitkeeper referred to the source of truth as the "master repository" and other copies as "slave repositories". This shows how common master/slave references have been in technology, and the difficulty in knowing how the term master should be interpreted.
During the creation of the “Black Lives Matter“ initiative the demand to get rid of the master/slave naming got louder and louder and therefore large projects and platforms like GitHub/GitLab started made the first step and pushed towards this goal.
These organizations are not alone in the Git ecosystem: the Git project announced to adapt these changes and the latest Git versions using main as default branch name when initializing a new repository.

As of October 1, 2020 the the default branch for newly-created repositories is now main and GitLab will apply this change with on June 6. 2021.
To make the transition as easy and fast as possible, GitHub create the github/renaming repository that assists projects to gradually rename the default branch from master to main. The process should be as seamless as possible for project maintainers and all of their contributors so the repository is the up-to-date guidance on how and when to rename the default branch. In January 19, 2021 GitHub also introduced a new feature for the web platform that supports maintainers to rename any branch that automates some tasks and ensures that internal GitHub information is updated as well. GitHub also ensures that links to deleted branches are now also redirected to the default branch of a repository.

Migration Tasks

All Arctic Ice Studio and Sven Greb projects adhere to this guide so each repository will gradually adapt to this change one after the other. Large projects like Nord with all of it's port projects will require a lot more time and effort to migrate regarding the goal and tooling compatibility of the actual project.
Smaller projects like my igloo dotfile repository, snowsaw as well as this style guide repository itself are way easier and can be done within the next few weeks.

To ensure the migration is documented and the status of each repository can be tracked, this issue will be kept open and used as umbrella ticket.

Private repositories are tracked internally as well on external (private) systems while the following affected public repositories and the corresponding issue are listed below.

svengreb / styleguide-git Goto Github PK

styleguide-git's Issues

Branch naming conventions and guidelines

`svengreb` GitHub account migration

Initial style guide and project documentation

Tag naming conventions and guidelines

Migrate to MIT license

GitHub Flow migration

Historical Background

Note of reflection (March 5, 2020)

Migration Tasks

From `master` to `main`

Migration Tasks

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent