*`squash` - Does an interactive rebase of the previous # commits; useful for squashing commits

*`stashed` - Display information about stashes

### Cloning a Repository

Once you've set up SSH, cloning a repository hosted on GitLab is pretty simple and straightforward. The structure of a repository's URI is: <host>:<namespace>/<project>.git (example: gitlab:systems/git-tips.git). Determine where you want to clone the repository; a directory like ~/projects/ works pretty well, but it really doesn't matter; wherever you are most comfortable working.

* Change to your projects directory (e.g. `cd ~/projects`)

*`git clone -o systems gitlab:systems/git-tips.git`

That's it.

You should now have a copy of the Git Tips repository in ~/projects/git-tips (or wherever, you non-conformist, you...) It is cloned and the only remote repository (simply 'remote' for short) it knows about is named 'systems' (-o <name> gives the remote a name, the default is origin).

### Branch Workflow

In a branch-style workflow, contributors either maintain long-lived personal branches of a project, or create (and destroy) shorter lived branches for bringing in new features or fixing bugs.

Creating a new branch:

```

cd ~/projects/git-tips

git checkout -b foo # create and checkout the branch 'foo'

```

You can change between branches by typing `git checkout <name_of_branch>`.

```

git checkout foo # Change to local branch 'foo'

git merge --no-ff master # Merge changes from 'master into the currently checked out branch; Creates a merge commit

The fork-style workflow is more complicated than the branch-style workflow because it necessitates working with multiple remotes, but is easier for individual contributors to work with, since you have a long-lived development environment set up.

Forking creates a clone of a particular project in your own personal name-space. This allows you to do your development work out of the way of anyone else, and work on features and bug fixes until they are ready to be shared with others.

The fork-style workflow is useful when there are numerous contributors managing long-lived branches on the main repository.

"Rewriting history" using tools like `git rebase` is a much smaller issue when working with a personal fork.

git rebase bar systems/master # Rebase your local branch 'bar' on top of the branch 'master' on systems; changes made to your local branch only

```

Ignore the 'rebase' example above if you're unfamiliar with rebase; it's only there for an example of how you can work with remotes. For more information about git, please read through [Pro Git](https://git-scm.com/book/en/v2).

### Contributing Changes

Whether using the fork or branch workflows, contributing changes to a project (at least through GitLab) is pretty much the same.

When all is said and done, and you have work that is ready to be reviewed by others and potentially pushed to 'production', you will need to create a Merge Request on GitLab:

* Describe what your branch does and what testing you've done: don't rely on commit messages.

* Click 'Submit new merge request'

* Notify the main maintainer(s) of the project (they should receive an email, but...)

Your changes will be reviewed, and the maintainer(s) may have follow up questions for you or may ask you to make some changes, or squash some commits and generally clean things up.

### Bringing in Changes

This is a heated topic in some circles; some people prefer merging and merge commits, where others prefer a cleaner history and rebasing. The style should be determined by the maintainer(s), I personally prefer rebasing.

I'd rather leave this hazy, for the time being, until people get more familiar with git; information about both methods is readily available.

Merging is easiest, especially with GitLab, because it can essentially all be done through the web interface.

### Migrating a Repository from Other Services

The process is fairly straightforward:

* Create a new project on GitLab; either a user or group project

* Clone the project from the original service (if it has not already been cloned somewhere you can work with it)

* Add a remote for the new GitLab project you created

* Push the repository to your new GitLab remote

```

git clone -o source <source_URI> migrate # (optional) Clone the repository from the other service into the directory 'migrate'

# Checkout all remote branches locally (optional)

for branch in $(git branch -r | grep source | grep -v HEAD); do

branch="${branch##*/}"

git branch --track "$branch" source/"$branch"

done

# Where 'namespace' is the user/group, and 'project' is the name of the project on GitLab: