Websites for you and your projects

Install Git on Linux

Fun fact: Git was originally developed to version the Linux operating system! So, it only makes sense that it is easy to configure to run on Linux.

You can install on Linux through the package management tool that comes with your distribution.

Debian/Ubuntu

1. Git packages are available using .
2. It’s a good idea to make sure you’re running the latest version. To do so, Navigate to your command prompt shell and run the following command to make sure everything is up-to-date: .
3. To install Git, run the following command: .
4. Once the command output has completed, you can verify the installation by typing: .

Fedora

1. Git packages are available using .
2. To install Git, navigate to your command prompt shell and run the following command: .
3. Once the command output has completed, you can verify the installation by typing: .

Note: You can download the proper Git versions and read more about how to install on specific Linux systems, like installing Git on Ubuntu or Fedora, in git-scm’s documentation.

Step 5. Merge your Pull Request

In this final step, it’s time to bring your changes together – merging your branch into the branch.

1. Click the green Merge pull request button to merge the changes into .
2. Click Confirm merge.
3. Go ahead and delete the branch, since its changes have been incorporated, with the Delete branch button in the purple box.

Celebrate!

By completing this tutorial, you’ve learned to create a project and make a pull request on GitHub!

Here’s what you accomplished in this tutorial:

• Created an open source repository
• Started and managed a new branch
• Changed a file and committed those changes to GitHub
• Opened and merged a Pull Request

Take a look at your GitHub profile and you’ll see your new contribution squares!

To learn more about the power of Pull Requests, we recommend reading the GitHub flow Guide. You might also visit GitHub Explore and get involved in an Open Source project.

Last updated July 24, 2020

Contributing guidelines

We’d love for you to help us improve this project. To help us keep this collection
high quality, we request that contributions adhere to the following guidelines.

• Provide a link to the application or project’s homepage. Unless it’s
  extremely popular, there’s a chance the maintainers don’t know about or use
  the language, framework, editor, app, or project your change applies to.

• Provide links to documentation supporting the change you’re making.
  Current, canonical documentation mentioning the files being ignored is best.
  If documentation isn’t available to support your change, do the best you can
  to explain what the files being ignored are for.

• Explain why you’re making a change. Even if it seems self-evident, please
  take a sentence or two to tell us why your change or addition should happen.
  It’s especially helpful to articulate why this change applies to everyone
  who works with the applicable technology, rather than just you or your team.

• Please consider the scope of your change. If your change is specific to a
  certain language or framework, then make sure the change is made to the
  template for that language or framework, rather than to the template for an
  editor, tool, or operating system.

• Please only modify one template per pull request. This helps keep pull
  requests and feedback focused on a specific project or technology.

In general, the more you can do to help us understand the change you’re making,
the more likely we’ll be to accept your contribution quickly.

What can GHunt find ?

• Owner’s name
• Gaia ID
• Last time the profile was edited
• Profile picture (+ detect custom picture)
• If the account is a Hangouts Bot
• Activated Google services (YouTube, Photos, Maps, News360, Hangouts, etc.)
• Possible YouTube channel
• Possible other usernames
• Google Maps reviews (M)
• Possible physical location (M)
• Events from Google Calendar (C)
• Public photos (P)
• Phones models (P)
• Phones firmwares (P)
• Installed softwares (P)

️Document module:

• Owner’s name
• Owner’s Gaia ID
• Owner’s profile picture (+ detect custom picture)
• Creation date
• Last time the document was edited
• Public permissions
• Your permissions

️Youtube module:

• Owner’s Gaia ID (through Wayback Machine)
• Detect if the email is visible
• Country
• Description
• Total views
• Joined date
• Primary links (social networks)
• All infos accessible by the Gaia module

️Gaia module:

• Owner’s name
• Profile picture (+ detect custom picture)
• Possible YouTube channel
• Possible other usernames
• Google Maps reviews (M)
• Possible physical location (M)

The features marked with a (P) require the target account to have the default setting of on the Google AlbumArchive, or if the target has ever used Picasa linked to their Google account.
More info .

Those marked with a (M) require the Google Maps reviews of the target to be public (they are by default).

Those marked with a (C) requires user to have Google Calendar set on public (default it is closed)

Core

Core framework modules used by the generator and the server

1. Utilities (): miscellaneous utility functions that are used by many modules
2. Security (): Diffie-Hellman IKE & 3 encryption modes (AES-256-OCB, AES-256-CBC, XOR-128)
3. Loaders (): remotely import any package/module/scripts from the server
4. Payloads (): reverse TCP shell designed to remotely import dependencies, packages & modules
5. Stagers (): generate unique payload stagers to prevent analysis & detection
6. Generators (): functions which all dynamically generate code for the client generator
7. DAO (): handles interaction between command & control server and the SQLite database
8. Handler (): HTTP POST request handler for remote file uploads to the server

To Do

Contributors welcome! Feel free to issue pull-requests with any new features or improvements you have come up with!

1. Remote Import Encryption — encryption for data streams of packages/modules being remotely imported (to maintain confidentiality/authenticity/integrity and prevent any remote code execution vulnerabilities arising from deserialization)
2. Transport Types — add support for more transport types (HTTP/S, DNS, etc.)
3. Bug Fixes — fix any bugs/issues

Part 4: Publishing your repository to GitHub

When you create a new repository, it only exists on your computer and you are the only one who can access the repository. You can publish your repository to GitHub to keep it synchronized across multiple computers and allow other people to access it. To publish your repository, push your local changes to GitHub.

1. Click Publish repository in the menu bar.

   • GitHub Desktop automatically fills the «Name» and «Description» fields with the information you entered when you created the repository.
   • Keep this code private lets you control who can view your project. If you leave this option unselected, other users on GitHub will be able to view your code. If you select this option, your code will not be publicly available.
   • The Organization drop-down menu, if present, lets you publish your repository to a specific organization that you belong to on GitHub.

2. Click the Publish Repository button.

3. You can access the repository on GitHub.com from within GitHub Desktop. In the file menu, click Repository, then click View on GitHub. This will take you directly to the repository in your default browser.

Step 1. Create a Repository

A repository is usually used to organize a single project. Repositories can contain folders and files, images, videos, spreadsheets, and data sets – anything your project needs. We recommend including a README, or a file with information about your project. GitHub makes it easy to add one at the same time you create your new repository. It also offers other common options such as a license file.

Your repository can be a place where you store ideas, resources, or even share and discuss things with others.

To create a new repository

1. In the upper right corner, next to your avatar or identicon, click and then select New repository.
2. Name your repository .
3. Write a short description.
4. Select Initialize this repository with a README.

Click Create repository.

Our Learning Paths

First Day on GitHub

Welcome to GitHub! We’re so glad you’re here. We know it can look overwhelming at first, so we’ve put together a few of our favorite courses for people logging in for the first time

1. What is GitHub?

2. Introduction to GitHub

3. Git Handbook

First Week on GitHub

After you’ve mastered the basics, learn some of the fun things you can do on GitHub. From GitHub Pages to building projects with your friends, this path will give you plenty of new ideas.

1. Discover GitHub Pages

2. GitHub Pages

3. Reviewing pull requests

DevOps with GitHub Actions

Learn how to do DevOps on GitHub with the power of GitHub Actions! This path will guide you through leveraging GitHub Actions to go from code to cloud.

1. GitHub Actions: Hello World

2. GitHub Actions: Continuous Integration

3. GitHub Actions: Publish to GitHub Packages

Step 3. Make and commit changes

Bravo! Now, you’re on the code view for your branch, which is a copy of . Let’s make some edits.

On GitHub, saved changes are called commits. Each commit has an associated commit message, which is a description explaining why a particular change was made. Commit messages capture the history of your changes, so other contributors can understand what you’ve done and why.

Make and commit changes

1. Click the file.
2. Click the pencil icon in the upper right corner of the file view to edit.
3. In the editor, write a bit about yourself.
4. Write a commit message that describes your changes.
5. Click Commit changes button.

These changes will be made to just the README file on your branch, so now this branch contains content that’s different from .

GitHub Actions

Create a GitHub Action and use it in a workflow.

GitHub Actions

Workflows

Hello World

GitHub Actions: Continuous Integration

Learn how to create workflows that enable you to use Continuous Integration (CI) for your projects.

GitHub Actions

Workflows

CI

Continuous Integration

Integration

GitHub Actions: Publish to GitHub Packages

This course will walk you through using GitHub Actions to get your code in a deployable state once your CI workflows have completed.

GitHub Actions

GitHub Packages

Deployment

Workflows

Docker

GitHub Actions: Continuous Delivery with Azure

Create two deployment workflows using GitHub Actions and Microsoft Azure.

GitHub Actions

Microsoft Azure

Workflows

CD

Deployment

GitHub Actions: Writing JavaScript Actions

Learn how to write your own GitHub JavaScript Action! This course will empower you to begin automating customized tasks unique to your workflow.

JavaScript

API

Actions toolkit

GitHub Secrets

Workflows

GitHub Actions: Write Docker container actions

Learn how to write your own GitHub Docker container action! This course will empower you to begin automating customized tasks unique to your workflow.

Docker

Containers

Workflows

Application programming interface (API)

Publishing GitHub Actions

GitHub Actions: Using GitHub Script

This course covers how to use GitHub Script to quickly use octokit/rest in a GitHub Actions workflow.

GitHub Actions

Octokit

Workflow

Automation

Application programming interface (API)

Miscellanea

1. If you configure the Software to work with one or more accounts on the GitHub.com website or with an instance of GitHub Enterprise, your use of the Software will also be governed by the GitHub.com website Terms of Service and/or the license agreement applicable to your instance of GitHub Enterprise.
2. The failure of GitHub to exercise or enforce any right or provision of this EULA shall not constitute a waiver of such right or provision.
3. This EULA constitutes the entire agreement between you and GitHub and governs your use of the Software, superseding any prior agreements between you and GitHub (including, but not limited to, any prior versions of the EULA).
4. You agree that this EULA and your use of the Software are governed under California law and any dispute related to the Software must be brought in a tribunal of competent jurisdiction located in or near San Francisco, California.
5. Please send any questions about this EULA to support@github.com.

Step 2. Create a Branch

Branching is the way to work on different versions of a repository at one time.

By default your repository has one branch named which is considered to be the definitive branch. We use branches to experiment and make edits before committing them to .

When you create a branch off the branch, you’re making a copy, or snapshot, of as it was at that point in time. If someone else made changes to the branch while you were working on your branch, you could pull in those updates.

This diagram shows:

• The branch
• A new branch called (because we’re doing ‘feature work’ on this branch)
• The journey that takes before it’s merged into

Have you ever saved different versions of a file? Something like:

Branches accomplish similar goals in GitHub repositories.

Here at GitHub, our developers, writers, and designers use branches for keeping bug fixes and feature work separate from our (production) branch. When a change is ready, they merge their branch into .

To create a new branch

1. Go to your new repository .
2. Click the drop down at the top of the file list that says branch: main.
3. Type a branch name, , into the new branch text box.
4. Select the blue Create branch box or hit “Enter” on your keyboard.

Now you have two branches, and . They look exactly the same, but not for long! Next we’ll add our changes to the new branch.

Miscellanea

1. No Waiver. The failure of GitHub to exercise or enforce any right
   or provision of these Application Terms shall not constitute a
   waiver of such right or provision.
2. Entire Agreement. These Application Terms, together with any
   applicable Privacy Notices, constitutes the entire agreement
   between you and GitHub and governs your use of the Software,
   superseding any prior agreements between you and GitHub
   (including, but not limited to, any prior versions of the
   Application Terms).
3. Governing Law. You agree that these Application Terms and your use
   of the Software are governed under California law and any dispute
   related to the Software must be brought in a tribunal of competent
   jurisdiction located in or near San Francisco, California.
4. Third-Party Packages. The Software supports third-party «Packages»
   which may modify, add, remove, or alter the functionality of the
   Software. These Packages are not covered by these Application
   Terms and may include their own license which governs your use of
   that particular package.
5. No Modifications; Complete Agreement. These Application Terms may
   only be modified by a written amendment signed by an authorized
   representative of GitHub, or by the posting by GitHub of a revised
   version. These Application Terms, together with any applicable
   Open Source Licenses and Notices and GitHub’s Privacy Statement,
   represent the complete and exclusive statement of the agreement
   between you and us. These Application Terms supersede any proposal
   or prior agreement oral or written, and any other communications
   between you and GitHub relating to the subject matter of these
   terms.
6. License to GitHub Policies. These Application Terms are licensed
   under the Creative Commons Attribution license.
   You may use it freely under the terms of the Creative Commons license.
7. Contact Us. Please send any questions about these Application
   Terms to support@github.com.

Part 3: Contributing to projects with GitHub Desktop

After installing, authenticating, and configuring the app, you are ready to start using GitHub Desktop. You can create, add, or clone repositories and use GitHub Desktop to manage contributions to your repositories.

Creating, adding, and cloning repositories

You can create a new repository by selecting the File menu and clicking New repository…. For more information, see «Creating your first repository using GitHub Desktop.»

You can add a repository from your local computer by selecting the File menu and clicking Add Local Repository…. For more information, see «Adding a repository from your local computer to GitHub Desktop.»

You can clone a repository from GitHub by selecting the File menu and clicking Clone Repository…. For more information, see «Cloning and Forking Repositories from GitHub Desktop.»

Making changes in a branch

You can use GitHub Desktop to create a branch of a project. Branches isolate your development work from other branches in the repository, so that you can safely experiment with changes. For more information, see «Managing branches.»

After you make changes to a branch, you can review them in GitHub Desktop and make a commit to keep track of your changes. For more information, see «Committing and reviewing changes to your project.»

If you want to access your changes remotely or share them with other people, you can push your commits to GitHub. For more information, see «Pushing changes to GitHub.»

Collaborating with GitHub Desktop

You can use GitHub Desktop to create issues or pull requests to collaborate on projects with other people. Issues help you keep track of ideas and discuss possible changes to projects. Pull requests let you share your proposed changes with others, receive feedback, and merge changes into a project. For more information, see «Creating an issue or pull request.»»

You can view your own or your collaborator’s pull requests in GitHub Desktop. Viewing a pull request in GitHub Desktop lets you see any proposed changes and make additional changes by opening the project’s files and repositories in your default text editor. For more information, see «Viewing a pull request in GitHub Desktop.»

Keeping your local repository in sync

When you make changes to your local repositories or when other people make changes to the remote repositories, you will need to sync your local copy of the project with the remote repository. GitHub Desktop can keep your local copy of a project in sync with the remote version by pushing and pulling commits. For more information, see «Syncing your branch.»

Основные термины Git

Репозиторий (Repository)  — каталог файловой системы, в котором хранятся файлы разработки.

Удаленный репозиторий (Ориджин, Origin) — репозиторий, находящийся на сервере. Это общий репозиторий, в который приходят все изменения.

Локальный репозиторий — репозиторий, расположенный на локальном компьютере разработчика. Именно с ним работает программист.

Клон (Clone) — копия Origin в локальный репозиторий.

Форк (Fork) — копия репозитория. Форк позволяет разработчику вносить изменения без риска испортить исходный код.

Коммит (Commit) — запись изменений в локальный репозиторий.

Пуш (Push) — отправка всех неотправленных коммитов в удаленный репозиторий.

Пул (Pull) — получение последних изменений с удаленного репозитория.

Пулреквест (Pull Request) — запрос на слияние форка репозитория с основным репозиторием. Пулреквест может быть принят или отклонен владельцем репозитория.

Создание ветки

Теперь создадим ветку, внесем изменения и посмотрим как влияют изменения на ветку.

В GitHub Desktop переходим в Branch > New Branch и создаем новую ветвь. Назовем ее «development» и нажмем Create Branch.

Создание новой ветки

После создания ветки, в центре раскрывающееся меню будет указывать на ту ветку, в которой мы работаем. Создание ветки копирует существующий контент (из ветки master) в новую ветку (development).

Работа с ветками

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

Сохраним изменения.
Вернемся в GitHub Desktop и обратим внимание, что на вкладке «Changes» у нас появились новые измененные файлы.

Изменения в файле показывают удаленные строки красным и новые строки зеленым цветом. Цвета помогают увидеть, что изменилось.

Закоммитим изменения в левом нижнем углу и кликнем на Commit to development.
Нажимаем Publish branch (в верхней части окна GitHub Desktop), чтобы сделать локальную ветку также доступной в Origin (GitHub). (Всегда существует две версии ветки: локальная версия и удаленная версия.)
Вернемся в основную ветку (выбираем master в раскрывающемся меню). Затем посмотрим на свой файл (в текстовом редакторе)

Стоит обратить внимание, что изменения, внесенные нами во время редактирования в ветке , не отображаются в основной ветке.

Обычно новую ветку создают, когда вносят значительные изменения в контент. Например, нужно обновить раздел («Раздел X») в своих документах. Возможно, опубликовать другие обновления не нужно, прежде чем публиковать подробные изменения в Разделе X. Если работа была в той же ветке, было бы сложно выборочно загружать обновления для нескольких файлов за пределами Раздела X без отправки обновлений, которые сделали к файлам в разделе Х.

Посредством ветвления можно ограничить свои изменения конкретной версией, которая не запускается, пока не будут готовы изменения к объединению с master веткой.

Repositories

Right now, we’re in your first GitHub repository. A repository is like a folder or storage space for your project. Your project’s repository contains all its files such as code, documentation, images, and more. It also tracks every change that you—or your collaborators—make to each file, so you can always go back to previous versions of your project if you make any mistakes.

This repository contains three important files: The HTML code for your first website on GitHub, the CSS stylesheet that decorates your website with colors and fonts, and the README file. It also contains an image folder, with one image file.

Our most popular courses

Introduction to GitHub

If you are looking for a quick and fun introduction to GitHub, you’ve found it. This class will get you started using GitHub in less than an hour.

Git

GitHub Pages

Branches

Commits

Pull Requests

Create a GitHub Action and use it in a workflow.

GitHub Actions

Workflows

Hello World

Communicating using Markdown

This course will walk you through everything you need to start organizing ideas and collaborating using Markdown, a lightweight language for text formatting.

GitHub

Markdown

Learning should be fun

There are no simulations or boring tutorials here, just hands-on lessons created with by the GitHub community and taught by the friendly Learning Lab bot.

📰 Latest news

• 02/10/2020 : Since a few days ago, Google returns a 404 when we try to access someone’s Google Photos public albums, we can only access it if we have a link to one of their albums.
  Either this is a bug and this will be fixed, either it’s a protection that we need to find how to bypass.
• 03/10/2020 : Successfully bypassed. (commit 01dc016)
  It requires the «Profile photos» album to be public (it is by default)
• 20/10/2020 : Google WebArchive now returns a 404 even when coming from the «Profile photos» album, so the photos scraping is temporary (or permanently) disabled. (commit e762543)
• 25/11/2020 : Google now removes the name from the Google Maps profile if the user has 0 reviews (or contributions, even private). I did not find a bypass for the moment, so all the help in the research of a bypass is appreciated.
• 20/03/2021 : Successfully bypassed. (commit b3b01bc)

GitHub’s Logos

The license grant included with the Software is not for GitHub’s
trademarks, which include the Software logo designs. GitHub reserves
all trademark and copyright rights in and to all GitHub trademarks.
GitHub’s logos include, for instance, the stylized designs that
include «logo» in the file title in the «logos» folder.

The names GitHub, GitHub Desktop, GitHub for Mac, GitHub for
Windows, Atom, the Octocat, and related GitHub logos and/or stylized
names are trademarks of GitHub. You agree not to display or use
these trademarks in any manner without GitHub’s prior, written
permission, except as allowed by GitHub’s Logos and Usage Policy: https://github.com/logos.

Part 3: Exploring GitHub Desktop

In the file menu at the top of the screen, you can access settings and actions that you can perform in GitHub Desktop. Most actions also have keyboard shortcuts to help you work more efficiently. For a full list of keyboard shortcuts, see «Keyboard shortcuts.»

The GitHub Desktop menu bar

At the top of the GitHub Desktop app, you will see a bar that shows the current state of your repository.

• Current repository shows the name of the repository you’re working on. You can click Current repository to switch to a different repository in GitHub Desktop.

• Current branch shows the name of the branch you’re working on. You can click Current branch to view all the branches in your repository, switch to a different branch, or create a new branch. Once you create pull requests in your repository, you can also view these by clicking on Current branch.

• Publish repository appears because you haven’t published your repository to GitHub yet, which you’ll do later in the next step. This section of the bar will change based on the status of your current branch and repository. Different context dependent actions will be available that let you exchange data between your local and remote repositories.

Changes and History

In the left sidebar, you’ll find the Changes and History views.

• The Changes view shows changes you’ve made to files in your current branch but haven’t committed to your local repository. At the bottom, there is a box with «Summary» and «Description» text boxes and a Commit to BRANCH button. This is where you’ll commit new changes. The Commit to BRANCH button is dynamic and will display which branch you’re committing your changes to.

• The History view shows the previous commits on the current branch of your repository. You should see an «Initial commit» that was created by GitHub Desktop when you created your repository. To the right of the commit, depending on the options you selected while creating your repository, you may see .gitattributes, .gitignore, LICENSE, or README files. You can click each file to see a diff for that file, which is the changes made to the file in that commit. The diff only shows the parts of the file that have changed, not the entire contents of the file.

Modules

Post-exploitation modules that are remotely importable by clients

1. Persistence (): establish persistence on the host machine using 5 different methods
2. Packet Sniffer (): run a packet sniffer on the host network & upload .pcap file
3. Escalate Privileges (): attempt UAC bypass to gain unauthorized administrator privileges
4. Port Scanner (): scan the local network for other online devices & open ports
5. Keylogger (): logs the user’s keystrokes & the window name entered
6. Screenshot (): take a screenshot of current user’s desktop
7. Webcam (): view a live stream or capture image/video from the webcam
8. Outlook (): read/search/upload emails from the local Outlook client
9. Process Control (): list/search/kill/monitor currently running processes on the host
10. iCloud (): check for logged in iCloud account on macOS
11. Miner (): mine Monero in the background using the built-in miner or XMRig

Регистрация на GitHub

На главной странице заполняем форму справа и нажимаем “Sign up for GitHub”

Проходим проверку и нажимаем “Join a free plan”

На следующей странице можно заполнить небольшую анкету (можно не заполнять)

На этой же странице спускаемся в самый низ и нажимаем “Complete setup”

Проверяем свою почту. Если письмо пришло, переходим к следующему пункту.

Аккаунт GitHub успешно создан

Установка GitHub Desktop

Нажимаем “Download for Windows (64bit)” (операционная система может отличаться)

Запускаем скачанный файл. После установки в появившемся окне нажимаем “Sign in to GitHub.com”

В открывшемся окне браузера вводим в форму свои данные, как при регистрации, и нажимаем “Sign in”

Если браузер запросит, то подтвердить, что нужно “Открыть приложение GitHub Desktop”

Далее регистрационные данные перенесутся в форму конфигурации (настроек) Git — нажимаем “Continue”

Отключаем пункт “Yes, submit periodic usage stats”, если не хотите периодически передавать статистику работы GitHub Desktop и нажимаем “Finish”

Далее видим начальное окно GitHub Desktop

“Create a tutorial repository…“ — создать обучающий репозиторий

“Clone repository from the Internet…“ — клонировать (скопировать/скачать) репозиторий из GitHub к себе на компьютер

“Create a New Repository on your hard drive…“ — создать новый репозиторий на вашем жестком диске (на вашем компьютере) и добавить систему Git в проект

“Add an Existing Repository from your hard drive…“ — добавить на GitHub репозиторий, который уже есть на вашем компьютере и использует Git

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

Why do we need usage stats?

Our team uses metrics to prioritize our work and evaluate whether we are
successful in solving real users’ problems after we’ve released something. For example,
when we released dark theme and a new guided way to merge conflicts, we wanted to
understand first whether anyone was even using the new feature, and second whether it was
providing value for our users.

To give a concrete example, if we release a feature that aims to improve merge conflicts,
if the percentage of conflicts that are resolved successfully rises by 20%, that means our
release is successful in helping people resolve conflicts more easily. Conversely, if the
percentage of successfully resolved conflicts drops by 5%, we know it’s time to revisit
the feature and assess whether we should iterate or try a different solution. You can see an
example of how we think about metrics here.

The more people who opt in to send usage stats, the more information we have to base our
decision making on. And if you want us to take your use cases into consideration, we hope
you’ll opt in so we get a better idea of how you use the app and whether or not it’s meeting your
needs. GitHub Desktop will send a payload in the format below to our analytics system unless you’ve opted out.
We are very sensitive to the privacy of our users and we never look at the data of specific individuals,
but rather only examine aggregate data and trends to inform our product decisions.

You can change your opt-in setting at any time in
File | Options
File | Preferences.

Добавляем и изменяем файлы

Теперь давайте создадим в нашей папке новый текстовый документ с сообщением “Hello world!”.

Если мы откроем GitHub Desktop, мы увидим что наш файл увидела система и пометила как добавление новгго файла, отметив зеленым плюсом. Справа отобразив что именно сделали с файлом: зеленым выделены добавленные фрагменты.

Теперь мы готовы сделать свой первый коммит (commit). По факту это фраза означает внесения изменения в текущую ветку в локальном репозитории. Чтобы это сделать, нужно написать краткое сообщение, отражающее суть изменений, чтобы потом было проще в них ориентироваться. В данном случае мы добавили новый текстовый файл (сообщение может быть на любом языке, необязательно на английском). Github сам нам подсказал название коммита. Так же мы можем добавить описание изменений, чтобы другим пользователям было проще.

Когда мы готовы сделать коммит, нажимаем кнопку Commit to master. Это означает сделать коммит в локальную ветку master, про сами ветки расскажем чуть позже. Но мы сделали только коммит, теперь нужно чтобы изменились файлы в удаленном репозитории, то есть синхронизировать локальную и удалённую ветки master. Для этого нажимаем кнопку сверху Push origin.

Если все прошло успешно, и изменения запушились в удаленный репозиторий, то, обновив его страницу на GitHub, мы увидим новый файл hello world.txt.

Поверьте, адекватные описания коммитов — это очень важно!

Теперь давайте создадим файл на GitHub и скопируем его в локальный репозиторий. Нажимаем кнопку Create new file и называем его newfile.

Осталось “прописать” коммит и сделать его, нажав Commit new file:

Откроем GitHub Desktop и обнаружим, что система сама определила, что произошел внешний коммит и наши файлы нужно обновить. Если изменений не видно, нажмите F5 или перезапустите приложение. Нажмём на Pull origin и скачаем файлы в свой локальный репозиторий:

Заключение

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

Используемые в этом занятии команды в интерфейсе GitHub Desktop можно попробовать и в командной строке. Возможно, что командная строка понравится больше. Но GitHub Desktop может стать хорошей отправной точкой.