Andrea Cremasco
GIT Guide
Initial configuration
To set user information:
1. git init
2. git config user.name "someone"
3. git config user.email "[email protected]"
4. git add *
5. git commit -m "some init msg"
Basic commands
Use Git commands to help keep track of changes made to a project:
git init creates a new Git repository
git status inspects the contents of the working directory and staging area
o List all untracked files in red
git add adds files from the working directory to the staging area
o In order to start tracking a file, add it to Stage Area by git add <filename>
o More files can be added git add <filename1> <filename2>
git diff shows the difference between the working directory and the staging area
git commit permanently stores file changes from the staging area in the repository
o –m to add a message related to the commitment status, btw quotation marks
git log shows a list of all previous commits
Andrea Cremasco
Repository structure
A Git project can be thought of as having three parts:
A Working Directory: where you'll be doing all the work: creating, editing, deleting and organizing
files
A Staging Area: where you'll list changes you make to the working directory
A Repository: where Git permanently stores those changes as different versions of the project
Workflow
1. Edit file in the Working directory
2. Add file to Staging area
3. Save changes to Repository
Backtrack
git checkout HEAD <filename>: Discards changes in the working directory.
git reset HEAD <filename>: unstages file changes in the staging area.
git reset <commit_SHA>: Resets to a previous commit in your commit history.
Revert to committed version
1. A file file1.txt has been modified
2. File1.txt has been added to the staging area
3. File1.txt has been committed
NOTE: the commit lastly done is known as HEAD commit. To see it git show HEAD
4. After committing, a modification was done to the file1.txt in Working directory
Scope: Revert the file1.txt to the status just after committing
git checkout HEAD file1.txt
Remove from staging area before committing, unstage file
git reset HEAD <filename>
Andrea Cremasco
This command does:
1. Remove the modified <filename> from the staging area and bring back at Working Directory, where
it keeps the modifications done after committing
2. Reset the file <filename> in staging area to the version after in HEAD commit
Reset the project/file to the status at a certain commit
1. Use command git log to find the status where it is needed to go back
2. Use command git reset <7 characters of SHA code>
NOTE: to reset a single file use git checkout <commit hash> -- <filename1> <filename2>
3. HEAD is set to that commit
Branching
Git allows us to create branches to experiment with versions of a project.
git branch checks what branch you are currently on, which is indicated with * asterisk
git branch new_branch creates a new branch. The master and fencing branches are identical: they
share the same exact commit history
git checkout new_branch is used to switch to the new branch
The normal operations can be done to files (add, commit) but they are applied to the new_branch
git branch -d new_branch will delete new_branch
Andrea Cremasco
Merge new branch to master branch
1. Switch to master branch.
git checkout master
2. Merge new_branch
git merge new_branch master
NOTE: a conflit may appear if file1.txt has been firstly modified while being in new_branch and then
in master branch.
In this case:
1. Git uses markings to indicate the HEAD (master) version of the file and the fencing version
of the file, like this:
<<<<<<< HEAD
master version of line
=======
fencing version of line
>>>>>>> fencing
2. Resolve the conflicts based on indications given by git
Delete all of Git's special markings including the words HEAD and new_branch. If any of
Git's markings remain, for example, >>>>>>> and =======, the conflict remains.
Git teamwork – remotes
They allow to handle:
A complete replica of the project on your own computers
A way to keep track of and review each other's work
Access to a definitive project version
A remote is a shared Git repository that allows multiple collaborators to work on the same Git project from
different locations. Collaborators work on the project independently, and merge changes together when
they are ready to do so.
1. Clone locally the remote repository
git clone remote_location clone_name
o remote_location: tells Git where to go to find the remote. This could be a web address, or a
filepath, such as: /Users/teachers/Documents/some-remote
o clone_name: is the name you give to the directory in which Git will clone the repository
NOTE: Git gives the remote address the name origin
To see a list of Git project’s remote git remote –v
Typical workflow
1. Fetch and merge changes from the remote
git fetch
This command will not merge changes from the remote into your local repository. It brings those
changes onto what's called a remote branch origin/master. Your local master branch has not been
updated yet, so you can't view or make changes to any of the work she has added.
2. Merge remote branch to master local
git merge origin/master
3. Create a branch to work on a new project feature
4. Develop the feature on your branch and commit your work
Andrea Cremasco
5. Optional: Fetch and merge from the remote again (in case new commits were made while you were
working)
6. Push your branch up to the remote for review
git push origin branch_name
Github
Git projects are usually managed on Github, a website that hosts Git projects for millions of users. With
Github you can access your projects from anywhere in the world by using the basic workflow you learned
here.
