Start deprecating university/ directory

We are moving all docs in university to better
locations. This MR moves git topics to topics/git

doc/topics/git/bisect.md

+---
+stage: none
+group: unassigned
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+comments: false
+---
+
+# Bisect
+
+- Find a commit that introduced a bug
+- Works through a process of elimination
+- Specify a known good and bad revision to begin
+
+## Bisect sample workflow
+
+1. Start the bisect process
+1. Enter the bad revision (usually latest commit)
+1. Enter a known good revision (commit/branch)
+1. Run code to see if bug still exists
+1. Tell bisect the result
+1. Repeat the previous 2 items until you find the offending commit
+
+## Setup
+
+```shell
+  mkdir bisect-ex
+  cd bisect-ex
+  touch index.html
+  git add -A
+  git commit -m "starting out"
+  vi index.html
+  # Add all good
+  git add -A
+  git commit -m "second commit"
+  vi index.html
+  # Add all good 2
+  git add -A
+  git commit -m "third commit"
+  vi index.html
+```
+
+```shell
+  # Add all good 3
+  git add -A
+  git commit -m "fourth commit"
+  vi index.html
+  # This looks bad
+  git add -A
+  git commit -m "fifth commit"
+  vi index.html
+  # Really bad
+  git add -A
+  git commit -m "sixth commit"
+  vi index.html
+  # again just bad
+  git add -A
+  git commit -m "seventh commit"
+```
+
+## Commands
+
+```shell
+  git bisect start
+  # Test your code
+  git bisect bad
+  git bisect next
+  # Say yes to the warning
+  # Test
+  git bisect good
+  # Test
+  git bisect bad
+  # Test
+  git bisect good
+  # done
+  git bisect reset
+```

doc/topics/git/feature_branching.md

+---
+stage: none
+group: unassigned
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+comments: false
+---
+
+# Feature branching
+
+- Efficient parallel workflow for teams
+- Develop each feature in a branch
+- Keeps changes isolated
+- Consider a 1-to-1 link to issues
+- Push branches to the server frequently
+  - Hint: This is a cheap backup for your work-in-progress code
+
+## Feature branching sample workflow
+
+1. Create a new feature branch called 'squash_some_bugs'
+1. Edit '`bugs.rb`' and remove all the bugs.
+1. Commit
+1. Push
+
+```shell
+git checkout -b squash_some_bugs
+# Edit `bugs.rb`
+git status
+git add bugs.rb
+git commit -m 'Fix some buggy code'
+git push origin squash_some_bugs
+```

doc/topics/git/getting_started.md

+---
+stage: none
+group: unassigned
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+comments: false
+---
+
+# Getting Started
+
+## Instantiating Repositories
+
+- Create a new repository by instantiating it through:
+
+  ```shell
+  git init
+  ```
+
+- Copy an existing project by cloning the repository through:
+
+  ```shell
+  git clone <url>
+  ```
+
+## Central Repositories
+
+- To instantiate a central repository a `--bare` flag is required.
+- Bare repositories don't allow file editing or committing changes.
+- Create a bare repository with:
+
+  ```shell
+  git init --bare project-name.git
+  ```
+
+## Instantiate workflow with clone
+
+1. Create a project in your user namespace.
+   - Choose to import from **Any Repository by URL** and use <https://gitlab.com/gitlab-org/training-examples.git>.
+1. Create a '`Workspace`' directory in your home directory.
+1. Clone the '`training-examples`' project.
+
+```shell
+mkdir ~/workspace
+cd ~/workspace
+
+git clone git@gitlab.example.com:<username>/training-examples.git
+cd training-examples
+```
+
+## Git concepts
+
+**Untracked files**
+
+New files that Git has not been told to track previously.
+
+**Working area**
+
+Files that have been modified but are not committed.
+
+**Staging area**
+
+Modified files that have been marked to go in the next commit.
+
+## Committing Workflow
+
+1. Edit '`edit_this_file.rb`' in '`training-examples`'
+1. See it listed as a changed file (working area)
+1. View the differences
+1. Stage the file
+1. Commit
+1. Push the commit to the remote
+1. View the Git log
+
+```shell
+# Edit `edit_this_file.rb`
+git status
+git diff
+git add <file>
+git commit -m 'My change'
+git push origin master
+git log
+```
+
+## Note
+
+- `git fetch` vs `git pull`
+- Pull is `git fetch` + `git merge`

doc/topics/git/git_add.md

+---
+stage: none
+group: unassigned
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+comments: false
+---
+
+# Git Add
+
+Adds content to the index or staging area.
+
+- Adds a list of file:
+
+  ```shell
+  git add <files>
+  ```
+
+- Adds all files including deleted ones:
+
+  ```shell
+  git add -A
+  ```
+
+- Add all text files in current dir:
+
+  ```shell
+  git add *.txt
+  ```
+
+- Add all text file in the project:
+
+  ```shell
+  git add "*.txt*"
+  ```
+
+- Adds all files in directory:
+
+  ```shell
+  git add views/layouts/
+  ```

doc/topics/git/git_log.md

+---
+stage: none
+group: unassigned
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+comments: false
+---
+
+# Git Log
+
+Git log lists commit history. It allows searching and filtering.
+
+- Initiate log:
+
+  ```shell
+  git log
+  ```
+
+- Retrieve set number of records:
+
+  ```shell
+  git log -n 2
+  ```
+
+- Search commits by author. Allows user name or a regular expression.
+
+  ```shell
+  git log --author="user_name"
+  ```
+
+- Search by comment message:
+
+  ```shell
+  git log --grep="<pattern>"
+  ```
+
+- Search by date:
+
+  ```shell
+  git log --since=1.month.ago --until=3.weeks.ago
+  ```
+
+## Git Log Workflow
+
+1. Change to workspace directory
+1. Clone the multi runner projects
+1. Change to project dir
+1. Search by author
+1. Search by date
+1. Combine
+
+## Commands
+
+```shell
+cd ~/workspace
+git clone git@gitlab.com:gitlab-org/gitlab-runner.git
+cd gitlab-runner
+git log --author="Travis"
+git log --since=1.month.ago --until=3.weeks.ago
+git log --since=1.month.ago --until=1.day.ago --author="Travis"
+```

doc/topics/git/index.md

@@ -39,7 +39,7 @@ The following resources can help you get started with Git:
   - [Squashing commits](../gitlab_flow.md#squashing-commits-with-rebase)
   - [Squash-and-merge](../../user/project/merge_requests/squash_and_merge.md)
   - [Signing commits](../../user/project/repository/gpg_signed_commits/index.md)
-- [Git stash](../../university/training/topics/stash.md)
+- [Git stash](stash.md)
 - [Git file blame](../../user/project/repository/git_blame.md)
 - [Git file history](../../user/project/repository/git_history.md)
 - [Git tags](tags.md)

doc/topics/git/merge_conflicts.md

+---
+stage: none
+group: unassigned
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+comments: false
+---
+
+# Merge conflicts
+
+- Happen often
+- Learning to fix conflicts is hard
+- Practice makes perfect
+- Force push after fixing conflicts. Be careful!
+
+## Merge conflicts sample workflow
+
+1. Checkout a new branch and edit `conflicts.rb`. Add 'Line4' and 'Line5'.
+1. Commit and push.
+1. Checkout master and edit `conflicts.rb`. Add 'Line6' and 'Line7' below 'Line3'.
+1. Commit and push to master.
+1. Create a merge request and watch it fail.
+1. Rebase our new branch with master.
+1. Fix conflicts on the `conflicts.rb` file.
+1. Stage the file and continue rebasing.
+1. Force push the changes.
+1. Finally continue with the Merge Request.
+
+```shell
+git checkout -b conflicts_branch
+
+# vi conflicts.rb
+# Add 'Line4' and 'Line5'
+
+git commit -am "add line4 and line5"
+git push origin conflicts_branch
+
+git checkout master
+
+# vi conflicts.rb
+# Add 'Line6' and 'Line7'
+git commit -am "add line6 and line7"
+git push origin master
+```
+
+Create a merge request on the GitLab web UI, and a conflict warning displays.
+
+```shell
+git checkout conflicts_branch
+git fetch
+git rebase master
+
+# Fix conflicts by editing the files.
+
+git add conflicts.rb
+# No need to commit this file
+
+git rebase --continue
+
+# Remember that we have rewritten our commit history so we
+# need to force push so that our remote branch is restructured
+git push origin conflicts_branch -f
+```
+
+## Note
+
+- When to use `git merge` and when to use `git rebase`
+- Rebase when updating your branch with master
+- Merge when bringing changes from feature to master
+- Reference: <https://www.atlassian.com/git/tutorials/merging-vs-rebasing>

doc/topics/git/merge_requests.md

+---
+stage: none
+group: unassigned
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+comments: false
+---
+
+# Code review and collaboration with Merge Requests
+
+- When you want feedback create a merge request
+- Target is the default branch (usually master)
+- Assign or mention the person you would like to review
+- Add `[Draft]` to the title if it's a work in progress
+- When accepting, always delete the branch
+- Anyone can comment, not just the assignee
+- Push corrections to the same branch
+
+## Merge requests
+
+**Create your first merge request**
+
+1. Use the blue button in the activity feed
+1. View the diff (changes) and leave a comment
+1. Push a new commit to the same branch
+1. Review the changes again and notice the update
+
+## Feedback and Collaboration
+
+- Merge requests are a time for feedback and collaboration
+- Giving feedback is hard
+- Be as kind as possible
+- Receiving feedback is hard
+- Be as receptive as possible
+- Feedback is about the best code, not the person. You are not your code
+
+Review the Thoughtbot code-review guide for suggestions to follow when reviewing merge requests:
+[https://github.com/thoughtbot/guides/tree/master/code-review](https://github.com/thoughtbot/guides/tree/master/code-review)
+
+See GitLab merge requests for examples:
+[https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests)

doc/topics/git/rollback_commits.md

+---
+stage: none
+group: unassigned
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+comments: false
+---
+
+# Rollback Commits
+
+## Undo Commits
+
+- Undo last commit putting everything back into the staging area:
+
+  ```shell
+  git reset --soft HEAD^
+  ```
+
+- Add files and change message with:
+
+  ```shell
+  git commit --amend -m "New Message"
+  ```
+
+- Undo last and remove changes:
+
+  ```shell
+  git reset --hard HEAD^
+  ```
+
+- Same as last one but for two commits back:
+
+  ```shell
+  git reset --hard HEAD^^
+  ```
+
+**Don't reset after pushing**
+
+## Reset Workflow
+
+1. Edit file again 'edit_this_file.rb'
+1. Check status
+1. Add and commit with wrong message
+1. Check log
+1. Amend commit
+1. Check log
+1. Soft reset
+1. Check log
+1. Pull for updates
+1. Push changes
+
+## Commands
+
+```shell
+# Change file edit_this_file.rb
+git status
+git commit -am "kjkfjkg"
+git log
+git commit --amend -m "New comment added"
+git log
+git reset --soft HEAD^
+git log
+git pull origin master
+git push origin master
+```
+
+## Note
+
+- `git revert` vs `git reset`
+- Reset removes the commit while revert removes the changes but leaves the commit
+- Revert is safer considering we can revert a revert
+
+```shell
+# Changed file
+git commit -am "bug introduced"
+git revert HEAD
+# New commit created reverting changes
+# Now we want to re apply the reverted commit
+git log # take hash from the revert commit
+git revert <rev commit hash>
+# reverted commit is back (new commit created again)
+```

doc/topics/git/stash.md

+---
+stage: none
+group: unassigned
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+comments: false
+---
+
+# Git Stash
+
+We use `git stash` to store our changes when they are not ready to be committed
+and we need to change to a different branch.
+
+- Stash:
+
+  ```shell
+  git stash save
+  # or
+  git stash
+  # or with a message
+  git stash save "this is a message to display on the list"
+  ```
+
+- Apply stash to keep working on it:
+
+  ```shell
+  git stash apply
+  # or apply a specific one from out stack
+  git stash apply stash@{3}
+  ```
+
+- Every time we save a stash it gets stacked so by using `list` we can see all our
+  stashes.
+
+  ```shell
+  git stash list
+  # or for more information (log methods)
+  git stash list --stat
+  ```
+
+- To clean our stack we need to manually remove them:
+
+  ```shell
+  # drop top stash
+  git stash drop
+  # or
+  git stash drop <name>
+  # to clear all history we can use
+  git stash clear
+  ```
+
+- Apply and drop on one command:
+
+  ```shell
+  git stash pop
+  ```
+
+- If we meet conflicts we need to either reset or commit our changes.
+- Conflicts through `pop` doesn't drop a stash afterwards.
+
+## Git Stash sample workflow
+
+1. Modify a file
+1. Stage file
+1. Stash it
+1. View our stash list
+1. Confirm no pending changes through status
+1. Apply with pop
+1. View list to confirm changes
+
+```shell
+# Modify edit_this_file.rb file
+git add .
+
+git stash save "Saving changes from edit this file"
+
+git stash list
+git status
+
+git stash pop
+git stash list
+git status
+```

doc/topics/git/subtree.md

+---
+stage: none
+group: unassigned
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+comments: false
+---
+
+# Subtree
+
+- Used when there are nested repositories.
+- Not recommended when the amount of dependencies is too large.
+- For these cases we need a dependency control system.
+- Command are painfully long so aliases are necessary.
+
+## Subtree Aliases
+
+- Add: `git subtree add --prefix <target-folder> <url> <branch> --squash`
+- Pull: `git subtree pull --prefix <target-folder> <url> <branch> --squash`
+- Push: `git subtree add --prefix <target-folder> <url> <branch>`
+- Ex: `git config alias.sbp 'subtree pull --prefix st /
+  git@gitlab.com:balameb/subtree-nested-example.git master --squash'`
+
+```shell
+  # Add an alias
+  # Add
+  git config alias.sba 'subtree add --prefix st /
+  git@gitlab.com:balameb/subtree-nested-example.git master --squash'
+  # Pull
+  git config alias.sbpl 'subtree pull --prefix st /
+  git@gitlab.com:balameb/subtree-nested-example.git master --squash'
+  # Push
+  git config alias.sbph 'subtree push --prefix st /
+  git@gitlab.com:balameb/subtree-nested-example.git master'
+
+  # Adding this subtree adds a st dir with a readme
+  git sba
+  vi st/README.md
+  # Edit file
+  git status shows differences
+
+```
+
+```shell
+  # Adding, or committing won't change the sub repo at remote
+  # even if we push
+  git add -A
+  git commit -m "Adding to subtree readme"
+
+  # Push to subtree repo
+  git sbph
+  # now we can check our remote sub repo
+```

doc/topics/git/unstage.md

+---
+stage: none
+group: unassigned
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+comments: false
+---
+
+# Unstage
+
+- To remove files from stage use reset HEAD where HEAD is the last commit of the current branch. This unstages the file but maintain the modifications.
+
+  ```shell
+  git reset HEAD <file>
+  ```
+
+- To revert the file back to the state it was in before the changes we can use:
+
+  ```shell
+  git checkout -- <file>
+  ```
+
+- To remove a file from disk and repository, use `git rm`. To remove a directory, use the `-r` flag:
+
+  ```shell
+  git rm '*.txt'
+  git rm -r <dirname>
+  ```
+
+- If we want to remove a file from the repository but keep it on disk, say we forgot to add it to our `.gitignore` file then use `--cache`:
+
+  ```shell
+  git rm <filename> --cache
+  ```

doc/university/training/topics/bisect.md

 ---
-stage: none
-group: unassigned
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
-comments: false
+redirect_to: '../../../topics/git/bisect.md'
 ---
 
-# Bisect
+This document was moved to [another location](../../../topics/git/bisect.md).
 
-- Find a commit that introduced a bug
-- Works through a process of elimination
-- Specify a known good and bad revision to begin
-
-## Bisect sample workflow
-
-1. Start the bisect process
-1. Enter the bad revision (usually latest commit)
-1. Enter a known good revision (commit/branch)
-1. Run code to see if bug still exists
-1. Tell bisect the result
-1. Repeat the previous 2 items until you find the offending commit
-
-## Setup
-
-```shell
-  mkdir bisect-ex
-  cd bisect-ex
-  touch index.html
-  git add -A
-  git commit -m "starting out"
-  vi index.html
-  # Add all good
-  git add -A
-  git commit -m "second commit"
-  vi index.html
-  # Add all good 2
-  git add -A
-  git commit -m "third commit"
-  vi index.html
-```
-
-```shell
-  # Add all good 3
-  git add -A
-  git commit -m "fourth commit"
-  vi index.html
-  # This looks bad
-  git add -A
-  git commit -m "fifth commit"
-  vi index.html
-  # Really bad
-  git add -A
-  git commit -m "sixth commit"
-  vi index.html
-  # again just bad
-  git add -A
-  git commit -m "seventh commit"
-```
-
-## Commands
-
-```shell
-  git bisect start
-  # Test your code
-  git bisect bad
-  git bisect next
-  # Say yes to the warning
-  # Test
-  git bisect good
-  # Test
-  git bisect bad
-  # Test
-  git bisect good
-  # done
-  git bisect reset
-```
+<!-- This redirect file can be deleted after <2021-08-13>. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->

doc/university/training/topics/feature_branching.md

 ---
-stage: none
-group: unassigned
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
-comments: false
+redirect_to: '../../../topics/git/feature_branching.md'
 ---
 
-# Feature branching
+This document was moved to [another location](../../../topics/git/feature_branching.md).
 
-- Efficient parallel workflow for teams
-- Develop each feature in a branch
-- Keeps changes isolated
-- Consider a 1-to-1 link to issues
-- Push branches to the server frequently
-  - Hint: This is a cheap backup for your work-in-progress code
-
-## Feature branching sample workflow
-
-1. Create a new feature branch called 'squash_some_bugs'
-1. Edit '`bugs.rb`' and remove all the bugs.
-1. Commit
-1. Push
-
-```shell
-git checkout -b squash_some_bugs
-# Edit `bugs.rb`
-git status
-git add bugs.rb
-git commit -m 'Fix some buggy code'
-git push origin squash_some_bugs
-```
+<!-- This redirect file can be deleted after <2021-08-13>. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->

doc/university/training/topics/getting_started.md

 ---
-stage: none
-group: unassigned
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
-comments: false
+redirect_to: '../../../topics/git/getting_started.md'
 ---
 
-# Getting Started
+This document was moved to [another location](../../../topics/git/getting_started.md).
 
-## Instantiating Repositories
-
-- Create a new repository by instantiating it through:
-
-  ```shell
-  git init
-  ```
-
-- Copy an existing project by cloning the repository through:
-
-  ```shell
-  git clone <url>
-  ```
-
-## Central Repositories
-
-- To instantiate a central repository a `--bare` flag is required.
-- Bare repositories don't allow file editing or committing changes.
-- Create a bare repository with:
-
-  ```shell
-  git init --bare project-name.git
-  ```
-
-## Instantiate workflow with clone
-
-1. Create a project in your user namespace.
-   - Choose to import from **Any Repository by URL** and use <https://gitlab.com/gitlab-org/training-examples.git>.
-1. Create a '`Workspace`' directory in your home directory.
-1. Clone the '`training-examples`' project.
-
-```shell
-mkdir ~/workspace
-cd ~/workspace
-
-git clone git@gitlab.example.com:<username>/training-examples.git
-cd training-examples
-```
-
-## Git concepts
-
-**Untracked files**
-
-New files that Git has not been told to track previously.
-
-**Working area**
-
-Files that have been modified but are not committed.
-
-**Staging area**
-
-Modified files that have been marked to go in the next commit.
-
-## Committing Workflow
-
-1. Edit '`edit_this_file.rb`' in '`training-examples`'
-1. See it listed as a changed file (working area)
-1. View the differences
-1. Stage the file
-1. Commit
-1. Push the commit to the remote
-1. View the Git log
-
-```shell
-# Edit `edit_this_file.rb`
-git status
-git diff
-git add <file>
-git commit -m 'My change'
-git push origin master
-git log
-```
-
-## Note
-
-- `git fetch` vs `git pull`
-- Pull is `git fetch` + `git merge`
+<!-- This redirect file can be deleted after <2021-08-13>. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->

doc/university/training/topics/git_add.md

 ---
-stage: none
-group: unassigned
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
-comments: false
+redirect_to: '../../../topics/git/git_add.md'
 ---
 
-# Git Add
+This document was moved to [another location](../../../topics/git/git_add.md).
 
-Adds content to the index or staging area.
-
-- Adds a list of file:
-
-  ```shell
-  git add <files>
-  ```
-
-- Adds all files including deleted ones:
-
-  ```shell
-  git add -A
-  ```
-
-- Add all text files in current dir:
-
-  ```shell
-  git add *.txt
-  ```
-
-- Add all text file in the project:
-
-  ```shell
-  git add "*.txt*"
-  ```
-
-- Adds all files in directory:
-
-  ```shell
-  git add views/layouts/
-  ```
+<!-- This redirect file can be deleted after <2021-08-13>. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->

doc/university/training/topics/git_log.md

 ---
-stage: none
-group: unassigned
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
-comments: false
+redirect_to: '../../../topics/git/git_log.md'
 ---
 
-# Git Log
+This document was moved to [another location](../../../topics/git/git_log.md).
 
-Git log lists commit history. It allows searching and filtering.
-
-- Initiate log:
-
-  ```shell
-  git log
-  ```
-
-- Retrieve set number of records:
-
-  ```shell
-  git log -n 2
-  ```
-
-- Search commits by author. Allows user name or a regular expression.
-
-  ```shell
-  git log --author="user_name"
-  ```
-
-- Search by comment message:
-
-  ```shell
-  git log --grep="<pattern>"
-  ```
-
-- Search by date:
-
-  ```shell
-  git log --since=1.month.ago --until=3.weeks.ago
-  ```
-
-## Git Log Workflow
-
-1. Change to workspace directory
-1. Clone the multi runner projects
-1. Change to project dir
-1. Search by author
-1. Search by date
-1. Combine
-
-## Commands
-
-```shell
-cd ~/workspace
-git clone git@gitlab.com:gitlab-org/gitlab-runner.git
-cd gitlab-runner
-git log --author="Travis"
-git log --since=1.month.ago --until=3.weeks.ago
-git log --since=1.month.ago --until=1.day.ago --author="Travis"
-```
+<!-- This redirect file can be deleted after <2021-08-13>. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->

doc/university/training/topics/merge_conflicts.md

 ---
-stage: none
-group: unassigned
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
-comments: false
+redirect_to: '../../../topics/git/merge_conflicts.md'
 ---
 
-# Merge conflicts
+This document was moved to [another location](../../../topics/git/merge_conflicts.md).
 
-- Happen often
-- Learning to fix conflicts is hard
-- Practice makes perfect
-- Force push after fixing conflicts. Be careful!
-
-## Merge conflicts sample workflow
-
-1. Checkout a new branch and edit `conflicts.rb`. Add 'Line4' and 'Line5'.
-1. Commit and push.
-1. Checkout master and edit `conflicts.rb`. Add 'Line6' and 'Line7' below 'Line3'.
-1. Commit and push to master.
-1. Create a merge request and watch it fail.
-1. Rebase our new branch with master.
-1. Fix conflicts on the `conflicts.rb` file.
-1. Stage the file and continue rebasing.
-1. Force push the changes.
-1. Finally continue with the Merge Request.
-
-```shell
-git checkout -b conflicts_branch
-
-# vi conflicts.rb
-# Add 'Line4' and 'Line5'
-
-git commit -am "add line4 and line5"
-git push origin conflicts_branch
-
-git checkout master
-
-# vi conflicts.rb
-# Add 'Line6' and 'Line7'
-git commit -am "add line6 and line7"
-git push origin master
-```
-
-Create a merge request on the GitLab web UI, and a conflict warning displays.
-
-```shell
-git checkout conflicts_branch
-git fetch
-git rebase master
-
-# Fix conflicts by editing the files.
-
-git add conflicts.rb
-# No need to commit this file
-
-git rebase --continue
-
-# Remember that we have rewritten our commit history so we
-# need to force push so that our remote branch is restructured
-git push origin conflicts_branch -f
-```
-
-## Note
-
-- When to use `git merge` and when to use `git rebase`
-- Rebase when updating your branch with master
-- Merge when bringing changes from feature to master
-- Reference: <https://www.atlassian.com/git/tutorials/merging-vs-rebasing>
+<!-- This redirect file can be deleted after <2021-08-13>. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->

doc/university/training/topics/merge_requests.md

 ---
-stage: none
-group: unassigned
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
-comments: false
+redirect_to: '../../../topics/git/merge_requests.md'
 ---
 
-# Code review and collaboration with Merge Requests
+This document was moved to [another location](../../../topics/git/merge_requests.md).
 
-- When you want feedback create a merge request
-- Target is the default branch (usually master)
-- Assign or mention the person you would like to review
-- Add `[Draft]` to the title if it's a work in progress
-- When accepting, always delete the branch
-- Anyone can comment, not just the assignee
-- Push corrections to the same branch
-
-## Merge requests
-
-**Create your first merge request**
-
-1. Use the blue button in the activity feed
-1. View the diff (changes) and leave a comment
-1. Push a new commit to the same branch
-1. Review the changes again and notice the update
-
-## Feedback and Collaboration
-
-- Merge requests are a time for feedback and collaboration
-- Giving feedback is hard
-- Be as kind as possible
-- Receiving feedback is hard
-- Be as receptive as possible
-- Feedback is about the best code, not the person. You are not your code
-
-Review the Thoughtbot code-review guide for suggestions to follow when reviewing merge requests:
-[https://github.com/thoughtbot/guides/tree/master/code-review](https://github.com/thoughtbot/guides/tree/master/code-review)
-
-See GitLab merge requests for examples:
-[https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests)
+<!-- This redirect file can be deleted after <2021-08-13>. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->

doc/university/training/topics/rollback_commits.md

 ---
-stage: none
-group: unassigned
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
-comments: false
+redirect_to: '../../../topics/git/rollback_commits.md'
 ---
 
-# Rollback Commits
+This document was moved to [another location](../../../topics/git/rollback_commits.md).
 
-## Undo Commits
-
-- Undo last commit putting everything back into the staging area:
-
-  ```shell
-  git reset --soft HEAD^
-  ```
-
-- Add files and change message with:
-
-  ```shell
-  git commit --amend -m "New Message"
-  ```
-
-- Undo last and remove changes:
-
-  ```shell
-  git reset --hard HEAD^
-  ```
-
-- Same as last one but for two commits back:
-
-  ```shell
-  git reset --hard HEAD^^
-  ```
-
-**Don't reset after pushing**
-
-## Reset Workflow
-
-1. Edit file again 'edit_this_file.rb'
-1. Check status
-1. Add and commit with wrong message
-1. Check log
-1. Amend commit
-1. Check log
-1. Soft reset
-1. Check log
-1. Pull for updates
-1. Push changes
-
-## Commands
-
-```shell
-# Change file edit_this_file.rb
-git status
-git commit -am "kjkfjkg"
-git log
-git commit --amend -m "New comment added"
-git log
-git reset --soft HEAD^
-git log
-git pull origin master
-git push origin master
-```
-
-## Note
-
-- `git revert` vs `git reset`
-- Reset removes the commit while revert removes the changes but leaves the commit
-- Revert is safer considering we can revert a revert
-
-```shell
-# Changed file
-git commit -am "bug introduced"
-git revert HEAD
-# New commit created reverting changes
-# Now we want to re apply the reverted commit
-git log # take hash from the revert commit
-git revert <rev commit hash>
-# reverted commit is back (new commit created again)
-```
+<!-- This redirect file can be deleted after <2021-08-13>. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->

doc/university/training/topics/stash.md

 ---
-stage: none
-group: unassigned
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
-comments: false
+redirect_to: '../../../topics/git/stash.md'
 ---
 
-# Git Stash
+This document was moved to [another location](../../../topics/git/stash.md).
 
-We use `git stash` to store our changes when they are not ready to be committed
-and we need to change to a different branch.
-
-- Stash:
-
-  ```shell
-  git stash save
-  # or
-  git stash
-  # or with a message
-  git stash save "this is a message to display on the list"
-  ```
-
-- Apply stash to keep working on it:
-
-  ```shell
-  git stash apply
-  # or apply a specific one from out stack
-  git stash apply stash@{3}
-  ```
-
-- Every time we save a stash it gets stacked so by using `list` we can see all our
-  stashes.
-
-  ```shell
-  git stash list
-  # or for more information (log methods)
-  git stash list --stat
-  ```
-
-- To clean our stack we need to manually remove them:
-
-  ```shell
-  # drop top stash
-  git stash drop
-  # or
-  git stash drop <name>
-  # to clear all history we can use
-  git stash clear
-  ```
-
-- Apply and drop on one command:
-
-  ```shell
-  git stash pop
-  ```
-
-- If we meet conflicts we need to either reset or commit our changes.
-- Conflicts through `pop` doesn't drop a stash afterwards.
-
-## Git Stash sample workflow
-
-1. Modify a file
-1. Stage file
-1. Stash it
-1. View our stash list
-1. Confirm no pending changes through status
-1. Apply with pop
-1. View list to confirm changes
-
-```shell
-# Modify edit_this_file.rb file
-git add .
-
-git stash save "Saving changes from edit this file"
-
-git stash list
-git status
-
-git stash pop
-git stash list
-git status
-```
+<!-- This redirect file can be deleted after <2021-08-13>. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->

doc/university/training/topics/subtree.md

 ---
-stage: none
-group: unassigned
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
-comments: false
+redirect_to: '../../../topics/git/subtree.md'
 ---
 
-# Subtree
+This document was moved to [another location](../../../topics/git/subtree.md).
 
-- Used when there are nested repositories.
-- Not recommended when the amount of dependencies is too large.
-- For these cases we need a dependency control system.
-- Command are painfully long so aliases are necessary.
-
-## Subtree Aliases
-
-- Add: `git subtree add --prefix <target-folder> <url> <branch> --squash`
-- Pull: `git subtree pull --prefix <target-folder> <url> <branch> --squash`
-- Push: `git subtree add --prefix <target-folder> <url> <branch>`
-- Ex: `git config alias.sbp 'subtree pull --prefix st /
-  git@gitlab.com:balameb/subtree-nested-example.git master --squash'`
-
-```shell
-  # Add an alias
-  # Add
-  git config alias.sba 'subtree add --prefix st /
-  git@gitlab.com:balameb/subtree-nested-example.git master --squash'
-  # Pull
-  git config alias.sbpl 'subtree pull --prefix st /
-  git@gitlab.com:balameb/subtree-nested-example.git master --squash'
-  # Push
-  git config alias.sbph 'subtree push --prefix st /
-  git@gitlab.com:balameb/subtree-nested-example.git master'
-
-  # Adding this subtree adds a st dir with a readme
-  git sba
-  vi st/README.md
-  # Edit file
-  git status shows differences
-
-```
-
-```shell
-  # Adding, or committing won't change the sub repo at remote
-  # even if we push
-  git add -A
-  git commit -m "Adding to subtree readme"
-
-  # Push to subtree repo
-  git sbph
-  # now we can check our remote sub repo
-```
+<!-- This redirect file can be deleted after <2021-08-13>. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->

doc/university/training/topics/unstage.md

 ---
-stage: none
-group: unassigned
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
-comments: false
+redirect_to: '../../../topics/git/unstage.md'
 ---
 
-# Unstage
+This document was moved to [another location](../../../topics/git/unstage.md).
 
-- To remove files from stage use reset HEAD where HEAD is the last commit of the current branch. This unstages the file but maintain the modifications.
-
-  ```shell
-  git reset HEAD <file>
-  ```
-
-- To revert the file back to the state it was in before the changes we can use:
-
-  ```shell
-  git checkout -- <file>
-  ```
-
-- To remove a file from disk and repository, use `git rm`. To remove a directory, use the `-r` flag:
-
-  ```shell
-  git rm '*.txt'
-  git rm -r <dirname>
-  ```
-
-- If we want to remove a file from the repository but keep it on disk, say we forgot to add it to our `.gitignore` file then use `--cache`:
-
-  ```shell
-  git rm <filename> --cache
-  ```
+<!-- This redirect file can be deleted after <2021-08-13>. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->

doc/user/project/repository/branches/index.md

@@ -40,7 +40,7 @@ You can also manage branches using the
 See also:
 
 - [Branches API](../../../../api/branches.md), for information on operating on repository branches using the GitLab API.
-- [GitLab Flow](../../../../university/training/gitlab_flow.md) documentation.
+- [GitLab Flow](../../../../topics/gitlab_flow.md) documentation.
 - [Getting started with Git](../../../../topics/git/index.md) and GitLab.
 
 ## Compare