GitLab Git Workshop
- Brief history of Git
- GitLab walkthrough
- Configure your environment
- Distributed version control
- Does not rely on connection to a central server
- Many copies of the complete history
- Powerful branching and merging
- Adapts to nearly any workflow
- Fast, reliable and stable file format
Use the tools at your disposal when you get stuck.
- Use '
git help <command>' command
- Use Google
- Read documentation at https://git-scm.com
Configure your environment
- Windows: Install 'Git for Windows'
- Mac: Type '
git' in the Terminal application.
If it's not installed, it will prompt you to install it.
- Debian: '
sudo apt-get install git-all' or Red Hat '
sudo yum install git-all'
- Configure Git
- Configure SSH Key
- Create a project
- Feature branching
- Merge requests
- Feedback and Collaboration
One-time configuration of the Git client
git config --global user.name "Your Name" git config --global user.email firstname.lastname@example.org
Configure SSH Key
ssh-keygen -t rsa -b 4096 -C "you@computer-name"
# You will be prompted for the following information. Press enter to accept the defaults. Defaults appear in parentheses. Generating public/private rsa key pair. Enter file in which to save the key (/Users/you/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /Users/you/.ssh/id_rsa. Your public key has been saved in /Users/you/.ssh/id_rsa.pub. The key fingerprint is: 39:fc:ce:94:f4:09:13:95:64:9a:65:c1:de:05:4d:01 you@computer-name
Copy your public key and add it to your GitLab profile
ssh-rsa AAAAB3NzaC1yc2EAAAADAQEL17Ufacg8cDhlQMS5NhV8z3GHZdhCrZbl4gz email@example.com
Create a project
- Create a project in your user namespace
- Choose to import from 'Any Repo by URL' and use https://gitlab.com/gitlab-org/training-examples.git
- Create a '
development' or '
workspace' directory in your home directory.
- Clone the '
mkdir ~/development cd ~/development -or- mkdir ~/workspace cd ~/workspace git clone firstname.lastname@example.org:<username>/training-examples.git cd training-examples
New files that Git has not been told to track previously.
Files that have been modified but are not committed.
Modified files that have been marked to go in the next commit.
- Edit '
edit_this_file.rb' in '
- See it listed as a changed file (working area)
- View the differences
- Stage the file
- Push the commit to the remote
- View the git log
# Edit `edit_this_file.rb` git status git diff git add <file> git commit -m 'My change' git push origin master git log
- 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
- Create a new feature branch called 'squash_some_bugs'
- Edit '
bugs.rb' and remove all the bugs.
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
- 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 'WIP' 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
Create your first merge request
- Use the blue button in the activity feed
- View the diff (changes) and leave a comment
- Push a new commit to the same branch
- 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
Feedback and Collaboration
Review the Thoughtbot code-review guide for suggestions to follow when reviewing merge requests: https://github.com/thoughtbot/guides/tree/master/code-review
See GitLab merge requests for examples: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests
Explore GitLab projects
- User Preferences
- ReadMe, Changelog, License shortcuts
- Milestones and Labels
- Manage project members
- Project settings
- Useful for marking deployments and releases
- Annotated tags are an unchangeable part of Git history
- Soft/lightweight tags can be set and removed at will
- Many projects combine an anotated release tag with a stable branch
- Consider setting deployment/release tags automatically
- Create a lightweight tag
- Create an annotated tag
- Push the tags to the remote repository
git checkout master # Lightweight tag git tag my_lightweight_tag # Annotated tag git tag -a v1.0 -m ‘Version 1.0’ git tag git push origin --tags
- Happen often
- Learning to fix conflicts is hard
- Practice makes perfect
- Force push after fixing conflicts. Be careful!
- Checkout a new branch and edit
conflicts.rb. Add 'Line4' and 'Line5'.
- Commit and push
- Checkout master and edit
conflicts.rb. Add 'Line6' and 'Line7' below 'Line3'.
- Commit and push to master
- Create a merge request
After creating a merge request you should notice that conflicts exist. Resolve the conflicts locally by rebasing.
git rebase master # Fix conflicts by editing the files. git add conflicts.rb git commit -m 'Fix conflicts' git rebase --continue git push origin <branch> -f
Rebase with squash
You may end up with a commit log that looks like this:
Fix issue #13 Test Fix Fix again Test Test again Does this work?
Squash these in to meaningful commits using an interactive rebase.
Rebase with squash
Squash the commits on the same branch we used for the merge conflicts step.
git rebase -i master
In the editor, leave the first commit as 'pick' and set others to 'fixup'.
Thank you for your hard work!
GitLab Documentation http://docs.gitlab.com
GUI Clients http://git-scm.com/downloads/guis
Pro git book http://git-scm.com/book
Platzi Course https://courses.platzi.com/courses/git-gitlab/
Code School tutorial http://try.github.io/
Contact Us at