Git инструкция шпаргалка для начинающих: Инструкция-шпаргалка для начинающих / Хабр

Шпаргалка по основам Git/GitHub. Руководство по контролю версий для… | by Vlad Kopenkin

Если Вы всё еще не знакомы с системой контроля версий и её использование не входит в Ваш рабочий процесс, то сейчас — самое время начать! Это основополагающее руководство поможет Вам начать работу с Git и даст Вам прочный фундамент для дальнейшего развития. Git почти наверняка используется на любом серьёзном проекте и чем раньше Вы научитесь им пользоваться, тем более ценным сотрудником Вы станете для работодателей. Так же, это улучшит Ваш личный опыт, так как Вы без проблем сможете переключаться между несколькими компьютерами, не волнуясь при этом о переносе проекта через флэш накопители… Работа в команде станет гораздо легче. Бывали ли у Вас случаи, когда код становился настолько запутанным, что казалось, будто было бы легче начать проект с нуля? С системой контроля версий Вы сможете просто вернуться к стабильной версии, без всего того что Вы успели воплотить в 4 часа утра.

Git — это одна из систем контроля версий. По существу это значит, что она хранит всю историю изменений проекта. История Вашего проекта и история изменений этого же проекта у Ваших коллег — у всего будет копия. Это полная противоположность SVN, где вся история изменений храниться в одном месте.

GitHub, часто путают с Git. На самом деле — это хостинг репозиториев. Возможно Вам пока непонятно что такое репозиторий, но не спешите закрывать статью, к концу всё прояснится. Вкратце, GitHub — это то место, куда Вы будете загружать историю изменений проекта используя Git.

Git достаточно мудрёный и выучить каждую из его команд не так-то просто, но для начала работы Вам нужно знать всего несколько ключевых понятий. Чем больше Вы будете использовать Git, тем чаще Вы будете сталкиваться с ситуацией, когда начальных знаний окажется недостаточно, но существует большое количество ресурсов, которые придут к Вам на помощь. Так что используйте это руководство как трамплин, не забывая о дальнейшем развитии.

Первым делом мы загрузим Git. Для пользователей Windows я советую установить и Git Bash, который доступен после установки Git. Для пользователей Mac, использование Terminal будет достаточным. После завершения установки приступайте к регистрации аккаунта GitHub. Итак, у Вас есть Git, инструмент командной строки, и GitHub аккаунт, куда Вы будете загружать свои репозитории.

Используя Git Bash или Terminal перейдите в корневую директорию проекта. Если Вы используете Git Bash, то с помощью правого клика можно выбрать “Git Bash Here” и он запустится в рабочей директории.

git init
Эта команда создаст .git репозиторий в Вашем проекте. Репозиторий или “repo” это коллекция всех изменений, которые были совершены на протяжении всего времени после инициализации репозитория. Это первое что нужно сделать для нового проекта.

git config --global user.name "Ваше Имя"
git config --global user.email "ВашаПочта@mail.com"
Эти команды определят информацию, которая будет использоваться при каждом commit(фиксирование изменений). Их стоит выполнить всего один раз при первичной установке Git.

git add имяФайла.расширение
Замените “имяФайла.расширение” на любой файл, изменения которого Вы пытаетесь зафиксировать, например “index.html”. Эта команда добавит файл в “staging area”(участок подготовки). Воспринимайте staging area, как секцию в которой файлы проходят подготовку к перемещению в Ваш репозиторий.

git add .
Если Вы хотите добавить всё из директории проекта в staging area, то эта команда сделает всё сама.

git add *.html
Если Вы хотите добавить все файлы с расширением .html в staging area то эта команда отлично подойдет. Расширение можно менять в зависимости от предпочтений.

git status
Покажет что уже было добавлено в staging area и какие файлы были изменены и ждут перемещения в staging area.

git reset имяФайла. расширение
Убирает выбранный файл из staging area.

git rm --cached имяФайла.расширение
Убирает файл из staging area и определяет его как игнорируемый.

git commit -m "Описание коммита"
Берёт файлы из staging area и “фиксирует” их в Ваш локальный репозиторий. В кавычки следует вставить краткое описание изменений для конкретного коммита. Постарайтесь описать коммит краткими деталями, например: “устранил проблему при изменении имени пользователя” вместо подобных сообщений “какие-то изменения”

touch .gitignore
Эта команда создаст файл с названием .gitignore. Вы можете открыть этот файл в текстовом редакторе и прописать названия файлов или директорий, изменения в которых Вы не хотели бы отслеживать (они будут игнорироваться Git). Изменения в игнорируемых файлах не будут отображаться при выполнении git status.

git branch названиеВетки
Создает сущность, называемую branch(ветвь). Ветвь — это точная копия Ваших файлов.

git checkout “названиеВетки”
Позволит Вам переключить контроль над созданной Вами веткой и работать в её пределах. Здесь Вы можете совершать любые изменения кода. Когда Вы будете готовы можно совершить commit изменений и отправить изменения в GitHub (об этом ниже) или же можно удалить ветвь, если что-то пошло не так или Вам больше не нужны изменения сделанные в этой ветке.

git merge названиеВетки
Находясь в Master(главной) ветви, Вы можете использовать эту команду, чтобы взять коммиты из любой из ветвей и соединить их вместе.

git remote add origin https://github.com/имяПользователя/проект.git
Эта команда определит “местоположение” Вашего удалённого репозитория. Всё что было до этого происходило исключительно в локальном репозитории на Вашем компьютере. Вам нужно будет перейти в GitHub аккаунт и создать новый удалённый репозиторий, куда Вы сможете отправлять изменения из локального репозитория. After you created your remote repository you will be provided with a link and that link is the location you will want to use in the above command.

git remote
Выведет список из всех удалённых репозиториев, которые были добавлены к Вашему проекту.

git push -u origin master
Эта команда отправит локальные изменения в удалённый репозиторий. Таким образом эту команду стоит прописывать только первый раз.

git push
This is what you will use to push your code to GitHub after your initial push.

git clone https://github.com/имяПользователя/проект.git
Если у Вас отсутствует проект на личном или рабочем компьютере, то эта команда поможет клонировать/загрузить весь проект в текущую директорию.

git pull
Если Вы работаете над одним и тем же проектом с несколькими людьми, то эта команда позволит загрузить последнюю версию из удалённого репозитория и обновить вашу локальную версию.

Надеюсь это руководство поможет Вам начать и понимать что вообще происходит. Буду рад помочь с уточнениями и ответами на вопросы в комментариях.

Оригинал статьи — ссылка

Шпаргалка по Git. Инструкции по git для начинающих.

Как выписать репозиторий с github

1. Создаем новую директорию для проекта project_name, переходим в нее.
2. Выполняем команду:

  
git clone [email protected]:devlabuser/sharp.git ./

1. «./» означает, что создать репозиторий нужно в текущей директории.

Результат: каталог с выписанной веткой master. Теперь можно создавать новые ветки, или выписывать с github существующие.

Как выписать ветку с github

С помощью команды «checkout» можно выписать уже существующую ветку с github:

$ git checkout -b dev origin/dev
$ git checkout -b project_branch origin/project_branch

Или так, что намного надежнее:

$ git checkout --track origin/production

Если команда не сработала, нужно попробовать выполнить обновление:

$ git remote update

Если вышеприведенные команды не сработали, выдали ошибку, и времени разбираться с ней нет, можно попробовать получить нужную ветку следующим способом:

git checkout -b project_branch
git pull origin project_branch

Т. е. сначала мы создаем новую ветку, а затем вливаем в нее изменения из ветки на github.

Как создать новую ветку в локальном репозитории

1. Создаем новую ветку в локальном репозитории:

$ git checkout -b dev
Switched to a new branch 'dev'

2. Публикуем ее на github:

$ git push origin dev
Total 0 (delta 0), reused 0 (delta 0)
To [email protected]:devlabuser/sharp.git
 * [new branch]      dev -> dev

Как переключиться на другую ветку в git

$ git checkout project2_branch

Если вы случайно удалили какой-то файл, можно извлечь его из хранилища:

$ git checkout readme.txt

Как посмотреть список веток

Команда «branch» позволяет посмотреть список веток в локальном репозитории. Текущая ветка будет помечена звездочкой:

$ git branch
* dev
  master

Как сделать commit

Создаем новую ветку, выполняем в ней нужные изменения.

1. Список всех измененных и добавленных файлов можно просмотреть командой:

  
$ git status

2. Подготавливаем коммит, добавляя в него файлы командой:

$ git add <file1> <file2> ...

Или удаляем устаревшие файлы:

$ git rm <file1> <file2> ...

3. Выполняем коммит:

$ git commit -m 'Комментарий к коммиту'

4. Как правило, в репозитории существует две основные ветки — dev и master. Dev — общая ветка разработчиков и тестировщиков. Именно в нее добавляются все новые разработки перед очередным релизом. Master — ветка для выкладки продукта на боевые сервера.

После коммита надо влить в нашу ветку изменения из ветки dev и master:

$ git pull origin dev 
$ git pull origin master

Теперь наша ветка содержит изменения для проекта, и все последние изменения по другим задачам, которые успела внести команда.

5. Переключаемся на ветку dev:

$ git checkout dev

6. Вливаем в dev изменения из ветки проекта:

  
$ git merge project_branch

7. Заливаем последнюю версию ветки dev на удаленный сервер:

$ git push origin dev
 
Counting objects: 4, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 286 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To [email protected]:devlab/sharp.git
   d528335..9a452d9  dev -> dev

push может не пройти, потому что удалённый origin/dev обогнал локальную его копию.

Как решить конфликт бинарных файлов

Допустим, при слиянии с другой веткой git выдал ошибку. Команда git status возвращает информацию о конфликте:

$ git status
...
Unmerged paths:
  (use "git add <file>. .." to mark resolution)
 
        both modified:      root/css/styles.css.gz
 
 
$ git diff root/css/styles.css.gz
diff --cc root/css/styles.css.gz
index 970c721,bc6d170..0000000
Binary files differ

Конфликтный файл является бинарным (это могут быть архивные файлы, изображения и т.п.), и решение конфликта стандартным способом, с помощью редактирования — не возможно.

Чтобы решить такой конфликт, надо просто выбрать — какая версия файла будет использоваться: ваша или из вливаемой ветки. Чтобы использовать свой вариант файла, вводим команду:

git checkout --ours binary.dat
git add binary.dat

Если мы выбираем версию из вливаемой ветки:

git checkout --theirs binary.dat
git add binary.dat

«ours» — от английского «наш», «theirs» — от английского «их».

Как посмотреть историю изменений

git log — просмотр логов.

$ git log
commit 9a452d9cdbdb57e7e4f2b09f8ce2f776cd56657a
Author: DevLab User <[email protected]>
Date:   Wed Jul 31 18:35:47 2013 +0400
 
    first commit
 
commit d528335724dfc15461996ed9d44d74f23ce6a075
Author: DevLab User <[email protected]>
Date:   Wed Jul 31 06:24:57 2013 -0700
 
    Initial commit

Вывод данных о каждом коммите в одну строку:

git log --pretty=oneline
 
9a452d9cdbdb57e7e4f2b09f8ce2f776cd56657a first commit
d528335724dfc15461996ed9d44d74f23ce6a075 Initial commit

Для вывода информации git log использует просмотрщик, указанный в конфиге репозитория. d528335 (devlabuser 2013-07-31 06:24:57 -0700 2) =====

git annotate, выводит измененные строки и информацию о коммитах, где это произошло:

$ git annotate readme.txt
9a452d9c        (DevLab User      2013-07-31 18:35:47 +0400       1)Text

Как сделать откат

1. git log — просмотр логов, показывает дельту (разницу/diff), привнесенную каждым коммитом.

commit 9a452d9cdbdb57e7e4f2b09f8ce2f776cd56657a
Author: devlabuser <[email protected]>
Date:   Wed Jul 31 18:35:47 2013 +0400
 
    first commit
 
commit d528335724dfc15461996ed9d44d74f23ce6a075
Author: devlabuser <[email protected]>
Date:   Wed Jul 31 06:24:57 2013 -0700
 
    Initial commit

1. Копируем идентификатор коммита, до которого происходит откат.
2. Откатываемся до последнего успешного коммита (указываем последний коммит):

$ git reset --hard 9a452d955bdb57e7e4f2b09f8ce2fbb6cd56377a
HEAD is now at 9a45779 first commit

Можно откатить до последней версии ветки:

 $ git reset --hard origin/dev
HEAD is now at 9a45779 first commit

После того, как откат сделан, и выполнен очередной локальный коммит, при попытке сделать push в удаленный репозиторий, git может начать ругаться, что версия вашей ветки младше чем на github и вам надо сделать pull. Это лечится принудительным коммитом:

git push -f origin master

Как выполнить слияние с другой веткой

git merge выполняет слияние текущей и указанной ветки. Изменения добавляются в текущую ветку.

$ git merge origin/ticket_1001_branch

git pull забирает изменения из ветки на удаленном сервере и проводит слияние с активной веткой.

  
$ git pull origin ticket_1001_branch

git pull отличается от git merge тем, что merge только выполняет слияние веток, а pull прежде чем выполнить слияние — закачивает изменения с удаленного сервера. merge удобно использовать для слияния веток в локальном репозитории, pull — слияния веток, когда одна из них лежит на github.

Создание нового локального репозитория

$ mkdir project_dir
$ cd project_dir
$ git init

git cherry-pick

git cherry-pick помогает применить один-единственный коммит из одной ветки к дереву другой.

1. Для этого нужно выписать ветку, в которую будем вливать коммит:

git checkout master

2. Обновить ее:

git pull origin master

3. Выполнить команду, указать код коммита:

git cherry-pick eb042098a5

4. После этого обновить ветку на сервере:

git push origin master

Как раскрасить команды git

После создания репозитория в текущей директории появится субдиректория .git . Она содержит файл config .

[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
[remote "origin"]
        fetch = +refs/heads/*:refs/remotes/origin/*
        url = [email protected]:devlab/sharp.git
[branch "master"]
        remote = origin
        merge = refs/heads/master
[branch "dev"]
        remote = origin
        merge = refs/heads/dev

Чтобы раскрасить вывод git, можно добавить в файл блок [color]:

[color]
        branch = auto
        diff = auto
        interactive = auto
        status = auto
        ui = auto

Setup
——

git clone <repo>
clone the repository specified by <repo>; this is similar to «checkout» in
some other version control systems such as Subversion and CVS

Add colors to your ~/. gitconfig file:

[color] ui = auto
[color «branch»] current = yellow reverse
local = yellow
remote = green
[color «diff»] meta = yellow bold
frag = magenta bold
old = red bold
new = green bold
[color «status»] added = yellow
changed = green
untracked = cyan

Highlight whitespace in diffs

[color] ui = true
[color «diff»] whitespace = red reverse
[core] whitespace=fix,-indent-with-non-tab,trailing-space,cr-at-eol

Add aliases to your ~/.gitconfig file:

[alias] st = status
ci = commit
br = branch
co = checkout
df = diff
dc = diff —cached
lg = log -p
lol = log —graph —decorate —pretty=oneline —abbrev-commit
lola = log —graph —decorate —pretty=oneline —abbrev-commit —all
ls = ls-files

# Show files ignored by git:
ign = ls-files -o -i —exclude-standard

Configuration
————-

git config -e [—global] edit the . git/config [or ~/.gitconfig] file in your $EDITOR

git config —global user.name ‘John Doe’
git config —global user.email [email protected]
sets your name and email for commit messages

git config branch.autosetupmerge true
tells git-branch and git-checkout to setup new branches so that git-pull(1)
will appropriately merge from that remote branch. Recommended. Without this,
you will have to add —track to your branch command or manually merge remote
tracking branches with «fetch» and then «merge».

git config core.autocrlf true
This setting tells git to convert the newlines to the system’s standard
when checking out files, and to LF newlines when committing in

git config —list
To view all options

git config apply.whitespace nowarn
To ignore whitespace

You can add «—global» after «git config» to any of these commands to make it
apply to all git repos (writes to ~/.gitconfig).

Info
—-
git reflog
Use this to recover from *major* mess ups! It’s basically a log of the
last few actions and you might have luck and find old commits that
have been lost by doing a complex merge.

git diff
show a diff of the changes made since your last commit
to diff one file: «git diff — <filename>»
to show a diff between staging area and HEAD: `git diff —cached`

git status
show files added to the staging area, files with changes, and untracked files

git log
show recent commits, most recent on top. Useful options:
—color with color
—graph with an ASCII-art commit graph on the left
—decorate with branch and tag names on appropriate commits
—stat with stats (files changed, insertions, and deletions)
-p with full diffs
—author=foo only by a certain author
—after=»MMM DD YYYY» ex. («Jun 20 2008″) only commits after a certain date
—before=»MMM DD YYYY» only commits that occur before a certain date
—merge only the commits involved in the current merge conflicts

git log <ref>..<ref>
show commits between the specified range. Useful for seeing changes from remotes:
git log HEAD..origin/master # after git remote update

git show <rev>
show the changeset (diff) of a commit specified by <rev>, which can be any
SHA1 commit ID, branch name, or tag (shows the last commit (HEAD) by default)

also to show the contents of a file at a specific revision, use
git show <rev>:<filename>
this is similar to cat-file but much simpler syntax.

git show —name-only <rev>
show only the names of the files that changed, no diff information.

git blame <file>
show who authored each line in <file>

git blame <file> <rev>
show who authored each line in <file> as of <rev> (allows blame to go back in
time)

git gui blame
really nice GUI interface to git blame

git whatchanged <file>
show only the commits which affected <file> listing the most recent first
E.g. view all changes made to a file on a branch:
git whatchanged <branch> <file> | grep commit | \
colrm 1 7 | xargs -I % git show % <file>
this could be combined with git remote show <remote> to find all changes on
all branches to a particular file.

git diff <commit> head path/to/fubar
show the diff between a file on the current branch and potentially another branch

git diff —cached [<file>] shows diff for staged (git-add’ed) files (which includes uncommitted git cherry-pick’ed files)

git ls-files
list all files in the index and under version control.

git ls-remote <remote> [HEAD] show the current version on the remote repo. This can be used to check whether
a local is required by comparing the local head revision.

Adding / Deleting
——————

git add <file1> <file2> …
add <file1>, <file2>, etc… to the project

git add <dir>
add all files under directory <dir> to the project, including subdirectories

git add .
add all files under the current directory to the project
*WARNING*: including untracked files.

git rm <file1> <file2> …
remove <file1>, <file2>, etc… from the project

git rm $(git ls-files —deleted)
remove all deleted files from the project

git rm —cached <file1> <file2> …
commits absence of <file1>, <file2>, etc… from the project

Ignoring
———

Option 1:

Edit $GIT_DIR/.git/info/exclude. See Environment Variables below for explanation on $GIT_DIR.

Option 2:

Add a file .gitignore to the root of your project. This file will be checked in.

Either way you need to add patterns to exclude to these files.

Staging
——-

git add <file1> <file2> …
git stage <file1> <file2> …
add changes in <file1>, <file2> … to the staging area (to be included in
the next commit

git add -p
git stage —patch
interactively walk through the current changes (hunks) in the working
tree, and decide which changes to add to the staging area.

git add -i
git stage —interactive
interactively add files/changes to the staging area. For a simpler
mode (no menu), try `git add —patch` (above)

Unstaging
———

git reset HEAD <file1> <file2> …
remove the specified files from the next commit

Committing
———-

git commit <file1> <file2> … [-m <msg>] commit <file1>, <file2>, etc…, optionally using commit message <msg>,
otherwise opening your editor to let you type a commit message

git commit -a
commit all files changed since your last commit
(does not include new (untracked) files)

git commit -v
commit verbosely, i. e. includes the diff of the contents being committed in
the commit message screen

git commit —amend
edit the commit message of the most recent commit

git commit —amend <file1> <file2> …
redo previous commit, including changes made to <file1>, <file2>, etc…

Branching
———

git branch
list all local branches

git branch -r
list all remote branches

git branch -a
list all local and remote branches

git branch <branch>
create a new branch named <branch>, referencing the same point in history as
the current branch

git branch <branch> <start-point>
create a new branch named <branch>, referencing <start-point>, which may be
specified any way you like, including using a branch name or a tag name

git push <repo> <start-point>:refs/heads/<branch>
create a new remote branch named <branch>, referencing <start-point> on the
remote. Repo is the name of the remote.
Example: git push origin origin:refs/heads/branch-1
Example: git push origin origin/branch-1:refs/heads/branch-2
Example: git push origin branch-1 ## shortcut

git branch —track <branch> <remote-branch>
create a tracking branch. Will push/pull changes to/from another repository.
Example: git branch —track experimental origin/experimental

git branch —set-upstream <branch> <remote-branch> (As of Git 1.7.0)
Make an existing branch track a remote branch
Example: git branch —set-upstream foo origin/foo

git branch -d <branch>
delete the branch <branch>; if the branch you are deleting points to a
commit which is not reachable from the current branch, this command
will fail with a warning.

git branch -r -d <remote-branch>
delete a remote-tracking branch.
Example: git branch -r -d wycats/master

git branch -D <branch>
even if the branch points to a commit not reachable from the current branch,
you may know that that commit is still reachable from some other branch or
tag. In that case it is safe to use this command to force git to delete the
branch.

git checkout <branch>
make the current branch <branch>, updating the working directory to reflect
the version referenced by <branch>

git checkout -b <new> <start-point>
create a new branch <new> referencing <start-point>, and check it out.

git push <repository> :<branch>
removes a branch from a remote repository.
Example: git push origin :old_branch_to_be_deleted

git co <branch> <path to new file>
Checkout a file from another branch and add it to this branch. File
will still need to be added to the git branch, but it’s present.
Eg. git co remote_at_origin__tick702_antifraud_blocking …./…nt_elements_for_iframe_blocked_page.rb

git show <branch> — <path to file that does not exist>
Eg. git show remote_tick702 — path/to/fubar.txt
show the contents of a file that was created on another branch and that
does not exist on the current branch.

git show <rev>:<repo path to file>
Show the contents of a file at the specific revision. Note: path has to be
absolute within the repo.

Merging
——-

git merge <branch>
merge branch <branch> into the current branch; this command is idempotent
and can be run as many times as needed to keep the current branch
up-to-date with changes in <branch>

git merge <branch> —no-commit
merge branch <branch> into the current branch, but do not autocommit the
result; allows you to make further tweaks

git merge <branch> -s ours
merge branch <branch> into the current branch, but drops any changes in
<branch>, using the current tree as the new tree

Cherry-Picking
—————

git cherry-pick [—edit] [-n] [-m parent-number] [-s] [-x] <commit>
selectively merge a single commit from another local branch
Example: git cherry-pick 7300a6130d9447e18a931e898b64eefedea19544

git hash-object <file-path>
get the blob of some file whether it is in a repository or not

Find the commit in the repository that contains the file blob:

obj_blob=»$1″
git log —pretty=format:’%T %h %s’ \
| while read tree commit subject ; do
if git ls-tree -r $tree | grep -q «$obj_blob» ; then
echo $commit «$subject»
fi
done

Squashing
———
WARNING: «git rebase» changes history. Be careful. Google it.

git rebase —interactive HEAD~10
(then change all but the first «pick» to «squash»)
squash the last 10 commits into one big commit

Conflicts
———

git mergetool
work through conflicted files by opening them in your mergetool (opendiff,
kdiff3, etc.) and choosing left/right chunks. The merged result is staged for
commit.

For binary files or if mergetool won’t do, resolve the conflict(s) manually
and then do:

git add <file1> [<file2> …]

Once all conflicts are resolved and staged, commit the pending merge with:

git commit

Sharing
——-

git fetch <remote>
update the remote-tracking branches for <remote> (defaults to «origin»).
Does not initiate a merge into the current branch (see «git pull» below).

git pull
fetch changes from the server, and merge them into the current branch.
Note: .git/config must have a [branch «some_name»] section for the current
branch, to know which remote-tracking branch to merge into the current
branch. Git 1.5.3 and above adds this automatically.

git push
update the server with your commits across all branches that are *COMMON*
between your local copy and the server. Local branches that were never
pushed to the server in the first place are not shared.

git push origin <branch>
update the server with your commits made to <branch> since your last push.
This is always *required* for new branches that you wish to share. After
the first explicit push, «git push» by itself is sufficient.

git push origin <branch>:refs/heads/<branch>
E.g. git push origin twitter-experiment:refs/heads/twitter-experiment
Which, in fact, is the same as git push origin <branch> but a little
more obvious what is happening.

Reverting
———

git revert <rev>
reverse commit specified by <rev> and commit the result. This does *not* do
the same thing as similarly named commands in other VCS’s such as «svn
revert» or «bzr revert», see below

git checkout <file>
re-checkout <file>, overwriting any local changes

git checkout .
forgot something in your last commit? That’s easy to fix. Undo your last
commit, but keep the changes in the staging area for editing.

git commit —amend
redo previous commit, including changes you’ve staged in the meantime.
Also used to edit commit message of previous commit.

Plumbing
———

test <sha1-A> = $(git merge-base <sha1-A> <sha1-B>)
determine if merging sha1-B into sha1-A is achievable as a fast forward;
non-zero exit status is false.

Stashing
———

git stash
git stash save <optional-name>
save your local modifications to a new stash (so you can for example
«git svn rebase» or «git pull»)

git stash apply
restore the changes recorded in the stash on top of the current working tree
state

git stash pop
restore the changes from the most recent stash, and remove it from the stack
of stashed changes

git stash list
list all current stashes

git stash show <stash-name> -p
show the contents of a stash — accepts all diff args

git stash drop [<stash-name>] delete the stash

git stash clear
delete all current stashes

Remotes
——-

git remote add <remote> <remote_URL>
adds a remote repository to your git config. Can be then fetched locally.
Example:
git remote add coreteam git://github.com/wycats/merb-plugins.git
git fetch coreteam

git push <remote> :refs/heads/<branch>
delete a branch in a remote repository

git push <remote> <remote>:refs/heads/<remote_branch>
create a branch on a remote repository
Example: git push origin origin:refs/heads/new_feature_name

git push <repository> +<remote>:<new_remote>
replace a <remote> branch with <new_remote>
think twice before do this
Example: git push origin +master:my_branch

git remote prune <remote>
prune deleted remote-tracking branches from «git branch -r» listing

git remote add -t master -m master origin git://example.com/git.git/
add a remote and track its master

git remote show <remote>
show information about the remote server.

git checkout -b <local branch> <remote>/<remote branch>
Eg. :
git checkout -b myfeature origin/myfeature
git checkout -b myfeature remotes/<remote>/<branch>

Track a remote branch as a local branch. It seems that
somtimes an extra ‘remotes/’ is required, to see the exact
branch name, ‘git branch -a’.

git pull <remote> <branch>
git push
For branches that are remotely tracked (via git push) but
that complain about non-fast forward commits when doing a
git push. The pull synchronizes local and remote, and if
all goes well, the result is pushable.

git fetch <remote>
Retrieves all branches from the remote repository. After
this ‘git branch —track …’ can be used to track a branch
from the new remote.

Submodules
———-

git submodule add <remote_repository> <path/to/submodule>
add the given repository at the given path. The addition will be part of the
next commit.

git submodule update [—init] Update the registered submodules (clone missing submodules, and checkout
the commit specified by the super-repo). ..d8efce43099
Revision does not need to be fully specified.

git am <patch file>
Applies the patch file generated by format-patch.

git diff —no-prefix > patchfile
Generates a patch file that can be applied using patch:
patch -p0 < patchfile
Useful for sharing changes without generating a git commit.

Tags
—-

git tag -l
Will list all tags defined in the repository.

git co <tag_name>
Will checkout the code for a particular tag. After this you’ll
probably want to do: ‘git co -b <some branch name>’ to define
a branch. Any changes you now make can be committed to that
branch and later merged.

Archive
——-

git archive master | tar -x -C /somewhere/else
Will export expanded tree as tar archive at given path

git archive master | bzip2 > source-tree.tar.bz2
Will export archive as bz2

git archive —format zip —output /full/path master
Will export as zip

Git Instaweb
————

git instaweb —httpd=webrick [—start | —stop | —restart]

Environment Variables
———————

GIT_AUTHOR_NAME, GIT_COMMITTER_NAME
Your full name to be recorded in any newly created commits. Overrides
user.name in .git/config

GIT_AUTHOR_EMAIL, GIT_COMMITTER_EMAIL
Your email address to be recorded in any newly created commits. Overrides
user.email in .git/config

GIT_DIR
Location of the repository to use (for out of working directory repositories)

GIT_WORKING_TREE
Location of the Working Directory — use with GIT_DIR to specifiy the working directory root
or to work without being in the working directory at all.

Changing history
—————-

Change author for all commits with given name

git filter-branch —commit-filter ‘
if [ «$GIT_COMMITTER_NAME» = «<Old Name>» ];
then
GIT_COMMITTER_NAME=»<New Name>»;
GIT_AUTHOR_NAME=»<New Name>»;
GIT_COMMITTER_EMAIL=»<New Email>»;
GIT_AUTHOR_EMAIL=»<New Email>»;
git commit-tree «[email protected]»;
else
git commit-tree «[email protected]»;
fi’ HEAD

DVCS Git и TortoiseGit в картинках. Пособие для начинающих чайников.

Что такое git? git — это распределенная система управления версиями.

Не так давно проект «Google API в Delphi» успешно переехал на новый адрес и теперь находится под управлением распределенной системы контроля версий Git. Для чего и почему мы это сделали — это вопрос второстепенный, а вот работа с Git, по крайней мере для меня, стала основной. По сути этот пост ни что иное как шпаргалка для себя любимого по выполнению основных операций при работе Git, но может эта шпаргалка поможет кому-то как и мне начать работу с этой DVCS.

Если Вы работаете в Delphi, то в этой статье представлено пошаговое руководство по настройке и работе с Git непосредственно из IDE Delphi

Небольшое введение. О чем вообще пойдет речь

Git — распределённая система управления версиями файлов. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux.

То обстоятельство, что система создавалась «под Linux» уже как бы намекает на то, что без консоли нам не обойтись. Но не стоит махать руками и кричать «консоль отстой, git — в печь» и все такое. Поверьте — консоль Linux и консоль Windows имеют для обычного пользователя только одно общее свойство — чёрный экран при первом запуске. Команды Linux (ИМХО) просты и запоминаются без проблем, а работать с консолью не составляет особого труда даже для такого чайника, как я.

Самым главным, на мой взгляд, отличием Git от того же SVN является то, что в Git нет такого понятия как главный репозиторий. Каждый разработчик использует свою локальную версию репозитория, в которую делает commit’ы и, при необходимости, синхронизирует все изменения с репозиторием, располагающимся на сервере.

Это обстоятельство и поставило меня в начале работы с Git в тупик.
Как это так commit и не в центральный репозиторий?
Как правильно отправлять данные на сервер?
Как вообще начинать работу?
Эти и ещё многие другие вопросы посещали меня на старте работы с Git. Сейчас я не буду углубляться далеко в теоретические вопросы Git, да и вообще любых систем контроля версия — всего этого полно в Сети. А затрону один практический момент — как начать работу вообще, чтобы потом не было мучительно больно за бесцельно потерянные исходники.

Качаем и устанавливаем софт

Для работы с Git под Windows имеются вполне работоспособные и юзабельные решения, например, msysgit. Однако если Вы ранее имели опыт работы с SVN и использовали в работе TortoiseSVN, то видимо, Вам захочется иметь аналог подобного интерфейса и для Git? Нет проблем вот аналог TortoiseSVN для Git — TortoiseGit.
По сути TortoiseGit после нажатия команды из контекстного меню запускает консольную команду из MSysGit и рисует в окошко ее вывод. Если вы не хотите или просто не хватает времени детально разобраться в консольных командах Git, то TortoiseGit — то, что Вам нужно.
Итак, если Вы работаете под 32-х битной Windows, то Вам необходимо скачать следующий софт:

1. msysgit — качаем Git-1. 7.1-previewXXXXXXXX.exe (11,6 Mb) Git For Windows
2. TortoiseGit. На момент написания статьи последней была версия TortoiseGit-1.5.2.0-32bit.msi (19.6 MB). Новые версии Вы можете найти также по приведенной ссылке.

Получается, что скачать нам надо чуть больше 30 Mb.
Теперь устанавливаем скачанные программы.

Вначале ставим msysgit, а потом TortoiseGit.

При установке msysgit настройки по умолчанию можно не изменять.
При установке TortoiseGit выбираем в окне «Choose SSH Client» второе значение:

После успешной установки обоих продуктов работу над первым этапом можно считать завершенной. Приступим ко второму — получение доступа к репозиторию Git.

Получаем доступ к репозиторию

В качестве примера я буду рассматривать получение доступа к нашему репозиторию, который располагается на github.com.
Распишем все операции по шагам.

1. Регистрация на GitHub’e.

Эта операция не отличается абсолютно ничем от всех прочих регистраций на других сайтах. Единственное, что нам необходимо обязательно запомнить — адрес email который мы указывали при регистрации. Этот адрес можно видеть на главной странице своего профиля:

Профиль на GitHub.com

2. Генерируем ключ для доступа по SSH.
Вот тут хочешь-не хочешь, а надо запускать консоль. После установки msysgit у Вас на рабочем столе появился новый ярлык — Git Bush — вот с помощью него и запускаем консоль.

1. Набираем в консоли следующую команду
   

   ssh-keygen -t rsa -C «E-Mail из Вашего профиля»

2. На экране появится запрос «Enter file in which to save the key». Пока оставим значение по умолчанию. Жмем Enter.
3. Нас попросят ввести пароль. Эту часть тоже пропускаем — впоследствии пароль можно будет установить, а пока — учимся. Жмем опять Enter.
4. Сгенерируются два файла один из которых — публичный ключ для доступа.

Если Вы все делали с настройками по умолчанию то файлы будут располагаться в директории:

C:/Documents and Settings/UserName/.ssh/

Заходим в директорию, открываем с помощью «Блокнота» файл ida_rsa.pub и копируем все его содержимое в буфер обмена.

3. Заносим публичный ключ доступа в профиль.

Для записи публичного ключа в профиль:

1. Заходим в свой профиль github и жмем ссылку Account Settings (сверху)
2. Выбираем пункт «SSH Public Keys»
3. Жмем ссылку «Add another public key»

Перед вами появится форма добавления нового публичного ключа. Вставляем из буфере весь скопированный ранее текст (из файла ida_rsa.pub) только в поле key — поле Title оставляем пустым.

На этом работа с публичными ключами закончена.

4. Просимся в проект.

Для этого достаточно найти наш проект на github и отправить одному из администраторов запрос на предоставление доступа к репозиторию. Или просто отправить мне email с логином на github. После того как вы будите записаны в список разработчиков проекта можно переходить к следующей фазе работы — получение исходников.

Работа со своим первым репозиорием Git

Доступ получен, исходники в Вашем распоряжении. Теперь переключаемся на работу с TortoiseGit. Для порядка, каждую из операций, которые мы будем сейчас выполнять я буду также записывать в виде консольной команды — лишним знание работы с консолью никогда не будут.

Итак, выбираем директорию на жестком диске где мы будем хранить все файлы. Далее действуем следующим образом:

1. Вызываем контекстное меню и выбираем пункт «TortoiseGit — Settings«:

В появившемся окне переходим сразу к пункту «Git — Config» и записываем свое имя и адрес электронной почты. Эти данные должны в точности совпадать с теми, что записаны в Вашем аккаунте на github, иначе ваш ключ просто не подойдет.

2. Клонируем репозиторий. Для этого заходим на страницу проекта, и копируем в буфер адрес:

Теперь жмем правой кнопкой мыши на директории, в которой будем хранить исходники и в меню выбираем «Git Clone..«:

В открывшемся окне в поле URL вставляем скопированный адрес и жмем «Ok»:

Начнется процесс клонирования репозитория.

Всё вышесказанное можно было бы заменить всего двумя командами в консоли:

cd path/to/dir
git clone URL

После клонирования репозитория Вы автоматически переключитесь на нашу главную ветку (master). Так как каждый из нас занят определенной работой в проекте, то у каждого своя ветвь в репозитории, поэтому и Вам придется создавать свой branch. Делается это достаточно просто.

3. Создаем свою ветку. Для этого жмем правую кнопку мыши на директории в которую мы клонировали репозиторий и выбираем в меню «TortoiseGit — Create Branch«:

В открывшемся оке задаем название новой ветки и указываем на основании какой ветки репозитория мы будем создавать новую. Жмем «Ок», подтверждая создание ветки. Теперь переключаемся на свой новый branch.

Выбираем в меню «TortoiseGit — Switch/Checkout…«:

В открывшемся окне выбираем нашу новую ветку и жмем «Ок». Убеждаемся, что мы успешно переключились:

По сути, все что касалось создания нового branch’a в консоли решилось бы всего одной командой:

checkout -b new-branch

4. Программируем. Теперь, когда мы все настроили — открываем необходимый проект в Delphi, вносим свои коррективы, изменяем модули и т.д. В общем ведем нормальную плодотворную работу с проектом.

5. Вносим изменения в репозиторий. После того как внесены какие-то изменения нам необходимо их закрепить в Git. И здесь опять же проявляется отличие этой системы контроля версий от того же SVN. Дело в том, что Commit в Git не сбрасывается сразу на сервер. Для того, чтобы внести изменения в удаленный репозиторий используется команда PUSH. В общем виде работа может быть построена следующим образом:

1. Вносятся изменения в проект

2. Изменения закрепляются в вашем локальном репозитории, используя команду Commit в меню или, используя консоль:

git commit

3. Когда Вам необходимо/удобно/требуется закрепить все изменения на сервере выполняем push в свою ветку (brunch). Команда консоли выглядит так:

git push origin <свое имя бранча>

Здесь стоит, наверное рассмотреть весь процесс на деле. К примеру, мы решили добавить в проект простой текстовый файл с описанием чего либо. Создаем файл, записываем в него данные и добавляем файл в индекс.

Для этого выбираем новый файл, вызываем меню и выбираем «Add…»:

По рисунку можно видеть, что я вношу в индекс новый файл text.txt. Жмем «Ok».

После того как файл добавлен, можно сразу же сделать Commit — кнопка Commit появится в окне с выводом консоли. Жмем её и откроется окно для внесения Commit’a:

Заполняем поле с описанием, жмем «Ок»  и коммит готов. Если хотите сразу отправить эти изменения в репозиторий, то в окне с выводом консоли появится также кнопка PUSH. Если же Вас не устраивает таскать по 1 файлику туда-сюда или изменения столь незначительны, что их нет смысла отправлять на сервер, то просто продолжаете дальше кодить, а push выполним позднее.

Чтобы выполнить команду push можете поступить следующим образом:

1. Зажимаем Shift и вызываем контекстное меню. В меню должны появится дополнительные команды:

Выбираем команду Push. Перед Вами откроется окно следующего содержания:

Все, что от Вас требуется на данном этапе — нажать на кнопку (на рисунке она выделена красным) найти в списке удаленную ветку в которую вы делаете push и два раза нажать Ok. Все изменения, произведенные Вами в локальном репозитории отправятся в Сеть.

Вот пожалуй все, что мне пока потребовалось использовать при работе с новой для меня системой контроля версий. Надеюсь эта мини-шпаргалка поможет кому-нибудь кроме меня. А если Вас заинтересовала работа с консолью, то как раз сейчас я изучаю Вот такие топики на habrahabr.ru:
1. Git Workflow.
2. Git Wizardry
Статьи написаны понятным простым языком и касаются как раз работы с Git с нуля.

Книжная полка

0 0 голоса

Рейтинг статьи

Памятка по Git для начинающих

Follow @Cloudways

В предыдущих частях этой серии я рассмотрел важные темы, такие как руководство по Git для начинающих, управление ветками и разрешение конфликтов, а также лучшие клиенты Git с графическим интерфейсом для разных платформ. В этой шпаргалке по Git я расскажу о наиболее часто используемых командах Git. Этот список будет разделен на категории и будет иметь краткое описание каждой команды. Я добавил раздел о терминологии Git, чтобы вы могли понять, как работает Git и как команды выполняются на различных объектах.

Git — это огромная платформа с набором команд, которые охватывают все аспекты функций Git. Начнем сначала с терминологии Git:

Git Terminologies

#	Команда Git	Описание
1	Чистый репозиторий	Репозиторий без рабочего каталога.
2	Филиал	Филиал — это активная область разработки в Git. Самая последняя фиксация показывает верхушку ветки.
3	Виноват	Описывает последнюю модификацию каждой строки в файле. Показывает редакцию, автора и время.
4	Касса	Это относится к процессу, в котором любая данная фиксация выбирается из репозитория, а состояние связанного файла и дерева каталогов воссоздается в рабочем каталоге.
5	Зафиксировать	Это единственная точка в истории Git, которая содержит информацию о наборе изменений.
6	Дифф.	Diff — это разница в изменениях между двумя фиксациями или сохраненными изменениями.
7	Съемная головка	Состояние, в котором конкретная фиксация извлекается вместо ветки.
8	Получить	Извлечение означает получение последних изменений в ветке и локальных/удаленных репозиториях.
9	Вилка	Разветвляя репозиторий, вы сможете добавлять коммиты и создавать запросы на извлечение.
10	Хэш	Уникальный код SHA1 для каждой фиксации
11	Головка	Именованная ссылка на фиксацию в конце ветки
12	Индекс	Набор файлов с информацией о состоянии.
13	Объединить	Чтобы вывести содержимое другой ветки в текущую ветку.
14	Мастер	Ветвь разработки по умолчанию в Git
15	Происхождение	Основной репозиторий по умолчанию
16	Запрос на вытягивание	Предлагает внести изменения в основную ветку
17	Толчок	Отправляет новые изменения после их фиксации
18	Репозиторий	Набор коммитов, веток и тегов для идентификации коммитов.
19	Рабочее дерево	Дерево фактически извлеченных файлов

Конфигурация Git

#	Команда Git	Описание
1	git config – глобальное имя пользователя	Установите имя пользователя, которое будет использоваться для всех действий
2	git config – глобальный user.email	Укажите адрес электронной почты, который будет использоваться для всех действий.
3	git config – глобальный псевдоним.	Создайте ярлык для команды Git.
4	git config – system core.editor	Установить текстовый редактор для всех командных действий.
5	git config – глобальный – редактировать	Откройте глобальный файл конфигурации в текстовом редакторе для ручного редактирования.
6	git config –global color.ui авто	Включить полезное раскрашивание выходных данных командной строки.

Настройка репозитория Git

#	Команда Git	Описание
1	гит инициализация	Инициализировать пустой репозиторий Git в текущем проекте.
2	клон git (URL-адрес репозитория)	Клонируйте репозиторий с GitHub в папку проекта.
3	git clone (URL-адрес репозитория) (папка)	Клонировать репозиторий в определенную папку.
4	git удаленное добавление источника https://github.com/username/(repo_name).git	Создайте удаленное репо, указывающее на существующий репозиторий GitHub.
5	гит удаленный	Показывает имена удаленных репозиториев.
6	git удаленный -v	Показывает имя и URL удаленных репозиториев.
7	git remote rm (имя удаленного репо)	Удаляет удаленный репозиторий.
8	git удаленный набор URL-адресов (URL-адрес git)	Изменяет URL-адрес репозитория.
9	git выборка	Получить последние изменения из источника, но не объединять.
10	git тянуть	Получить последние изменения из источника и объединить их.

#	Команда Git	Описание
1	git добавить (имя файла)	Добавить текущие изменения в файл для подготовки.
2	git добавить .	Добавить все изменения каталога в staging (без удаления файлов).
3	git добавить -A	Добавить все новые, измененные и удаленные файлы в промежуточную среду.
4	git rm (имя_файла)	Удаляет файл и отменяет его отслеживание (прекращение отслеживания).
5	git rm – кэшированный (имя_файла)	Отменяет отслеживание текущего файла.
6	git mv  (имя_файла) (имя_нового_файла)	Изменяет имя файла и подготавливает его к фиксации.
7	git checkout <имя удаленного файла>	Восстанавливает удаленный файл и подготавливает его к фиксации
8	статус git	Показывает состояние измененных файлов.
9	git ls-files –другое –игнорируется –exclude-standard	Показывает список всех игнорируемых файлов.
10	git разница	Показывает неустановленные изменения в индексе и рабочем каталоге.
11	git diff — поэтапно	Показывает различия файлов между промежуточной и последней версией файла.
12	git diff (имя_файла)	Показывает изменения в одном файле по сравнению с последней фиксацией.

Объявление фиксации

#	Команда Git	Описание
1	git commit -m «(сообщение)»	Фиксирует изменения с помощью пользовательского сообщения.
2	git commit -am «(сообщение)»	Добавляет все изменения в staging и фиксирует их с помощью специального сообщения.
3	git-касса	Переключиться на предоставленный Commit.
4	гит-шоу	Выводит метаданные и изменения содержимого указанной фиксации.
5	git reset — жесткий	Отменить всю историю и вернуться к данной фиксации.
6	git reset — жесткая голова	Отменяет все локальные изменения в рабочем каталоге.
7	журнал git	Показывает историю изменений.
8	журнал git -p	Показывает полное отображение каждой фиксации.
9	журнал git -oneline	Показывает список коммитов с простым сообщением.
10	git log – следовать (имя_файла)	Список истории для текущего файла.
11	виноват git (имя_файла)	Показывает все изменения вместе с именем пользователя.
12	git тайник	Временно сохраняет все измененные отслеживаемые файлы.
13	git stash pop	Восстанавливает последние сохраненные файлы.
14	список тайников git	Список всех наборов изменений тайника.
15	git stash применить	Применить последнее спрятанное содержимое.
16	git stash drop	Удалить последние спрятанные файлы
17	git stash применить (идентификатор тайника)	Повторно применить определенное содержимое тайника по идентификатору.
18	git stash drop (stash_id)	Удалить определенное содержимое тайника по идентификатору.
19	git push	Отправка изменений в Origin.
16	источник git push (имя_ветки)	Отправка ветки в Origin.
17	Git push -f происхождение (имя_ветки)	Принудительно отправляет изменения в Origin.
18	git-тег (имя_тега)	Определите тег для версии.
19	git push	Отправка изменений в Origin.

Ответвления

#	Команда Git	Описание
1	ветка git	Показывает список всех ветвей.
2	ветка git	Создает новую ветвь.
3	ветка git -m	Переименовывает ветвь.
4	ветка git -a	Список всех филиалов, локальных и удаленных.
5	git checkout -b	Создает ветку и переключается на нее.
6	git-касса	Переключиться на указанную ветку.
7	git checkout -b происхождение/	Получить удаленную ветвь из источника в локальный каталог.
8	ветка git -d	Удалить указанную ветвь.
9	git слияние	Объединить текущую ветвь с мастером (сначала извлекать из мастера)
10	git перебазировать	Принимает все изменения ветки и переформулирует на других.
11	git перебазировать	Перебазируйте текущую ветку на базу. Base может быть идентификатором фиксации или именем ветки.
12	git fetch удаленный	Выбирает указанную ветку из репозитория.
13	гит диф..	Показывает различия между двумя ветвями.
14	git pull – перебазировать	Извлекает удаленную копию текущей ветки и перемещает ее в локальную копию.
15	git push — все	Передать все локальные ветки в указанный удаленный репозиторий.

Вы также можете скачать приведенную выше шпаргалку в формате PDF, нажав кнопку загрузки.

Связано: Как автоматизировать Git с помощью Cloudways API

Заключение

Команды Git охватывают весь спектр функций Git. Важно отметить, что невозможно запомнить весь набор команд Git. Более простой способ — использовать эту шпаргалка Git при работе над сложными проектами. Если вы считаете, что я пропустил важную команду или хотел бы добавить к обсуждению, оставьте комментарий ниже.

Поделитесь своим мнением в разделе комментариев. КОММЕНТАРИЙ СЕЙЧАС

Поделиться этой статьей

Shahroze Nawaz

Shahroze — менеджер сообщества PHP в Cloudways — управляемой платформе PHP-хостинга. Помимо работы, он любит кино и путешествия. Вы можете написать ему по адресу [email protected]

. Твиттер Форум сообщества

×

Получить наш информационный бюллетень

Спасибо, что подписались на нас!

Полная шпаргалка для начинающих

ГИТ

05 октября 2022 г.

Домантас Г.

5 минут Чтение

Загрузить полную шпаргалку по Git

Нужно выучить некоторые основные команды GIT? Вы попали в нужное место. Читайте дальше, чтобы открыть для себя нашу удобную шпаргалку, которую вы можете использовать для ежедневного использования.

Начнем!

Понимание рабочего процесса GIT

GIT — это наиболее широко используемая система контроля версий с открытым исходным кодом, которая позволяет отслеживать изменения, внесенные в файлы. Компании и программисты обычно используют GIT для совместной разработки программного обеспечения и приложений.

Проект GIT состоит из трех основных разделов: рабочий каталог , промежуточная область и каталог git .

В рабочем каталоге вы добавляете, удаляете и редактируете файлы. Затем изменения размещаются (индексируются) в области подготовки. После того, как вы зафиксируете свои изменения, снимок изменений будет сохранен в каталоге git.

Каждый может использовать GIT, так как он доступен для Linux, Windows, Mac и Solaris. Программное обеспечение может иметь крутую кривую обучения, но есть множество руководств по GIT, готовых помочь вам.

Основные команды GIT

Вот некоторые основные команды GIT, которые вам необходимо знать:

• git init создаст новый локальный репозиторий GIT. Следующая команда Git создаст репозиторий в текущем каталоге:

 git init 

• Кроме того, вы можете создать репозиторий в новом каталоге, указав имя проекта:

 git init [имя проекта] 

• git clone используется для копирования репозитория. Если репозиторий находится на удаленном сервере, используйте:

 git clone username@host:/path/to/repository 

• И наоборот, выполните следующую базовую команду, чтобы скопировать локальный репозиторий:

 git clone /path/ to/repository 

• git add используется для добавления файлов в промежуточную область. Например, следующая базовая команда Git проиндексирует файл temp.txt:

 git add  

• git commit создаст моментальный снимок изменений и сохранит его в каталоге git.

 git commit –m «Сообщение для фиксации здесь» 

Pro Tip

Обратите внимание, что любые зафиксированные изменения не попадут в удаленный репозиторий.

• git config можно использовать для установки пользовательских значений конфигурации, таких как адрес электронной почты, имя пользователя, формат файла и т. д. Для иллюстрации команда для настройки электронной почты будет выглядеть так:

 git config --global user.email [email protected] 

• Флаг –global сообщает GIT, что вы собираетесь использовать этот адрес электронной почты для всех локальных репозиториев. Если вы хотите использовать разные адреса электронной почты для разных репозиториев, используйте команду ниже:

 git config --local user. email [email protected] 

• git status отображает список измененных файлов вместе с файлами, которые еще не поставлены и не совершены.

 git status 

• git push используется для отправки локальных коммитов в основную ветку удаленного репозитория. Вот базовая структура кода:

 git push origin  

Pro Tip

Замените на ветку, в которую вы хотите отправить изменения, если вы не собираетесь отправлять изменения в основную ветку.

• git checkout создает ветки и помогает вам перемещаться между ними. Например, следующая базовая команда создает новую ветку и автоматически переключает вас на нее:

 команда git checkout -b <название ветки> 

• Чтобы переключиться с одной ветки на другую, просто используйте:

 git checkout <название ветки> 

• git remote позволяет просматривать все удаленные репозитории . Следующая команда выведет список всех подключений вместе с их URL-адресами:

 git remote –v 

• Чтобы подключить локальный репозиторий к удаленному серверу, используйте следующую команду:

 git remote add origin  

• Между тем, следующая команда удалит подключение к указанному удаленному репозиторию:

 git remote rm <имя-репозитория> 

• git branch перечислит, создаст или удалит ветки. Например, если вы хотите вывести список всех веток, присутствующих в репозитории, команда должна выглядеть так:

 git branch 

• Если вы хотите удалить ветку, используйте:

 git branch –d  

• git pull объединяет все изменения, присутствующие в удаленном репозитории, с локальным рабочим каталогом.

 git pull 

• git merge используется для слияния ветки с активной.

 git merge  

• git diff перечисляет конфликты. Чтобы просмотреть конфликты с базовым файлом, используйте

 git diff --base  

• Следующая базовая команда используется для просмотра конфликтов между ветвями перед их слиянием:

 git diff <исходная-ветвь> <целевая-ветвь> 

• Чтобы перечислить все существующие конфликты, используйте:

 git diff 

• git tag помечает определенные коммиты. Разработчики обычно используют его для отметки таких точек выпуска, как v1.0 и v2.0.

 git tag  

• git log используется для просмотра истории репозитория путем перечисления определенных деталей фиксации. Выполнение команды даст вам вывод, который выглядит следующим образом:

 совершить 15f4b6c44b3c8344caasdac9e4be13246e21sadw
Автор: Алекс Хантер  com>
Дата:  Пн, 1 октября, 12:56:29 2016 -0600 

• Команда git reset сбросит индекс и рабочий каталог до состояния последней фиксации git.

 git reset --hard HEAD 

• git rm можно использовать для удаления файлов из индекса и рабочего каталога.

 git rm filename.txt 

• git stash 9Команда 0341 временно сохранит изменения, которые не готовы к фиксации. Таким образом, вы сможете вернуться к этому проекту позже.

 git stash 

• git show  – это команда, используемая для просмотра информации о любом объекте git.

 git show 

• git fetch позволяет пользователям извлекать из удаленного репозитория все объекты, которые в данный момент не находятся в локальном рабочем каталоге.

 git fetch источник 

• git ls-tree позволяет просматривать объект дерева вместе с именем, режимом каждого элемента и значением SHA-1 большого двоичного объекта. Допустим, вы хотите увидеть HEAD, используйте:

 git ls-tree HEAD 

• git cat-file используется для просмотра информации о типе и размере объекта репозитория. Используйте параметр -p вместе со значением SHA-1 объекта для просмотра информации о конкретном объекте, например:

 git cat-file –p d670460b4b4aece5915caf5c68d12f560a9fe3e4 

• git grep позволяет пользователям выполнять поиск определенных фраз и слов в зафиксированных деревьях, рабочем каталоге и промежуточной области. Для поиска www.hostinger.com во всех файлах используйте:

 git grep "www.hostinger.com" 

• gitk показывает графический интерфейс локального репозитория. Просто запустите:

 gitk 

• git instaweb позволяет просматривать локальный репозиторий в интерфейсе git-web. Например:

 git instaweb –httpd=webrick 

• git gc очистит ненужные файлы и оптимизирует локальный репозиторий.

 git gc 

• git archive позволяет пользователям создавать zip- или tar-файл, содержащий компоненты одного дерева репозитория. Например:

 git archive --format=tar master 

• git prune удаляет объекты, не имеющие входящих указателей.

 git prune 

• git fsck выполняет проверку целостности файловой системы git и идентифицирует любые поврежденные объекты.

 git fsck 

• git rebase используется для применения определенных изменений из одной ветки в другую. Например:

 git rebase master 

Памятка по основным командам GIT в формате .pdf

Если вы только начинаете работать с GIT, вам может быть трудно запомнить даже основные команды. По этой причине мы составили шпаргалку GIT, чтобы помочь вам освоить программное обеспечение. Сохраните файл на своих устройствах или распечатайте его, чтобы он всегда был у вас под рукой, когда вы застряли, вспоминая команды GIT.

Скачать (размер: 1,2 МБ)

Заключение

Изучение основных команд GIT будет иметь большое значение для разработчиков, поскольку они могут легко управлять исходным кодом проектов. Чтобы запомнить их все, может потребоваться некоторое время, но, надеюсь, наша шпаргалка GIT будет вам полезна.

Практика этих команд и максимально использовать ваши навыки! Удачи!

Часто задаваемые вопросы по основным командам GIT

Какие команды GIT используются чаще всего?

Хотя существуют сотни различных команд Git, некоторые из них используются чаще всего, в том числе:

— git config
— git clone
— git init
— git status
— git push
— git add
— git commit
— ветка git

Как начать работу с GIT?

Начните с создания учетной записи GitHub и установки Git на свой компьютер. Создайте локальный репозиторий на Git и новый репозиторий на Github. Добавляйте файлы в свой репозиторий, удаляйте эти файлы из Git, создавайте коммиты и новые ветки.

Домантас возглавляет группы по контенту и SEO, предлагая свежие идеи и нестандартные подходы. Обладая обширными знаниями в области SEO и маркетинга, он стремится распространить информацию о Hostinger во всех уголках мира. В свободное время Домантас любит оттачивать навыки веб-разработки и путешествовать по экзотическим местам.

Еще от Домантаса Г.

Шпаргалка Git для начинающих. Гит | Шпаргалка | Новичок |… | от Shanika Ediriweera

Git | Шпаргалка | Новичок | Программист

Сегодня для любого программиста контроль версий становится важным инструментом.

Системы контроля версий — это категория программных инструментов, которые помогают команде разработчиков программного обеспечения управлять изменениями в исходном коде с течением времени. Если допущена ошибка, разработчики могут повернуть время вспять и сравнить более ранние версии кода, чтобы исправить ошибку и свести к минимуму неудобства для всех членов команды.

На сегодняшний день наиболее широко используемой системой контроля версий является Git . Git — это распределенная система контроля версий. Это означает, что вместо того, чтобы иметь только одно место для полной истории версий (централизованное хранилище) программного обеспечения, рабочая копия каждого разработчика также содержит полную историю всех изменений. Git был разработан с учетом производительности, безопасности и гибкости. Таким образом, самый популярный и самый используемый.

Хватит вступления.

Ниже приведены команды git, которые будут наиболее полезны для всех разработчиков.

Для начинающих используйте это как шпаргалку, пока ваш мозг не запомнит их автоматически!!! 😉

Глобальная настройка имени пользователя и электронной почты Git. Эти данные будут связаны с вашими фиксациями. Используйте без флага --global , чтобы установить имя пользователя и адрес электронной почты Git для текущего репозитория.

 $ git config --global user.name "JohnDoe" 
 $ git config --global user. email "[email protected]" 

Инициализировать репозиторий Git существующим проектом. Внутри папки проекта:

 $ git init 

 $ git status 

 $ git help <команда git> 

 $ git clone  

 $ git remote -v // перечислить все удаленные устройства 
 $ git remote add origin  // добавить происхождение 
 $ git remote rename   // переименовать удаленный 

 $ git remote add upstream https://github.com/  ORIGINAL_REPOSITORY  .git 
 $ git remote show upstream //детали 

 $ git fetch upstream 
 $ git checkout master 
 $ git merge upstream/master 

 $ git branch //список веток 
 $ git branch -a //список всех удаленных веток 
 $ git branch  //создать новую ветку 
 $ git branch -d  //удалить ветку 
 $ git branch -D <ветка> //принудительно удалить ветку 
 $ git branch -m  //переименовать$ git checkout <ветка> //изменить текущую ветку 
 $ git checkout -b  //создать и изменить ветку 

 $ git branch -u origin/  

 $ git push origin --delete remote-branch-name 
 
 
 Основной рабочий процесс Git   
 $ git доп.  //подготовить все файлы с изменениями после работы 
 ИЛИ 
 $ git add $ git commit //открывает интерактивную оболочку для сообщения о фиксации типа 
 ИЛИ 
 $ git commit -m "ВАШЕ СООБЩЕНИЕ О СООБЩЕНИИ"$ git pull // вытягивать из удаленной ветки, отслеживаемой текущей локальной веткой 
 ИЛИ 
 $ git pull origin  //ВЕТВЬ — master, dev, feature-x...$ git push //если уже отслеживается удаленная ветка 
  Отправить в удаленная ветка.  (создайте удаленную ветку, если она не существует)
 $ git push -u origin  
  Изменить фиксацию.  Добавьте больше изменений в последнюю фиксацию. Изменить сообщение коммита.
 $ git commit --amend 
 $ git commit --amend -m «сообщение» 
  Проверить изменения с момента последней фиксации. 
 $ git diff 
 $ git diff --staged //отличие от подготовленных (git add) файлов 
 Для более сложного использования, такого как сравнение 2 файлов, сравнение 2 коммитов, сравнение 2 веток, посетите https://www. atlassian.com/git/tutorials/saving-changes/git-diff
  Журнал Git. (  Проверить историю коммитов)
 $ git log 
 $ git log -n  //limit 
 $ git log --oneline // Condense 
 $ git log --stat // статистика 
 $ git log --author ="" //коммиты от конкретного автора 
 $ git log  //коммиты включают файл$ git log --graph --decorate --oneline 
  Авторство  (проверьте все подробные изменения в файле )
 $ git виноват <ФАЙЛ> 
 $ git виноват <ФАЙЛ> --date short 
  Удалить 
 $ git rm  //удалить файл 
 $ git rm '*.txt' //удалить все файлы с расширением .txt 
  Сделать файл неотслеживаемым.  Удалить файл из индекса git. Но сохраните файл:
 $ git rm — cached  // сделать файл неотслеживаемым 
 Или вы можете использовать файл  .gitignore .
  Силовая тяга.  (Получить версию на удаленке)
 $ git fetch --all 
 $ git reset --hard origin/ 
 $ git оформить заказ -- .  
  Принудительное нажатие.  (Принудительно перезаписать удаленную ветку локальной историей коммитов)
 $ git push origin  --force 
 Отменить 
  Сброс рабочей области.  (Unstage)
 $ git reset  
  Удалить все изменения с момента последней фиксации файла. 
 $ git checkout --  
 $ git reset HEAD  
  Переместить для фиксации перед HEAD, файлы фиксации добавлены на сцену. 9

 $ git reset --hard HEAD 

 $ git stash //сохранение неустановленных изменений 
 $ git stash save "добавить стиль на наш сайт" //сохранение с сообщением//вытащить из удаленного и объединить $ git stash show //показать схрон 
 $ git stash show -p //показать разницу тайника 
 $ git stash list$ git stash pop 
 ИЛИ 
 $ git stash pop stash@{0} //stash@{0} - номер тайника$ git stash apply 

 $ git stash branch  stash@{1} //тайник@{1} - номер тайника.  

 $ git stash drop stash@{1} 
 $ git stash clear //очистить все тайники 

 $ git tag // список тегов 
 $ git checkout  // проверка кода по тегу (версия) 
 $ git tag -a v0.0.3 -m "версия 0.0.3" //создать новый тег v0.0.3 
 $ git push --tags 

 $ git fetch 
 $ git rebase //добавляет локальные коммиты поверх исходных коммитов, без слияния коммитов 
 $ git rebase -i //перебазировать интерактивную сессию 

 $ git rebase --continue //исправить конфликт и продолжить 
 $ git rebase — пропустить //пропустить конфликт 
 $ git rebase -- abort //прервать перебазирование 

 $ git checkout  
 $ git rebase master //перебазировать основную ветку в "some_branch" 
 $ git checkout master 
 $ git merge  

 $ git rebase --onto    

 $ git rm -r --cached . && git добавить . && git commit -m "fixing .gitignore"// Вы можете запускать вышеуказанные команды одну за другой с большим контролем/четкостью 
 $ git rm -r --cached . 
 $ git добавить . 
 $ git commit -m "fixing .gitignore"