A version control system tracks changes to files over time.

• Version control
  • authorship, time stamps, and files changed
• Distributed
  • Repositories are self-contained and collaborative - work on a flight and share when you land.
• Open source and widely used

• Code review
• Browser-based Git repository manager
• Project ownership and management
• Task assignment and tracking
• Open source and widely used

http://git-scm.com/downloads

(Windows) With Git installed, you should be able to right-click in any folder and select "Git Bash Here" to pull up a console.

All commands to Git are issued through the console, or command line interface.

git config --global user.name "Elizabeth Byerly"  
git config --global user.email "elizabeth.byerly@gmail.com"

By issuing these configuration commands, all our Git activity will be stamped with our name and e-mail.

These commands must be re-issued for every installation of Git (i.e., if you want to use Git on your home computer).

We use the init command to create a repository in the current working directory of our console.

git init

Or, we can specify the directory we want to make a Git repository (it will make the directory if it does not exist).

git init "L:/my-new-project"

All files in the working directory, as well as all files in all subfolders, will be seen by Git.

Add some files to your directory and then to your new git repository.

git status
git add --all
git status
git commit -m 'My first commit'
git status

status is helpful for seeing the current condition of your potential commit. The first call will show in red the files you've added to your repo. The second call will show them in green, staged and ready to be tracked by Git. The last call, after our commit, shows we have no current changes to consider.

Let's pause here to talk about three levels of "saved" in the world of Git:

• Seen: Files written to disk, our working copy. Git cannot see work in our file editor until we save it. (We can also deliberately hide files from Git using .gitignore.)
• Staged: Git is aware of a change and is ready to add it to the file's tracked history.
• Committed: Git has saved the state of the staged file changes written to disk.

We care about committed file changes. Changes saved to disk and staged, but never committed, can be lost as soon as we change the file again.

git checkout <commit hash 1> "File C"

git checkout HEAD@{3} "File C"

git checkout -b dev

git checkout master
git merge dev

Repositories can be cloned.

git clone -b master "L:/my-new-project" "P:/my-clone-new-project"

Cloning does not copy the folder contents. It creates a new Git repository with the same contents, including its history of changes, and tracks the repository from which it was cloned (its origin). This means we can update "P:/my-copy-new-project" everytime its origin repository changes.

Note we provide the option -b master, which specifies we want to clone the master branch initially. All branches pushed to the central repository are available; this option sets what you define as your local master.

Updating based on the changes in origin is one part of Git's collaborative workflow. To be able to push our changes to origin (that is, update origin based on the changes we make to our remote repository), we need to make origin a bare repository.

<hr / >

What is a bare repository? One without a working directory!

For collaborative workflows, this is key. Multiple users can use a bare repository as their central repository - the one source of project Truth - from which they will pull down changes and push updates.

git init --bare "L:/second-new-project"
git clone "L:/second-new-project" "P:/my-remote-second-project"

We do some work, add some files changes, then we check the origin repo is in the same state as when we cloned.

git pull origin

If changes were introduced by another collaborator, they either (a) merge without issue or (b) introduce code conflicts we can resolve.

Finally, we give our code changes to the central repository.

git push origin master

Note, if we skipped the git pull step and another contributer has added conflicting work to the project, your push will be rejected!

Otherwise, anyone with access to the bare central repository can now clone our work and add to it.

• Git GUI for Windows (gitk)
• SourceTree
• Giggle
• …many more!
• Note: TortoiseGit will break our Windows SSH connection to GitLab.

These have not been reviewed for compatibility with a GitLab workflow. Please provide feedback if any of these are particularly easy/difficult or effective/horrible to use.

https://gitlab.com/users/sign_in

Follow the instructions! I believe in you.

In your console window, run the SSH generation.

ssh-keygen -t rsa -C "elizabeth.byerly@gmail.com"

Allow its default save location and press Enter twice to create without a password. Then, copy your public key to your clipboard.

clip < "~/.ssh/id_rsa.pub"

Paste the contents of your clipboard into Add an SSH Key: https://gitlab.com/profile/keys

These commands must be re-issued for every computer on which you use GitLab. You can add multiple SSH keys to your GitLab account.

https://gitlab.com/projects/new

Your Project path is your project name. It cannot contain spaces.

Your Visibility Level sets the project privacy.

• Private: Your project is invisible to users not explicitly invited to see it. Authentication is required to read and write. (This option is only available for private installations of GitLab.)
• Internal: Your project is visible to users logged into https://gitlab.com/. Authentication is required to write.
• Public: Your project is visible to everyone and can be copied by anyone.

We can also Create a group if we want to associate multiple projects.

git clone git@gitlab.com:ByerlyElizabeth/test-gitlab.git

Once you've cloned the bare repository from GitLab, you use it exactly the same as a normal Git repository. The push and pull commands will refer to the bare repository on the GitLab server.

https://gitlab.com/ByerlyElizabeth/test-gitlab/project_members

When adding a user to your project, you must assign their permissions level.

• Owner: Creator of the project. Can delete or change the visibility level.
• Master: Create milestones, add team members, and push to protected branches.
• Developer: Create and manage merge requests, create and modify unprotected branches.
• Reporter: Pull code and manage issues.
• Guest: Create issues and leave comments.

https://gitlab.com/ByerlyElizabeth/test-gitlab/issues

Issues can be assigned to a user on the project or be left unassigned. They can also be associated with a milestone and labels.

Milestones are for documentation purposes.

By default, the master branch is protected.

Protected branches can only be written to by users with Master or Owner permissions. This forces lower level users to issue a merge request.

https://gitlab.com/ByerlyElizabeth/test-gitlab/network/master