From 1abc9b813405d4e47adf875d4c123ebb0a32743f Mon Sep 17 00:00:00 2001 From: Mike Lockhart <mlockhart@gitlab.com> Date: Tue, 15 Feb 2022 13:02:08 +0000 Subject: [PATCH] Update stale GitHub Flow link, and link anchors GitHub moved their GitHub Flow documentation to a new documentation site Some of the links did not follow WCAG/GitLab documentation guidelines. --- doc/topics/gitlab_flow.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/topics/gitlab_flow.md b/doc/topics/gitlab_flow.md index b6206b301f7dc..3bca33b32b7d4 100644 --- a/doc/topics/gitlab_flow.md +++ b/doc/topics/gitlab_flow.md @@ -71,7 +71,7 @@ For example, many projects do releases but don't need to do hotfixes. ## GitHub flow as a simpler alternative In reaction to Git flow, GitHub created a simpler alternative. -[GitHub flow](https://guides.github.com/introduction/flow/index.html) has only feature branches and a `main` branch: +[GitHub flow](https://docs.github.com/en/get-started/quickstart/github-flow) has only feature branches and a `main` branch: ```mermaid graph TD @@ -341,7 +341,7 @@ However, as discussed in [the section about rebasing](#squashing-commits-with-re Rebasing could create more work, as every time you rebase, you may need to resolve the same conflicts. Sometimes you can reuse recorded resolutions (`rerere`), but merging is better, because you only have to resolve conflicts once. -Atlassian has a more thorough explanation of the tradeoffs between merging and rebasing [on their blog](https://www.atlassian.com/blog/git/git-team-workflows-merge-or-rebase). +Atlassian has [a more thorough explanation of the tradeoffs between merging and rebasing](https://www.atlassian.com/blog/git/git-team-workflows-merge-or-rebase) on their blog. A good way to prevent creating many merge commits is to not frequently merge `main` into the feature branch. There are three reasons to merge in `main`: utilizing new code, resolving merge conflicts, and updating long-running branches. @@ -403,7 +403,7 @@ git commit -m 'Properly escape special characters in XML generation' An example of a good commit message is: "Combine templates to reduce duplicate code in the user views." The words "change," "improve," "fix," and "refactor" don't add much information to a commit message. -For more information about formatting commit messages, please see this excellent [blog post by Tim Pope](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html). +For more information, please see Tim Pope's excellent [note about formatting commit messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html). To add more context to a commit message, consider adding information regarding the origin of the change. For example, the URL of a GitLab issue, or a Jira issue number, -- GitLab