From 8c085eeb47120de86a7a6c8dac485d6c17ec6ee3 Mon Sep 17 00:00:00 2001 From: Scott Chamberlain Date: Mon, 21 Oct 2024 10:59:58 -0700 Subject: [PATCH 1/4] fix #33 add gitflow chapter --- _quarto.yml | 1 + gitflow.qmd | 65 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 66 insertions(+) create mode 100644 gitflow.qmd diff --git a/_quarto.yml b/_quarto.yml index 236ed45..1a42ad8 100644 --- a/_quarto.yml +++ b/_quarto.yml @@ -18,6 +18,7 @@ book: - index.qmd - contributing.qmd - style.qmd + - gitflow.qmd - part: codereview.qmd chapters: - codereview-dasl.qmd diff --git a/gitflow.qmd b/gitflow.qmd new file mode 100644 index 0000000..82f6508 --- /dev/null +++ b/gitflow.qmd @@ -0,0 +1,65 @@ +# Gitflow {{< iconify fa6-solid code-branch >}} {#sec-gitflow} + +[Git][git] is the version control system that underlies GitHub. Gitflow is an alternative git branching model that uses feature branches and multiple primary branches (vs one primary branch, e.g., "main"). + +Gitflow was originally proposed by [Vincent Driessen in 2010 on his blog][gitflowblog]. [A tutorial][gitflowtut] by the tech company Atlassian has a nice overview of Gitflow. + +In Gitflow there are two primary branches: `main` and `dev` (see diagram below). Feature branches always branch off of `dev`. After feature branches merge back into `dev`, then `dev` is merged into `main`. + +```{mermaid} +%%{init: { 'logLevel': 'debug', 'theme': 'default', 'themeVariables': { + 'git0': '#57bfd3', + 'git1': '#5F9157', + 'git2': '#f4b840', + 'git3': '#D26D6D' +} } }%% +gitGraph + commit tag: "v1.0" + commit + branch dev + checkout dev + commit + branch feature1 + checkout feature1 + commit + commit + checkout dev + branch feature2 + checkout feature2 + commit + commit + checkout dev + merge feature1 + checkout main + merge dev + commit tag: "v2.0" +``` + +There are formal tools for using a Gitflow model, e.g., [nvie/gitflow](https://github.com/nvie/gitflow). However, we aren't using that tool or any others at the moment. + +There are components of Gitflow that we do not use. They are: + +- Release branches +- Hotfix branches + +## WILDS considerations + +- One thing we may consider doing in the future is making the `dev` branch the default branch in all WILDS repos, but that is not a rule right now +- For WILDS repos following Gitflow, have a badge or something in the readme that gives info on Gitflow so contribs know? And/or put in CONTRIBUTING.md too? + +## Further reading + +(Taken from ) + +Reading: + +Screen casts: + +* [How to use a scalable Git branching model called git-flow](http://buildamodule.com/video/change-management-and-version-control-deploying-releases-features-and-fixes-with-git-how-to-use-a-scalable-git-branching-model-called-gitflow) (by Build a Module) +* [A short introduction to git-flow](http://vimeo.com/16018419) (by Mark Derricutt) + + + +[git]: https://git-scm.com/ +[gitflowblog]: https://nvie.com/posts/a-successful-git-branching-model/ +[gitflowtut]: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow From 3d181782816977c731816b8a6983a0a25ca9f10d Mon Sep 17 00:00:00 2001 From: Scott Chamberlain Date: Mon, 2 Dec 2024 13:47:51 -0800 Subject: [PATCH 2/4] changes following seans review --- gitflow.qmd | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/gitflow.qmd b/gitflow.qmd index 82f6508..6d44a0f 100644 --- a/gitflow.qmd +++ b/gitflow.qmd @@ -37,14 +37,13 @@ gitGraph There are formal tools for using a Gitflow model, e.g., [nvie/gitflow](https://github.com/nvie/gitflow). However, we aren't using that tool or any others at the moment. -There are components of Gitflow that we do not use. They are: +There are components of Gitflow that we do not use right now, but could be used as needed: - Release branches - Hotfix branches ## WILDS considerations -- One thing we may consider doing in the future is making the `dev` branch the default branch in all WILDS repos, but that is not a rule right now - For WILDS repos following Gitflow, have a badge or something in the readme that gives info on Gitflow so contribs know? And/or put in CONTRIBUTING.md too? ## Further reading From 8c64baffb93157ba56beee4f28a08d254bd50262 Mon Sep 17 00:00:00 2001 From: Scott Chamberlain Date: Wed, 4 Dec 2024 09:42:46 -0800 Subject: [PATCH 3/4] remove wilds considerations sectxion --- gitflow.qmd | 4 ---- 1 file changed, 4 deletions(-) diff --git a/gitflow.qmd b/gitflow.qmd index 6d44a0f..779a374 100644 --- a/gitflow.qmd +++ b/gitflow.qmd @@ -42,10 +42,6 @@ There are components of Gitflow that we do not use right now, but could be used - Release branches - Hotfix branches -## WILDS considerations - -- For WILDS repos following Gitflow, have a badge or something in the readme that gives info on Gitflow so contribs know? And/or put in CONTRIBUTING.md too? - ## Further reading (Taken from ) From c0d57342d1199c33d443bdeb6775e360b45186e6 Mon Sep 17 00:00:00 2001 From: Scott Chamberlain Date: Wed, 4 Dec 2024 12:24:49 -0800 Subject: [PATCH 4/4] gitflow ch: just not releas branches not used; pkg maint ch: link to gitflow ch --- gitflow.qmd | 5 +---- maintenance.qmd | 2 +- 2 files changed, 2 insertions(+), 5 deletions(-) diff --git a/gitflow.qmd b/gitflow.qmd index 779a374..e3edcd7 100644 --- a/gitflow.qmd +++ b/gitflow.qmd @@ -37,10 +37,7 @@ gitGraph There are formal tools for using a Gitflow model, e.g., [nvie/gitflow](https://github.com/nvie/gitflow). However, we aren't using that tool or any others at the moment. -There are components of Gitflow that we do not use right now, but could be used as needed: - -- Release branches -- Hotfix branches +There is one component of Gitflow that we do not use right now: release branches. ## Further reading diff --git a/maintenance.qmd b/maintenance.qmd index 80caf46..33af8b7 100644 --- a/maintenance.qmd +++ b/maintenance.qmd @@ -92,7 +92,7 @@ Overall the branching lifecycle can be summed up by the following: 4. Whenever project leads want to create a new release, they merge the `dev` branch into the `main` branch and tag a new release. 5. Urgent fixes to the `main` branch can be made by creating a branch from `main` that begins with the hotfix- prefix, which is then merged directly into `main` via pull request and code review. The `dev` branch will then be updated to reflect the changes on `main` via pull request. We should do our best to avoid this pattern. Since this changes the `main` branch, there will be a new tagged release. -We try to follow the principles set out in [Git Flow](https://nvie.com/posts/a-successful-git-branching-model/) with a few modifications: +We try to follow the principles set out in Gitflow (@sec-gitflow) with a few modifications: - We use the `main` branch instead of the `master` branch, and we use the `dev` branch instead of the `develop` branch. - We don’t use release branches, we create release tags from the `main` branch. Therefore we shouldn’t use the `release-` prefix at all.