- Git Intro
- Git Setup
- Git Basics
- Merge Request
- Merge Conflicts
- Revert and Unstage
- Instructor Notes
- Records changes to a file
- Maintains history of changes
- Disaster Recovery
- Types of VCS: Local, Centralized and Distributed
- 1991-2002: The Linux kernel was being maintained by sharing archived files and patches.
- 2002: The Linux kernel project began using a DVCS called BitKeeper
- 2005: BitKeeper revoked the free-of-charge status and Git was created
- Distributed Version Control System
- Great branching model that adapts well to most workflows
- Fast and reliable
- Keeps a complete history
- Disaster recovery friendly
- Open Source
- Use the tools at your disposal when you get stuck.
git help <command>command
- Use Google (i.e. StackOverflow, Google groups)
- Read documentation at https://git-scm.com
- Windows: Install ‘Git for Windows’
- Mac: Type
gitin the Terminal application.
- If it’s not installed, it will prompt you to install it.
sudo apt-get install git-all
- Red Hat
sudo yum install git-all
- One-time configuration of the Git client:
git config --global user.name "Your Name" git config --global user.email email@example.com
- If you don’t use the global flag you can set up a different author for each project
- Check settings with:
git config --global --list
- You might want or be required to use an SSH key.
- Instructions: SSH
- Choose a directory on you machine easy to access
- Create a workspace or development directory
- This is where we’ll be working and adding content
mkdir ~/development cd ~/development -or- mkdir ~/workspace cd ~/workspace
- Untracked files
- New files that Git has not been told to track previously.
- Working area (Workspace)
- Files that have been modified but are not committed.
- Staging area (Index)
- Modified files that have been marked to go in the next commit.
- Hosted repository on a shared server
- GitLab is an application to code, test and deploy.
- Provides repository management with access controls, code reviews, issue tracking, Merge Requests, and other features.
- The hosted version of GitLab is https://gitlab.com
- Sign in into your https://gitlab.com account
- Create a project
- Choose to import from ‘Any Repo by URL’ and use https://gitlab.com/gitlab-org/training-examples.git
- On your machine clone the
- 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
- Create a new feature branch called
bugs.rband 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
WIPto 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
- 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: Thoughtbot
- See GitLab merge requests for examples: Merge Requests
- 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 and watch it fail
- Rebase our new branch with master
- Fix conflicts on the conflicts.rb file.
- Stage the file and continue rebasing
- Force push the changes
- Finally continue with the Merge Request
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. You’ll see a conflict warning.
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
- When to use
git mergeand when to use
- 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
To remove files from stage use reset HEAD. Where HEAD is the last commit of the current branch:
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>
To remove a file from disk and repo use
git rm and to remove a directory use the
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
git rm <filename> --cache
Undo last commit putting everything back into the staging area:
git reset --soft HEAD^
Add files and change message with:
git commit --amend -m "New Message"
Undo last and remove changes
git reset --hard HEAD^
Same as last one but for two commits back:
git reset --hard HEAD^^
Don’t reset after pushing
- Edit file again ‘edit_this_file.rb’
- Check status
- Add and commit with wrong message
- Check log
- Amend commit
- Check log
- Soft reset
- Check log
- Pull for updates
- 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
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)
- 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