Меню Рубрики

Установка и настройка sourcetree

Git: советы новичкам – часть 3

Глава 16. Откуда взялась ветка?

Набираемся терпения и продолжаем рассматривать разные рабочие ситуации. Если мы сделаем несколько коммитов, а потом выполним команду fetch (скачаем свежие коммиты, но пока не применим их в рабочий каталог), то увидим немного сбивающую с толку картину:

Что это ещё за ветка получилась? Мы ведь не создавали никакой ветки. Может её создал кто-то из сотрудников? Нет, никто её не создавал. Восстановим хронологию событий:

  • Сначала мы скачали свежие коммиты. Тогда последним был коммит «2».
  • Затем мы сделали коммиты «3» и «4» (но пока не пушили их).
  • В это время другие сотрудники запушили в удалённый репозиторий коммиты «5», «6» и «7». Тогда мы ничего не знали об этом.
  • Наконец, мы сделали fetch и увидели то, что на картинке.

В Git каждый коммит хранит ссылку на предыдущий (это и позволяет нам соединять кружки на рисунках; каждый отрезок – это ссылка на предыдущий коммит). Когда мы сделали коммит «3», для нас последним коммитом был «2» поэтому они соединены. Но когда на origin кто-то запушил коммит «5», там последним был тоже коммит «2» – ведь мы свои коммиты «3» и «4» ещё не запушили, и на origin их не было. А раз так, то для коммита «5» предыдущим тоже выступает коммит «2», именно эту связь Git и запомнил.

Итого, разные люди независимо друг от друга поменяли результат коммита «2» – вот и возникла ветка. Кстати, эта ветка сейчас есть только в нашем локальном репозитории. В origin её пока нет, поскольку коммиты «3» и «4» мы до сих пор не запушили.

Что дальше? Поскольку мы сделали fetch, а не pull, то скачанные коммиты ещё не применились к нашему рабочему каталогу. Давайте применим их – для этого выполним merge. Результат представлен на картинке:

Произошедшее уже знакомо нам. Образовался автоматический merge-commit «8» – master и head теперь указывают на него. В рабочей копии появились изменения из коммитов «5», «6» и «7», которые объединились с нашими изменениями из коммитов «3» и «4». origin/master по-прежнему указывает на «7», поскольку последние наши операции проходили на локальном компьютере. А origin/master может сдвинуться только после общения нашего репозитория с origin.

Наконец, делаем push, и вот теперь origin/master тоже указывает на «8», ведь:

  • Наш merge-commit «8» отправлен в origin.
  • Там он стал последним, а значит удалённый указатель master теперь показывает на него.
  • Нам скачалась информация об удалённом указателе master и мы её видим как origin/master.

Вот он и показывает на «8». Логично.

Не поддавайтесь малодушному желанию пропустить эти объяснения. В них нет ничего сложного, нужна лишь внимательность. Обязательно пройдитесь по шагам до тех пор, пока не поймете, почему все так работает.

Глава 17. Почему push выдаёт ошибку?

Вы обязательно столкнетесь с тем, что Git выдаёт ошибку при команде push. В чём проблема? Почему он не принимает наши коммиты? Push успешно завершится, только если для каждого отправляемого в origin коммита Git сможет найти предшественника. Пример:

Здесь слева изображены коммиты в вашем локальном репозитории, а справа – коммиты в удалённом репозитории (origin).

Хронология этих коммитов следующая:

  • Сначала в origin были коммиты «1» и «2».
  • Мы сделали pull (в локальном репозитории тоже оказались лишь эти два коммита).
  • Потом мы закоммитили «3» и «4» в локальный репозиторий (но не пушили).
  • Кто-то запушил коммит «5» в origin.

И получилось то, что сейчас на картинке. Разобрались?

Теперь наша попытка запушить «3» и «4» в origin завершится ошибкой. Git откажется пристыковать наши коммиты к последнему коммиту «5» в origin, поскольку в local предшественником для коммита «3» является коммит «2» – а вовсе не «5», как в origin! Для Git важно, чтобы предшественник был тот же.

Проблема решается легко. Перед тем, как сделать push, мы сделаем pull (забираем коммит «5» себе). Тут вы можете спросить: «Секунду! А почему это забрать коммит «5» Git может, а послать коммиты «3» и «4» он не может? Вроде же ситуация симметричная в обе стороны». Правильный вопрос! А ответ на него простой. Если бы Git позволил отправить коммиты «3» и «4» в такой ситуации, то пришлось бы делать merge на стороне origin – а кто там будет разрешать конфликты? Некому. Поэтому Git заставляет вас сначала забрать свежие коммиты себе, сделать merge на своем компьютере (если будут конфликты, то разрешить их), а уже готовый результат он позволит вам отправить в origin командой push. При этом, никаких конфликтов в origin уже быть не может.

Давайте посмотрим, как будет выглядеть локальная история, после того, как вы заберете коммит «5» командой pull.

Здесь у «3» и «5» предок «2», как и на предыдущей картинке. А новый коммит «6» – это уже давно известный нам merge-commit.

В таком состоянии локальные коммиты уже можно запушить. Пусть тут и появилось разветвление истории, но обе ветки при мерже объединились. А значит голова у ветки снова одна. То есть, ничего не мешает сделать push. После этого в origin коммиты будут выглядеть такой же точно «петелькой».

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

Глава 18. Rebase

В предыдущей главе мы сделали несколько локальных коммитов, а потом командой pull забрали коммиты других сотрудников из удалённого репозитория. У нас в локальном репозитории образовалась как бы «ветка», которая потом обратно объединилась с основной. После push это временное раздвоение ветки попало в origin, откуда его скачают сотрудники и увидят в своей истории. Часто такие «петли» считаются нежелательными. Поскольку вместо красивой линейной истории получается куча петель, которые затрудняют просмотр.

Git предлагает альтернативу. Выше мы делали fetch+merge. Первая команда забирает свежие коммиты, вторая объединяет их с нашими незапушенными коммитами (если они есть) и создаёт merge-commit с результатом объединения.

Так вот, оказывается можно вместо fetch+merge делать fetch+rebase. Что за rebase и чем он отличается от merge? Вспомним ещё раз, как проходил merge в предыдущем примере:

Rebase действует по-другому – он отсоединяет вашу цепочку незапушенных коммитов от своего предка. Напомним, это были коммиты «3» и «4». Они отсоединяются от своего предка «2» и rebase ставит их «сверху» на только что скачанный коммит «5». То есть, «3» и «4» будут прицеплены сверху к «5» (а мерж-коммит «6» вообще не появится). Итог будет таким:

Читайте также:  Установка заббикс агента на freebsd

Никакой петли больше нет, история линейная и красивая! Да здравствует rebase! Теперь мы знаем, что при скачивании коммитов из origin лучше объединять их со своими локальными коммитами при помощи rebase, а не merge.

Хорошо, а если речь не о паре-тройке ваших коммитов, а о большой ветке с разработкой новой фичи. Когда настанет время влить эту фичу в главную ветку, как это лучше сделать – через rebase или merge? У обоих способов есть преимущества:

  • rebase позволит сохранить историю простой и линейной – он добавит цепочку ваших коммитов из ветки в конец основной ветки.
  • merge сделает петлю, но зато в истории более наглядно будет прослеживаться история разработки вашей фичи.

Вопрос предпочтения rebase или merge в таких случаях обсудите с ведущим программистом вашего проекта.

Глава 19. Эпилог

Мы с вами разобрались в множестве команд Git для работы с репозиториями:

  • pull
  • commit
  • push
  • add
  • clone
  • checkout
  • stash
  • merge
  • rebase
  • abort
  • fetch

Это не все команды, которые бывают нужны в работе – только самые частые. Будьте готовы, что потребуется освоить и другие. Работать с Git можно при помощи разных git-клиентов. Мы в основном используем эти три:

  • Консольный
  • SourceTree
  • TortoiseGit

Выбор клиента – дело вкуса.

Консольный – работает на всех платформах, но у него крайне аскетичный интерфейс. Если вы не привыкли работать в консоли, то скорее всего вам будет в нем некомфортно.

SourceTree — графический клиент с довольно простым интерфейсом. Есть версии для наших основных платформ: Win и Mac. Однако, сотрудники часто жалуются на его медленную работу и глюки.

TortoiseGit — еще один графический клиент. Есть версия для Win, для Mac`а нет. Интерфейс несколько непривычный, но многим нравится. Жалоб на глюки и тормоза существенно меньше, чем в случае с SourceTree.

Интересно, что и SourceTree, и TortoiseGit не работают с репозиторием Git напрямую. Внутри себя они используют консольный Git. Когда вы нажимаете на красивые кнопки, вызываются консольные команды Git с разными хитрыми параметрами, а результат вызова снова показывают в красивом виде. Использование всеми клиентами консольного Git означает, что все они работают со стандартной файловой структурой Git-хранилища на вашем жёстком диске. А значит можно использовать смешанный стиль работы: одни операции выполнять в одном клиенте, а другие – в другом.

Итак, вы узнали основные концепции, используемые системой контроля версий Git. А также, как работают основные команды. Наверняка при чтении статьи вам не хватало описания «какие кнопки нажимать». Однако, в каждом Git-клиенте это выглядит по-разному, поэтому нам пришлось отделить описание логики от описания интерфейса. Настало время выбрать один из клиентов и изучить его интерфейс пользователя.

источник

Next up: Learn Sourcetree with Bitbucket

Step 1: Create a Git repository

As our new Bitbucket space station administrator, you need to be organized. When you make files for your space station, you’ll want to keep them in one place and shareable with teammates, no matter where they are in the universe. With Bitbucket, that means adding everything to a repository. Let’s create one!

Step 1: Create the repository

Initially, the repository you create in Bitbucket is going to be empty without any code in it. That’s okay because you will start adding some files to it soon. This Bitbucket repository will be the central repository for your files, which means that others can access that repository if you give them permission. You will also copy a version of that repository to your local system—that way you can update it from one repo, then transfer those changes to the other.

Do the following to create your repository:

    From Bitbucket, click the + icon in the global sidebar and select Repository. Bitbucket displays the Create a new repository page. Take some time to review the dialog’s contents. With the exception of the Repository type, everything you enter on this page you can later change.

Enter BitbucketStationSupplies for the Name field. Bitbucket uses this Name in the URL of the repository. For example, if the user the_best has a repository called awesome_repo , the URL for that repository would be https://bitbucket.org/the_best/awesome_repo .

Keep the rest of the options as is unless you want to change them:

Access level —Leave the This is a private repository box checked. A private repository is only visible to you and those with access. If this box is unchecked, anyone can see your repository.

Include a README? —If you recently created your account, this defaults to a tutorial README. For the purposes of this tutorial, pick either of the Yes options, that way you’ll start out with a file.

From Version control system, you can choose either Git or Mercurial. If you aren’t sure which one to go with, keep Git as your option.

Click Create repository. Bitbucket creates your repository and displays its Source page.

Step 2: Explore your new repository

Take some time to explore the repository you have just created. To view the shortcuts available, press the ? key on your keyboard.

Click + from the global sidebar for common actions for a repository. Scan through the links in the navigation sidebar to see what’s behind each one, including the repository Settings where you’ll update repository details and other settings. Click the Commits in the sidebar. If you included a README, you’ll see one commit on that page.

Your repository is private and you have not invited anyone to the repository, so the only person who can create or edit the repository’s content right now is you, the repository owner.

Step 2: Copy your repository and add files

Now that you have a place to add and share your space station files, you need a way to get to it from your local system. To set that up, you want to copy the Bitbucket repository to your system. Sourcetree refers to copying a repository as «cloning» it. When you clone a repository, you create a connection between the Bitbucket server and your local system.

Читайте также:  Установка автосигнализации в новополоцке

Step 1: Clone your repository to your local system

Use Sourcetree to clone your repository to your local system without using the command line.

    As you use Bitbucket more, you will probably work in multiple repositories. For that reason, it’s a good idea to create a directory to contain all those repositories. So start by creating a directory on your local system and call it repos.

From Bitbucket, go to your BitbucketStationSupplies repository.

Click the Clone button in the top right corner. Bitbucket displays the Clone this repository dialog.

From the Clone this repository dialog, click Clone in Sourcetree.

From the Clone New dialog box, update the Destination Path to /repos/bitbucketstationsupplies . This destination path refers to the directory you just created with the folder for the repository. The Name field remains the same with the folder name of the repository.

Click the Clone button.

Congratulations! You’ve cloned your repository to your local system.

Step 2: Create a file, add it locally, and push it to Bitbucket

With the repository on your local system, you can start making a list of all the supplies you need for your space station. To do so, let’s create a file for your supplies.

As you work on this section, the images may look slightly different, depending on whether you are working with a Git or Mercurial repository.

Double-click the bitbucketstationsupplies repository in Sourcetree and notice that there is nothing to commit from your local repository to the remote repository.

Use a text editor to add the following three lines:
space ice
cream nerf
darts telescope light shield

Save the file as supplies.txt to the bitbucketstationsupplies directory on your local system. The supplies.txt file now appears in Sourcetree since you created it in your local repository.

Now is the point where you prepare a snapshot of the changes before committing them to the official history. From the options menu of the supplies.txt file, select Stage file (for a Git repository) or Add file (for a Mercurial repository).

Click the Commit button at the top to commit the file.

In the message box, enter «Initial commit.»

Click the Commit button under the box. Your new file is now committed to the project history.

Up until this point, everything you have done is on your local system and is invisible to your Bitbucket repository until you push those changes to your remote Bitbucket repository.

From Sourcetree, click the Push button to push your committed changes. Pushing lets you move one or more commits to another repository, which serves as a convenient way to publish contributions.

From the dialog box that appears, your next step depends on whether you are using Git or Mercurial:

Git–Under the Push? column, select the master branch to indicate that you are pushing that branch to origin and click OK.

Mercurial–Everything is automatic, so all you have to do is click OK.

Go to your BitbucketStationSupplies repository in Bitbucket.

If you click Commits in the sidebar, you’ll see your commit in the repository. Bitbucket combines all the things you just did into that commit and shows it to you.

If you click Source in the sidebar, you’ll see your file in the repository, the supplies.txt file you just added.

Step 3: Pull changes from your repository

Next on your list of space station administrator activities, you need to file out a request for new supplies. Let’s set up a system for getting supplies to our Bitbucket space station. With just a bit more knowledge of Bitbucket and Sourcetree, we’ll be supporting our space exploration for years to come!

Step 1: Create a file in Bitbucket

To add your supply request file, do the following:

From your BitbucketStationSupplies in Bitbucket, click Source to open the source directory. Notice you only have one file, supplies.txt , in your directory.

A. Source page: Click the link to open this page.

B. Branch selection: Pick the branch you want to view.

C. More options button: Click to open a menu with more options, such as ‘Add file’.

D. Source file area: View the directory of files in Bitbucket.

From the Source page, click the More options button in the top right corner and select Add file from the menu. The More options button only appears after you have added at least one file to the repository. A page for creating the new file opens, as shown in the following image.

A. Branch with new file: Change if you want to add file to a different branch.

B. New file area: Add content for your new file here.

Enter supplyrequest in the filename field.

Select HTML from the Syntax mode list.

Add the following HTML code to the text area:

We are requesting additional supplies. Please send us the following:

Click Commit. The Commit message field appears with the message: supplyrequest created online with Bitbucket.

Click Commit under the message field.

You now have a new file in Bitbucket! You are taken to a page with details of the commit, where you can see the change you just made:

If you want to see a list of the commits you’ve made so far, click Commits in the sidebar.

Step 2: Pull changes from a remote repository

Now we need to get that supply request form onto your local system. The process is pretty straight forward, basically just the reverse of the push you used to get the supplies.txt file into Bitbucket.

Читайте также:  Установка кольца во время беременности

To pull the file into your local repository, do the following:

Open your repository in Sourcetree, and click the Pull button.

A popup appears to indicate that you are merging the file from Bitbucket to your local repository.

Click OK from this box. Sourcetree updates with a description of the merged file.

Navigate to your repository folder on your local system and you’ll see the file you just added.

Fantastic! Now, you have finished the basic DVCS workflow (clone, add, commit, push, and pull) between Bitbucket and your local system.

Step 4: Use Sourcetree branches to merge an update

After looking through the Intergalactic Mall Magazine, you see a pair of speakers that you really want for the space station. They are big enough to produce a good amount of sound and soft enough that the lack of gravity won’t cause them to crash. The only problem is that they pretty pricey, and you need approval before you can officially add them to your list of supplies.

In the meantime, create a feature branch so that you can update the supply to your request list while you wait. Then when you have approval, you just merge the requests file from the feature branch into the main branch.

Branches are most powerful when you’re working on a team. You can work on your own part of a project from your own branch, pull updates from Bitbucket, and then merge all your work into the main branch when it’s ready. Our documentation includes more explanation of why you would want to use branches.

Step 1: Create a branch and make a change

Let’s create a branch so that you can list the speakers in your supply requests file. Even though branches work differently between Git and Mercurial, you create them in a similar way from Sourcetree.

  1. From Sourcetree, click the Branch button.
  2. Depending on whether you have a Git or Mercurial repository, you see a different popup for creating a new branch. From the New Branch or Create a new branch field, enter wish-list for the name of your branch.

Click Create Branch or OK.

From Sourcetree, click the Show in Finder button. The directory on your system opens.

From the directory folder, open the supplyrequest file with a text editor.

Making a change to the file by adding the following item to the list of supplies:

anti-gravity speakers

Open the view in Sourcetree and notice that your repository now has uncommitted changes.

From here, everything you do is the same as you did when you added the supplyrequest file and initially committed it.

If you have a Git repository, make supplyrequest.txt ready to commit by selecting Stage file from the options menu.

Click the Commit button at the top to commit the file.

In the message box, enter «Adding an item for my wish list.»

Click the Commit button under the box. From Sourcetree, you see that the file has been updated on the wish-list branch.

Step 2: Merge file changes from a branch

Your speakers were approved! Now it’s time to update the main supply list with your wish-list item.

  1. First, you want to switch back to the main branch. From the left-side menu items in Sourcetree, hover your mouse over the right side of the Branches label so that the word Show appears.
  2. When Show appears, click it. Under the Branches heading, you will see the two branches for this repository, the main branch, and the wish-list branch. The main branch for a Git repository is called master . The main branch for a Mercurial repository is called default .

Double-click the feature branch (in this case wish-list ) to switch to that branch.

Click the Merge button.

From the popup that appears, make sure the commit on your wish-list branch is highlighted. You are indicating that you want to add the commit from this branch to the main branch.

If you have a Git repository, check this option at the bottom: Create a commit even if merge resolved via fast-forward.

Click OK. You have updated the supplyrequest file in your main branch with your wish-list item. Sourcetree will look slightly different based on whether you have a Git or Mercurial repository.

If you have a Git repository, you are done. If you have a Mercurial repository, you will notice that you need to commit your changes. Click the Commit button at the top. The commit message defaults to a description with «Merge.» Keep this message and go ahead and click Commit.

Step 3: Push your change to Bitbucket

From Sourcetree, click the Push button to push your committed changes.

From the dialog box that appears, click the OK button to push changes to your local repository.

Click the Overview page of your Bitbucket repository, and notice you can see your push in the Recent Activity stream.

Click Commits and you can see the commit you made on your local system. Notice that the change keeps the same commit code that it had on your local system.

Click Source, then click the supplyrequest file. You can see the last change to the file has the commit code you just pushed.

Click the file history list to see the committed changes for this file, as shown in the following image.

You are done!

That was intense! Maybe. Depends on how it compares to launching into space. Now that you know a lot more about Bitbucket, you are now prepared to run your space station’s activities a lot better. Now, take a break and go do some star gazing.

Want to learn more about Bitbucket and Sourcetree? You can take on the challenge of updating a teammate’s repository.

источник

Добавить комментарий

Adblock
detector