Git


This draft deletes the entire topic.

expand all collapse all

Examples

  • 52

    At the command line, first verify that you have Git installed:

    On all operating systems:

    git --version
    

    On UNIX-like operating systems:

    which git
    

    If nothing is returned, or the command is not recognized, you may have to install Git on your system by downloading and running the installer. See the Git homepage for exceptionally clear and easy installation instructions.

    After installing Git, configure your username and email address. Do this before making a commit.

    Once Git is installed, navigate to the directory you want to place under version control and create an empty Git repository:

    git init
    

    This creates a hidden folder, .git, which contains the plumbing needed for Git to work.

    Next, check what files Git will add to your new repository; this step is worth special care:

    git status
    

    Review the resulting list of files; you can tell Git which of the files to place into version control (avoid adding files with confidential information such as passwords, or files that just clutter the repo):

    git add <file/directory name #1> <file/directory name #2> < ... >
    

    If all files in the list should be shared with everyone who has access to the repository, a single command will add everything in your current directory and its subdirectories:

    git add .
    

    This will "stage" all files to be added to version control, preparing them to be committed in your first commit.

    For files that you want never under version control, create and populate a file named .gitignore before running the add command.

    Commit all the files that have been added, along with a commit message:

    git commit -m "Initial commit"
    

    This creates a new commit with the given message. A commit is like a save or snapshot of your entire project. You can now push, or upload, it to a remote repository, and later you can jump back to it if necessary.

  • 30

    The git clone command is used to copy an existing Git repository from a server to the local machine.

    For example, to clone a GitHub project:

    cd <path where you'd like the clone to create a directory>
    git clone https://github.com/username/projectname.git
    

    To clone a BitBucket project:

    cd <path where you'd like the clone to create a directory>
    git clone https://[email protected]/username/projectname.git
    

    This creates a directory called projectname on the local machine, containing all the files in the remote Git repository. This includes source files for the project, as well as a .git sub-directory which contains the entire history and configuration for the project.

    To specify a different name of the directory, e.g. MyFolder:

    git clone https://github.com/username/projectname.git MyFolder
    

    Note:

    1. When cloning to a specified directory, the directory must be empty or non-existent.

    2. You can also use the ssh version of the command:

      git clone [email protected]:username/projectname.git
      

    The https version and the ssh version are equivalent. However, some hosting services such as GitHub recommend that you use https rather than ssh.

  • 18

    To share your code on a remote server where you have shell access, the following steps will help you create the repository on that server, then copy your local repository.

    To minimize the use of space on the remote server you create a bare repository: one which has only the .git objects and doesn't create a working copy in the filesystem. As a bonus you set this remote as an upstream server to easily share updates with other programmers.

    On the remote server:

    git init --bare /path/to/repo.git
    

    On the local machine:

    git remote add origin ssh://username@server:/path/to/repo.git
    

    (Note that ssh: is just one possible way of accessing the remote repository.)

    Now copy your local repository to the remote:

    git push --set-upstream origin master
    

    Adding --set-upstream (or -u) created an upstream (tracking) reference which is used by argument-less Git commands, e.g. git pull.

Please consider making a request to improve this example.

Remarks

Git is a free, distributed version control system which allows programmers to keep track of code changes, via "snapshots" (commits), in its current state. Utilizing commits allows programmers to test, debug, and create new features collaboratively. All commits are kept in what is known as a "Git Repository" that can be hosted on your computer, private servers, or open source websites, such at Github.

Git also allows for users to create new "branches" of the code, which allows different versions of the code to live alongside each other. This enables scenarios where one branch contains the most recent stable version, a different branch contains a set of new features being developed, and a yet another branch contains a different set of features. Git makes the process of creating these branches, and then subsequently merging them back together, nearly painless.

Git was originally created for managing the Linux kernel source. By making them easier, it encourages small commits, forking of projects and merging between forks, and having lots of short-lived branches.

The biggest change for people who are used to CVS or Subversion is that every checkout contains not only the source tree, but also the whole history of the project. Common operations like diffing of revisions, checking out older revisions, committing (to your local history), creating a branch, checking out a different branch, merging branches or patch files can all be done locally without having to communicate with a central server. Thus the biggest source of latency and unreliability is removed. Communicating with the "upstream" repository is only needed to get the latest changes, and to publish your local changes to other developers. This turns what was previously a technical constraint (whoever has the repository owns the project) into an organisational choice (your "upstream" is whomever you choose to sync with).

Versions

VersionRelease Date
2.112016-11-29
2.10.22016-10-28
2.102016-09-02
2.92016-06-13
2.82016-03-28
2.72015-10-04
2.62015-09-28
2.52015-07-27
2.42015-04-30
2.32015-02-05
2.22014-11-26
2.12014-08-16
2.02014-05-28
1.92014-02-14
1.8.32013-05-24
1.82012-10-21
1.7.102012-04-06
1.72010-02-13
1.6.52009-10-10
1.6.32009-05-07
1.62008-08-17
1.5.32007-09-02
1.52007-02-14
1.42006-06-10
1.32006-04-18
1.22006-02-12
1.12006-01-08
1.02005-12-21
0.992005-07-11
Still have a question about Getting started with Git? Ask Question

Topic Outline