Commit c2e66c1c authored by Marcia Ramos's avatar Marcia Ramos

Merge branch 'docs-code-block-style-6' into 'master'

Fix whitespace in topic, university, workflow docs

See merge request gitlab-org/gitlab-ce!30603
parents ebfa2b49 298252bb
......@@ -110,21 +110,21 @@ At this point there are 3 options to undo the local changes you have:
- Discard all local changes, but save them for possible re-use [later](#quickly-save-local-changes):
```shell
git stash
```
```shell
git stash
```
- Discarding local changes (permanently) to a file:
```shell
git checkout -- <file>
```
```shell
git checkout -- <file>
```
- Discard all local changes to all files permanently:
```shell
git reset --hard
```
```shell
git reset --hard
```
Before executing `git reset --hard`, keep in mind that there is also a way to
just temporary store the changes without committing them using `git stash`.
......@@ -182,27 +182,27 @@ Now you have 4 options to undo your changes:
- Unstage the file to current commit (HEAD):
```shell
git reset HEAD <file>
```
```shell
git reset HEAD <file>
```
- Unstage everything - retain changes:
```shell
git reset
```
```shell
git reset
```
- Discard all local changes, but save them for [later](#quickly-save-local-changes):
```shell
git stash
```
```shell
git stash
```
- Discard everything permanently:
```shell
git reset --hard
```
```shell
git reset --hard
```
## Committed local changes
......@@ -240,21 +240,21 @@ In our example we will end up with commit `B`, that introduced bug/error. We hav
- Undo (swap additions and deletions) changes introduced by commit `B`:
```shell
git revert commit-B-id
```
```shell
git revert commit-B-id
```
- Undo changes on a single file or directory from commit `B`, but retain them in the staged state:
```shell
git checkout commit-B-id <file>
```
```shell
git checkout commit-B-id <file>
```
- Undo changes on a single file or directory from commit `B`, but retain them in the unstaged state:
```shell
git reset commit-B-id <file>
```
```shell
git reset commit-B-id <file>
```
- There is one command we also must not forget: **creating a new branch**
from the point where changes are not applicable or where the development has hit a
......@@ -270,14 +270,14 @@ In our example we will end up with commit `B`, that introduced bug/error. We hav
you can [cherry-pick](../../../user/project/merge_requests/cherry_pick_changes.md#cherry-picking-a-commit)
that commit into a new merge request.
![Create a new branch to avoid clashing](img/branching.png)
![Create a new branch to avoid clashing](img/branching.png)
```shell
git checkout commit-B-id
git checkout -b new-path-of-feature
# Create <commit F>
git commit -a
```
```shell
git checkout commit-B-id
git checkout -b new-path-of-feature
# Create <commit F>
git commit -a
```
### With history modification
......@@ -297,9 +297,9 @@ delete commit `B`.
- Rebase the range from current commit D to A:
```shell
git rebase -i A
```
```shell
git rebase -i A
```
- Command opens your favorite editor where you write `drop` in front of commit
`B`, but you leave default `pick` with all other commits. Save and exit the
......@@ -310,9 +310,9 @@ In case you want to modify something introduced in commit `B`.
- Rebase the range from current commit D to A:
```shell
git rebase -i A
```
```shell
git rebase -i A
```
- Command opens your favorite text editor where you write `edit` in front of commit
`B`, but leave default `pick` with all other commits. Save and exit the editor to
......@@ -320,9 +320,9 @@ In case you want to modify something introduced in commit `B`.
- Now do your edits and commit changes:
```shell
git commit -a
```
```shell
git commit -a
```
You can find some more examples in [below section where we explain how to modify
history](#how-modifying-history-is-done)
......
......@@ -51,11 +51,11 @@ Configuring *both* the client and the server is unnecessary.
- On UNIX, edit `~/.ssh/config` (create the file if it doesn’t exist) and
add or edit:
```text
Host your-gitlab-instance-url.com
ServerAliveInterval 60
ServerAliveCountMax 5
```
```text
Host your-gitlab-instance-url.com
ServerAliveInterval 60
ServerAliveCountMax 5
```
- On Windows, if you are using PuTTY, go to your session properties, then
navigate to "Connection" and under "Sending of null packets to keep
......
......@@ -54,6 +54,7 @@ project.
---
## Git Setup
Workshop Time!
---
......@@ -88,7 +89,7 @@ git config --global --list
```
- You might want or be required to use an SSH key.
- Instructions: [SSH](http://doc.gitlab.com/ce/ssh/README.html)
- Instructions: [SSH](http://doc.gitlab.com/ce/ssh/README.html)
---
......@@ -119,13 +120,13 @@ cd ~/workspace
### Git Workflow
- Untracked files
- New files that Git has not been told to track previously.
- New files that Git has not been told to track previously.
- Working area (Workspace)
- Files that have been modified but are not committed.
- Files that have been modified but are not committed.
- Staging area (Index)
- Modified files that have been marked to go in the next commit.
- Modified files that have been marked to go in the next commit.
- Upstream
- Hosted repository on a shared server
- Hosted repository on a shared server
---
......@@ -229,8 +230,6 @@ git push origin squash_some_bugs
---
### Feedback and Collaboration
- Review the Thoughtbot code-review guide for suggestions to follow when reviewing merge requests:[Thoughtbot](https://github.com/thoughtbot/guides/tree/master/code-review)
- See GitLab merge requests for examples: [Merge Requests](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests)
......@@ -266,20 +265,22 @@ git push origin squash_some_bugs
### Example 1/2
git checkout -b conflicts_branch
```sh
git checkout -b conflicts_branch
# vi conflicts.rb
# Add 'Line4' and 'Line5'
# vi conflicts.rb
# Add 'Line4' and 'Line5'
git commit -am "add line4 and line5"
git push origin conflicts_branch
git commit -am "add line4 and line5"
git push origin conflicts_branch
git checkout master
git checkout master
# vi conflicts.rb
# Add 'Line6' and 'Line7'
git commit -am "add line6 and line7"
git push origin master
# vi conflicts.rb
# Add 'Line6' and 'Line7'
git commit -am "add line6 and line7"
git push origin master
```
---
......@@ -287,20 +288,22 @@ git push origin squash_some_bugs
Create a merge request on the GitLab web UI. You'll see a conflict warning.
git checkout conflicts_branch
git fetch
git rebase master
```sh
git checkout conflicts_branch
git fetch
git rebase master
# Fix conflicts by editing the files.
# Fix conflicts by editing the files.
git add conflicts.rb
# No need to commit this file
git add conflicts.rb
# No need to commit this file
git rebase --continue
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
# 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
```
---
......@@ -321,20 +324,28 @@ Create a merge request on the GitLab web UI. You'll see a conflict warning.
To remove files from stage use reset HEAD. Where HEAD is the last commit of the current branch:
git reset HEAD <file>
```sh
git reset HEAD <file>
```
This will unstage the file but maintain the modifications. To revert the file back to the state it was in before the changes we can use:
git checkout -- <file>
```sh
git checkout -- <file>
```
To remove a file from disk and repo use 'git rm' and to rm a dir use the '-r' flag:
git rm '*.txt'
git rm -r <dirname>
```sh
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`:
git rm <filename> --cache
```sh
git rm <filename> --cache
```
---
......@@ -342,19 +353,27 @@ If we want to remove a file from the repository but keep it on disk, say we forg
Undo last commit putting everything back into the staging area:
git reset --soft HEAD^
```sh
git reset --soft HEAD^
```
Add files and change message with:
git commit --amend -m "New Message"
```sh
git commit --amend -m "New Message"
```
Undo last and remove changes
git reset --hard HEAD^
```sh
git reset --hard HEAD^
```
Same as last one but for two commits back:
git reset --hard HEAD^^
```sh
git reset --hard HEAD^^
```
Don't reset after pushing
......@@ -373,35 +392,38 @@ Don't reset after pushing
1. Pull for updates
1. Push changes
----
---
# 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
```sh
# 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
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
# 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)
```sh
# 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)
```
---
......@@ -415,11 +437,11 @@ Revert is safer considering we can revert a revert
### Version Control
- Local VCS was used with a filesystem or a simple db.
- Centralized VCS such as Subversion includes collaboration but
still is prone to data loss as the main server is the single point of
failure.
- Distributed VCS enables the team to have a complete copy of the project
and work with little dependency to the main server. In case of a main
server failing the project can be recovered by any of the latest copies
from the team
- Local VCS was used with a filesystem or a simple db.
- Centralized VCS such as Subversion includes collaboration but
still is prone to data loss as the main server is the single point of
failure.
- Distributed VCS enables the team to have a complete copy of the project
and work with little dependency to the main server. In case of a main
server failing the project can be recovered by any of the latest copies
from the team
......@@ -10,32 +10,32 @@ Adds content to the index or staging area.
- Adds a list of file:
```bash
git add <files>
```
```bash
git add <files>
```
- Adds all files including deleted ones:
```bash
git add -A
```
```bash
git add -A
```
## Git add continued
- Add all text files in current dir:
```bash
git add *.txt
```
```bash
git add *.txt
```
- Add all text file in the project:
```bash
git add "*.txt*"
```
```bash
git add "*.txt*"
```
- Adds all files in directory:
```bash
git add views/layouts/
```
```bash
git add views/layouts/
```
......@@ -8,33 +8,33 @@ Git log lists commit history. It allows searching and filtering.
- Initiate log:
```sh
git log
```
```sh
git log
```
- Retrieve set number of records:
```sh
git log -n 2
```
```sh
git log -n 2
```
- Search commits by author. Allows user name or a regular expression.
```sh
git log --author="user_name"
```
```sh
git log --author="user_name"
```
- Search by comment message:
```sh
git log --grep="<pattern>"
```
```sh
git log --grep="<pattern>"
```
- Search by date:
```sh
git log --since=1.month.ago --until=3.weeks.ago
```
```sh
git log --since=1.month.ago --until=3.weeks.ago
```
## Git Log Workflow
......
......@@ -8,29 +8,29 @@ comments: false
- Undo last commit putting everything back into the staging area:
```sh
git reset --soft HEAD^
```
```sh
git reset --soft HEAD^
```
- Add files and change message with:
```sh
git commit --amend -m "New Message"
```
```sh
git commit --amend -m "New Message"
```
- Undo last and remove changes:
```sh
git reset --hard HEAD^
```
```sh
git reset --hard HEAD^
```
- Same as last one but for two commits back:
```sh
git reset --hard HEAD^^
```
```sh
git reset --hard HEAD^^
```
** Don't reset after pushing **
**Don't reset after pushing**
## Reset Workflow
......
......@@ -9,47 +9,47 @@ and we need to change to a different branch.
- Stash:
```sh
git stash save
# or
git stash
# or with a message
git stash save "this is a message to display on the list"
```
```sh
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:
```sh
git stash apply
# or apply a specific one from out stack
git stash apply stash@{3}
```
```sh
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.
```sh
git stash list
# or for more information (log methods)
git stash list --stat
```
```sh
git stash list
# or for more information (log methods)
git stash list --stat
```
- To clean our stack we need to manually remove them:
```sh
# drop top stash
git stash drop
# or
git stash drop <name>
# to clear all history we can use
git stash clear
```
```sh
# 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:
```sh
git stash pop
```
```sh
git stash pop
```
- If we meet conflicts we need to either reset or commit our changes.
- Conflicts through `pop` will not drop a stash afterwards.
......
......@@ -6,27 +6,27 @@ comments: false
## Unstage
- To remove files from stage use reset HEAD where HEAD is the last commit of the current branch. This will unstage the file but maintain the modifications.
- To remove files from stage use reset HEAD where HEAD is the last commit of the current branch. This will unstage the file but maintain the modifications.
```bash
git reset HEAD <file>
```
```bash
git reset HEAD <file>
```
- To revert the file back to the state it was in before the changes we can use:
```bash
git checkout -- <file>
```
```bash
git checkout -- <file>
```
- To remove a file from disk and repo use 'git rm' and to rm a dir use the '-r' flag:
```sh
git rm '*.txt'
git rm -r <dirname>
```
```sh
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`:
```sh
git rm <filename> --cache
```
```sh
git rm <filename> --cache
```
......@@ -72,15 +72,15 @@ need to enable the bundled PostgreSQL:
1. Stop GitLab:
```bash
sudo gitlab-ctl stop
```
```bash
sudo gitlab-ctl stop
```
1. Edit `/etc/gitlab/gitlab.rb` to enable bundled PostgreSQL:
```
postgresql['enable'] = true
```
```
postgresql['enable'] = true
```
1. Edit `/etc/gitlab/gitlab.rb` to use the bundled PostgreSQL. Please check
all the settings beginning with `db_`, such as `gitlab_rails['db_adapter']`
......@@ -91,22 +91,22 @@ need to enable the bundled PostgreSQL:
for the changes to take effect.
1. Start Unicorn and PostgreSQL so that we can prepare the schema:
```bash
sudo gitlab-ctl start unicorn
sudo gitlab-ctl start postgresql
```
```bash
sudo gitlab-ctl start unicorn
sudo gitlab-ctl start postgresql
```
1. Run the following commands to prepare the schema:
```bash
sudo gitlab-rake db:create db:migrate
```
```bash
sudo gitlab-rake db:create db:migrate
```
1. Stop Unicorn to prevent other database access from interfering with the loading of data:
```bash
sudo gitlab-ctl stop unicorn
```
```bash
sudo gitlab-ctl stop unicorn
```
After these steps, you'll have a fresh PostgreSQL database with up-to-date schema.
......@@ -116,57 +116,57 @@ new PostgreSQL one:
1. Save the following snippet in a `commands.load` file, and edit with your
MySQL database `username`, `password` and `host`:
```
LOAD DATABASE
FROM mysql://username:password@host/gitlabhq_production
INTO postgresql://gitlab-psql@unix://var/opt/gitlab/postgresql:/gitlabhq_production
```
LOAD DATABASE
FROM mysql://username:password@host/gitlabhq_production
INTO postgresql://gitlab-psql@unix://var/opt/gitlab/postgresql:/gitlabhq_production
WITH include no drop, truncate, disable triggers, create no tables,
create no indexes, preserve index names, no foreign keys,
data only
WITH include no drop, truncate, disable triggers, create no tables,
create no indexes, preserve index names, no foreign keys,
data only
ALTER SCHEMA 'gitlabhq_production' RENAME TO 'public'
ALTER SCHEMA 'gitlabhq_production' RENAME TO 'public'
;
```
;
```
1. Start the migration:
```bash
sudo -u gitlab-psql pgloader commands.load
```
```bash
sudo -u gitlab-psql pgloader commands.load
```
1. Once the migration finishes, you should see a summary table that looks like
the following:
```
table name read imported errors total time
----------------------------------------------- --------- --------- --------- --------------
fetch meta data 119 119 0 0.388s
Truncate 119 119 0 1.134s
----------------------------------------------- --------- --------- --------- --------------
public.abuse_reports 0 0 0 0.490s
public.appearances 0 0 0 0.488s
.
.
.
public.web_hook_logs 0 0 0 1.080s
----------------------------------------------- --------- --------- --------- --------------
COPY Threads Completion 4 4 0 2.008s
Reset Sequences 113 113 0 0.304s
Install Comments 0 0 0 0.000s
----------------------------------------------- --------- --------- --------- --------------
Total import time 1894 1894 0 12.497s
```
If there is no output for more than 30 minutes, it's possible `pgloader` encountered an error. See
the [troubleshooting guide](#troubleshooting) for more details.
```
table name read imported errors total time
----------------------------------------------- --------- --------- --------- --------------
fetch meta data 119 119 0 0.388s
Truncate 119 119 0 1.134s
----------------------------------------------- --------- --------- --------- --------------
public.abuse_reports 0 0 0 0.490s
public.appearances 0 0 0 0.488s
.
.
.
public.web_hook_logs 0 0 0 1.080s
----------------------------------------------- --------- --------- --------- --------------
COPY Threads Completion 4 4 0 2.008s
Reset Sequences 113 113 0 0.304s
Install Comments 0 0 0 0.000s
----------------------------------------------- --------- --------- --------- --------------
Total import time 1894 1894 0 12.497s
```
If there is no output for more than 30 minutes, it's possible `pgloader` encountered an error. See
the [troubleshooting guide](#troubleshooting) for more details.
1. Start GitLab:
```bash
sudo gitlab-ctl start
```
```bash
sudo gitlab-ctl start
```
You can now verify that everything works as expected by visiting GitLab.
......
......@@ -54,13 +54,13 @@ sudo yum install epel-release && sudo yum install git-annex
For omnibus-gitlab packages, only one configuration setting is needed.
The Omnibus package will internally set the correct options in all locations.
1. In `/etc/gitlab/gitlab.rb` add the following line:
1. In `/etc/gitlab/gitlab.rb` add the following line:
```ruby
gitlab_shell['git_annex_enabled'] = true
```
```ruby
gitlab_shell['git_annex_enabled'] = true
```
1. Save the file and [reconfigure GitLab][] for the changes to take effect.
1. Save the file and [reconfigure GitLab][] for the changes to take effect.
### Configuration for installations from source
......@@ -69,20 +69,20 @@ There are 2 settings to enable git-annex on your GitLab server.
One is located in `config/gitlab.yml` of the GitLab repository and the other
one is located in `config.yml` of gitlab-shell.
1. In `config/gitlab.yml` add or edit the following lines:
1. In `config/gitlab.yml` add or edit the following lines:
```yaml
gitlab_shell:
git_annex_enabled: true
```
```yaml
gitlab_shell:
git_annex_enabled: true
```
1. In `config.yml` of gitlab-shell add or edit the following lines:
1. In `config.yml` of gitlab-shell add or edit the following lines:
```yaml
git_annex_enabled: true
```
```yaml
git_annex_enabled: true
```
1. Save the files and [restart GitLab][] for the changes to take effect.
1. Save the files and [restart GitLab][] for the changes to take effect.
## Using GitLab git-annex
......
......@@ -46,25 +46,24 @@ need to do (we assume you have [git-annex enabled](../git_annex.md#using-gitlab-
repository and that you have made backups in case something goes wrong).
Fire up a terminal, navigate to your Git repository and:
1. Disable `git-annex`:
```bash
git annex sync --content
git annex direct
git annex uninit
git annex indirect
```
```bash
git annex sync --content
git annex direct
git annex uninit
git annex indirect
```
1. Enable `git-lfs`:
```
git lfs install
git lfs track <files>
git add .
git commit -m "commit message"
git push
```
```
git lfs install
git lfs track <files>
git add .
git commit -m "commit message"
git push
```
### Disabling Git Annex in your repo
......@@ -86,72 +85,72 @@ if the server also has Git Annex 6 installed. Read more in the
1. Backup your repository
```bash
cd repository
git annex sync --content
cd ..
git clone repository repository-backup
cd repository-backup
git annex get
cd ..
```
```bash
cd repository
git annex sync --content
cd ..
git clone repository repository-backup
cd repository-backup
git annex get
cd ..
```
1. Use `annex direct`:
```bash
cd repository
git annex direct
```
```bash
cd repository
git annex direct
```
The output should be similar to this:
The output should be similar to this:
```bash
commit
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree clean
ok
direct debian.iso ok
direct ok
```
```bash
commit
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree clean
ok
direct debian.iso ok
direct ok
```
1. Disable Git Annex with [`annex uninit`][uninit]:
```bash
git annex uninit
```
```bash
git annex uninit
```
The output should be similar to this:
The output should be similar to this:
```bash
unannex debian.iso ok
Deleted branch git-annex (was 2534d2c).
```
```bash
unannex debian.iso ok
Deleted branch git-annex (was 2534d2c).
```
This will `unannex` every file in the repository, leaving the original files.
This will `unannex` every file in the repository, leaving the original files.
1. Switch back to `indirect` mode:
```bash
git annex indirect
```
The output should be similar to this:
```bash
git annex indirect
```
```bash
(merging origin/git-annex into git-annex...)
(recording state in git...)
commit (recording state in git...)
The output should be similar to this:
ok
(recording state in git...)
[master fac3194] commit before switching to indirect mode
1 file changed, 1 deletion(-)
delete mode 120000 alpine-virt-3.4.4-x86_64.iso
ok
indirect ok
ok
```
```bash
(merging origin/git-annex into git-annex...)
(recording state in git...)
commit (recording state in git...)
ok
(recording state in git...)
[master fac3194] commit before switching to indirect mode
1 file changed, 1 deletion(-)
delete mode 120000 alpine-virt-3.4.4-x86_64.iso
ok
indirect ok
ok
```
---
......@@ -216,16 +215,16 @@ branches created by Git Annex: `git-annex`, and all under `synced/`.
![repository branches](images/git-annex-branches.png)
You can also do this on the commandline with:
You can also do this on the command line with:
```bash
git branch -d synced/master
git branch -d synced/git-annex
git push origin :synced/master
git push origin :synced/git-annex
git push origin :git-annex
git remote prune origin
```
```bash
git branch -d synced/master
git branch -d synced/git-annex
git push origin :synced/master
git push origin :synced/git-annex
git push origin :git-annex
git remote prune origin
```
If there are still some Annex objects inside your repository (`.git/annex/`)
or references inside `.git/config`, run `annex uninit` again:
......
# Feature branch workflow
1. Clone project:
1. Clone project:
```bash
git clone git@example.com:project-name.git
```
```bash
git clone git@example.com:project-name.git
```
1. Create branch with your feature:
1. Create branch with your feature:
```bash
git checkout -b $feature_name
```
```bash
git checkout -b $feature_name
```
1. Write code. Commit changes:
1. Write code. Commit changes:
```bash
git commit -am "My feature is ready"
```
```bash
git commit -am "My feature is ready"
```
1. Push your branch to GitLab:
1. Push your branch to GitLab:
```bash
git push origin $feature_name
```
```bash
git push origin $feature_name
```
1. Review your code on commits page.
1. Review your code on commits page.
1. Create a merge request.
1. Create a merge request.
1. Your team lead will review the code &amp; merge it to the main branch.
1. Your team lead will review the code &amp; merge it to the main branch.
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment