Git, managed code
Some contents of this page is from here by Github. You can visit this page to know more about Git and Github.
Cuties used Git as revision control tool. This document is meant for Cuties developers and maintainers as a simple way to getting started with Git. We setup Cuties project at Github for master. We also provide mirror repository at OSC.
Subversion checkout URL can be browsed at Project Cuties Github Homepage and at Project Cuties OSC Mirror Homepage.
If you have trouble with this, please visit: Set Up Git (Github), Anything not covered by this document can be found this link.
Download and install the latest version of Git. Please mentioned that Git won't add an icon anywhere, it's not that sort of application.
Now that you have Git installed, it's time to configure your settings. To do this you need to open the command line. First you need to tell git your name, so that it can properly label the commits you make.
git config --global user.name "Your Name Here"
Git saves your email address into the commits you make. Github use the email address to associate your commits with your GitHub account. So you need to set the email.
git config --global user.email "your_email@example.com"
Tips: If you own a Github account and you are using github, your email address for Git should be the same one associated with your GitHub account. If it is not, see this guide for help adding additional emails to your GitHub account. If you want to keep your email address hidden, this guide may be useful to you.
The last option we need to set will tell git that you don't want to type your username and password every time you talk to a remote server. You need git 1.7.10 or newer to use the credential helper.
To use this option, you need to turn on the credential helper so that git will save your password in memory for some time:
git config --global credential.helper cache
By default git will cache your password for 15 minutes. You can change this if you like.
git config --global credential.helper 'cache --timeout=3600'
The credential helper only works when you clone an HTTPS repository URL. If you use the SSH repository URL instead, SSH keys are used for authentication. This guide offers help generating and using an SSH key pair.
Congratulations, you now have Git and GitHub all set up!
At some point you may find yourself wanting to contribute to someone else's project, or would like to use someone's project as the starting point for your own. This is known as "forking".
You can fork Cuties to your own repository, or just clone our repository. We recommand you to fork to yourself.
On Github, to fork Cuties, click the "Fork" button in the Cuties repository.
You've successfully forked the Cuties repository, but so far it only exists on GitHub. To be able to work on the project, you will need to clone it to your local machine.
Run the following code:
git clone https://github.com/username/Cuties.git
We suggest you to use https link to clone our project. Now the repository is available in the directory "Cuties".
You've successfully forked a repository, but get a load of these other cool things you can do:
A commit, or "revision", is an individual change to a file (or set of files). It's like when you save a file, except with Git, every time you save it creates a unique ID (a.k.a. the "SHA" or "hash") that allows you to keep record of what changes were made when and by who. Commits usually contain a commit message which is a brief description of what changes were made.
Think of a commit as a snapshot of your project — code, files, everything — at a particular point in time. After your first commit git will only save the files that have changed, thus saving space.
To create a commit, you have to add your modified files first, using git add command:
usage of git add:
git add [options] [--] <filepattern>...
-n, --dry-run dry run
-v, --verbose be verbose
-i, --interactive interactive picking
-p, --patch select hunks interactively
-e, --edit edit current diff and apply
-f, --force allow adding otherwise ignored files
-u, --update update tracked files
-N, --intent-to-add record only the fact that the path will be added later
-A, --all add changes from all tracked and untracked files
--refresh don't add, only refresh the index
--ignore-errors just skip files which cannot be added because of errors
--ignore-missing check if - even missing - files are ignored in dry run
Warning: Git will do its best to compress your files, but large files and binaries can cause a repository to become bloated and unwieldy. Try to avoid committing things like compressed files (zips, rars, jars), compiled code (object files, libraries, executables), database backups, and media files (flv, psd, music, movies).
Once you've made some commits to a forked repository and want to push it to your forked project, you do it the same way you would with a regular repository:
git push origin master
There are two ways to get commits from a remote repository or branch: git fetch and git pull. While they might seem similar at first, there are distinct differences you should consider.
When you use git pull, git tries to automatically do your work for you. It is context sensitive, so git will merge any pulled commits into the branch you are currently working in. One thing to keep in mind is that git pull automatically merges the commits without letting you review them first. If you don't closely manage your branches you may run into frequent conflicts.
git pull upstream master
When you git fetch, git retrieves any commits from the target remote that you do not have and stores them in your local repository. However, it does not merge them with your current branch. This is particularly useful if you need to keep your repository up to date but are working on something that might break if you update your files. To integrate the commits into your local branch, you use git merge. This combines the specified branches and prompts you if there are any conflicts.
git fetch upstream
git merge upstream/master