Git Basics - bounswe/bounswe2017group3 GitHub Wiki
Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later. It has (mainly) three types:
- Local Version Control System (LVCS): Copies the files into another directory.
- Centralized Version Control System (CVCS): Has a single server that contains all the versioned files, and a number of clients that check out files from that central place.
- Distributed Version Control System (DVCS): Just like CVCC but clients don’t just check out the latest snapshot of the files: they fully mirror the repository. Thus if any server dies, and these systems were collaborating via it, any of the client repositories can be copied back up to the server to restore it. Every clone is really a full backup of all the data. Git is a DVCS.
Git is a distributed version control system that supports non-linear distributed workflows. It is an open-source project started by Linus Torvalds, the famous creator of the Linux operating system kernel. It was created for the development of the Linux kernel, with other kernel developers contributing to its initial development. Now it became a huge system that is used by millions of people.
-
Download git for macOS. If you have Brew, you can also install Git with
brew install git. - Download git for Windows.
- Download git for Linux.
Create a new directory, open it and run the command git init. It'll create an empty git repository.
You can create a working copy of a local repository by running the command
git clone /path/to/repository
If you want to get the repository from a remote server, your command will be
git clone username@host:/path/to/repository
Your local repository consists of three "trees" maintained by git.
The first one is your Working Directory which holds the actual files.
The second one is the Index which acts as a staging area and finally the HEAD which points to the last commit you've made.
If you want to add a file to your repository (to Index), run
git add <FILE_NAME>
or if you want to add all the files in your current directory, run this instead
git add *
This is the first step in the basic git workflow. To actually commit these changes use
git commit -m "Commit message"
Now the file is committed to the HEAD, but not in your remote repository yet.
Your changes are now in the HEAD of your local working copy. To send those changes to your remote repository, execute
git push origin master
Change master to whatever branch you want to push your changes to.
If you have not cloned an existing repository and want to connect your repository to a remote server, you need to add it with
git remote add origin <SERVER>
Now you are able to push your changes to the selected remote server.
Branches are used to develop features isolated from each other. The master branch is the "default" branch when you create a repository. Use other branches for development and merge them back to the master branch upon completion.
You can create a new branch named feature_x and switch to it using
git checkout -b feature_x
or just switch to an existing_branch
git checkout existing_branch
You can delete a branch with
git branch -d branch_name
A branch is not available to others unless you push the branch to your remote repository. To push your branch, checkout to that branch and run
git push origin <YOUR_BRANCH_NAME>
To update your local repository to the newest commit in remote server, execute
git pull
in your working directory to fetch and merge remote changes at once.
To merge another branch into your active branch, use
git merge <BRANCH_NAME>
In both cases git tries to auto-merge changes. Unfortunately, this is not always possible and can result in conflicts. You are responsible to merge those conflicts manually by editing the files shown by git. After changing, you need to mark them as merged with
git add <FILE_NAME>
Before merging changes, you can also preview them by using
git diff <SOURCE_BRANCH> <TARGET_BRANCH>
In its simplest form, you can look at the repository history using git log.
You can add a lot of parameters to make the log look like what you want.
- To see only the commits of a certain author:
git log --author=smddzcy - To see a very compressed log where each commit is one line:
git log --pretty=oneline - To see an ASCII art tree of all the branches, decorated with the names of tags and branches:
git log --graph --oneline --decorate --all - See only which files have changed:
git log --name-status - For more, see:
git log --help
In case you did something wrong, to replace your changes with the last content in HEAD, run
git checkout -- <FILE_NAME>
or to replace all your changes in the directory, run
git checkout -- .
If you instead want to drop all your local changes and commits, fetch the latest history from the server and point your local master branch at it like this
git fetch origin
git reset --hard origin/master
It's recommended to create tags for software releases. You can create a new tag named 1.0.0 by executing
git tag 1.0.0 1b2e1d63ff
where 1b2e1d63ff stands for the first 10 characters of the commit id you want to reference with your tag. You can get the commit id by looking at git log output.