Git
Chapters ▾ 2nd Edition

2.1 پایه های گیت - داشتن یک مخزن گیت

اگر تنها یک فصل را برای آغاز کردن گیت باید خواند، آن فصل همین است. این فصل تمام فرمان های پایه ای را که برای انجام بخش زیادی از کارهای گیت نیاز دارم پوشش می دهد. در کار با گیت زمان زیادی را باید با ین دستورات و فرمان ها گذراند. در پایان این بخش، شما باید توانایی پیکربندی و راه اندازی یک مخرن، آغازیدن و پایان بخشیدن به دنبال کردن فایلهاو ثبت تغییرات را داشته باشید. همچنین به شما نشان خواهیم داد که چگونه گیت برخی از فایلها و الگوهای نام فایل را نادیده می گیرد، چگونه اشتباهات را به سادگی و سرعت برگردانید، چگونه تاریخچه ای از پروژه را وارسی کنید و تغییرات بین ثبت های مختلف را با هم برابر سازی و مقایسه کنید. و همچنین چگونه از مخازن دوردست واکشی کنید و ثبت ها را به آنها اعمال کنید.

داشتن یک مخزن گیت

شما می توانید مخرن گیت را به یکی از دو روش زیر به دست آورید:

  1. یک پوشه محلی که تحت نظارت کنترل نسخه نیست، آن را به مخرن گیت تبدیل می کنید

  2. نسخه برداری کنید. (clone) از یک مخزن گیت موجود.

به هر روی شما یک مخزن گیت محلی دارید که آماده به کار است.

راه اندازی مخرن گیت در یک پوشه موجود

اگر شما یک پوشه از پروژه را دارید که هنوز تحت نظارت کنترل نسخه نیست و می خواهید که مدیریت نسخه های آن را به کمک گیت انجام دهید، در آغاز به پوشه اصلی پروژه بروید. اگر تا کنون این کار را نکرده اید، این کار به نظر می رسد بسته سیستم عامل شما کمی گوناگون باشد:

در لینوکس:

$ cd /home/user/my_project

در مک:

$ cd /Users/user/my_project

در ویندوز:

$ cd /c/user/my_project

و سپس در آنجا دستور زیر را بزنید:

$ git init

با زدن این دستور یک پوشه تاره به نام .git ساخته می شود که تمام فایلهایی که مخزن نیاز دارد — اسکلت یک مخزن گیت — را در برد دارد. تا ایجای کار، گیت تغییرات هیچ فایلی را دنبال نمی کند. (برای اینکه بدانید در پوشه .git که هم اکنون ایجاد کردید، چه فایلهایی وجود دارند، Git Internals را ببینید.)

If you want to start version-controlling existing files (as opposed to an empty directory), you should probably begin tracking those files and do an initial commit. You can accomplish that with a few git add commands that specify the files you want to track, followed by a git commit:

$ git add *.c
$ git add LICENSE
$ git commit -m 'initial project version'

We’ll go over what these commands do in just a minute. At this point, you have a Git repository with tracked files and an initial commit.

Cloning an Existing Repository

If you want to get a copy of an existing Git repository — for example, a project you’d like to contribute to — the command you need is git clone. If you’re familiar with other VCS systems such as Subversion, you’ll notice that the command is "clone" and not "checkout". This is an important distinction — instead of getting just a working copy, Git receives a full copy of nearly all data that the server has. Every version of every file for the history of the project is pulled down by default when you run git clone. In fact, if your server disk gets corrupted, you can often use nearly any of the clones on any client to set the server back to the state it was in when it was cloned (you may lose some server-side hooks and such, but all the versioned data would be there — see Getting Git on a Server for more details).

You clone a repository with git clone <url>. For example, if you want to clone the Git linkable library called libgit2, you can do so like this:

$ git clone https://github.com/libgit2/libgit2

That creates a directory named libgit2, initializes a .git directory inside it, pulls down all the data for that repository, and checks out a working copy of the latest version. If you go into the new libgit2 directory that was just created, you’ll see the project files in there, ready to be worked on or used.

If you want to clone the repository into a directory named something other than libgit2, you can specify that as the next command-line option:

$ git clone https://github.com/libgit2/libgit2 mylibgit

That command does the same thing as the previous one, but the target directory is called mylibgit.

Git has a number of different transfer protocols you can use. The previous example uses the https:// protocol, but you may also see git:// or user@server:path/to/repo.git, which uses the SSH transfer protocol. Getting Git on a Server will introduce all of the available options the server can set up to access your Git repository and the pros and cons of each.