Sourcetree mercurial что это

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:

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.

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.

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 main 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:

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.

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.

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.

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.

Источник

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

SourceTree

Содержание

Особенности

Простота для начинающих

Могущество для экспертов

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

Визуализация кода

Видеть действительно верить. Получить информацию о любой ветке или совершить одним щелчком мыши.

Git и Mercurial/Hg на рабочем столе

Полнофункциональный графический интерфейс, который предлагает эффективный, последовательный процесс разработки сразу.

Комментирование

Визуализируйте свою работу и продвигайтесь с уверенностью. Сцена и отмена изменений в файле, фрагменте или отдельной линии.

Полноценный клиент

Обновление статуса Git

Никогда не пропустите ничего. Следите за своей работой и следите за своим кодом с первого взгляда.

Визуализация прогресса

Подробные диаграммы ветвления позволяют легко идти в ногу с прогрессом вашей команды.

Windows и Mac

Используйте возможности Git и Mercurial для двух наиболее популярных операционных систем.

Права Git

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

Git у вас под рукой

Не только графический интерфейс Git. SourceTree помещает мощь Git front и center в простой в использовании интерфейс.

Поддержка больших файлов Git

SourceTree поддерживает Git LFS, позволяя командам отслеживать крупные активы в одном месте.

Поиск локальных транзакций

Искать коммиты, изменения файлов и ветви прямо в SourceTree.

Git-flow из коробки

Интерактивное перебазирование

Получите чистые и понятные коммиты с помощью инструмента интерактивной перезагрузки SourceTree.

Подмодули

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

Удаленный менеджер хранилища

SourceTree позволяет вам искать и клонировать удаленные репозитории в своем простом пользовательском интерфейсе.

Источник

Ещё раз о «Mercurial против Git» (с картинками)

Некоторое время назад я опубликовал очень многословное сочинение, где пытался объяснить, почему Git серьёзно поломан, и почему всем следует вместо этого пользоваться Mercurial, до тех пор, пока разработчки Git его не починят. Ну ладно, я был не настолько груб, но близок к этому.

Народ на Reddit жаловался, что мой технический язык слишком путанный, особенно потому что я придумывал новую терминологию в попытках доказательства своих положений. Они потребовали графы, с узлами, рёбрами, кружочками, стрелочками и всем прочим. Тогда я промучал графический редактор несколько часов и получил два графа, приведённые ниже, которыми я надеюсь обрисовать проблему.

Я знаю, это нечестно. Я не показываю вам журнал изменений. Но поверьте мне, вы не захотите его видеть. Он не поможет. Вы думаете, одомашненные приматы [1] записали там полезные подсказки, которые ответили бы вам на эти вопросы, но они не сделали этого. Хуже того, иногда они врут.

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

Каждый узел в графе раскрашен, чтобы показать имя своей ветки в Mercurial. Всякая угадайка становится не нужна. Вы твёрдо знаете, что когда-то была ветка с именем «temp», которая затем влилась в ветку «release», а не «master». Вероятно, сейчас она отмечена закрытой, как больше не нужная.

Некоторая первоначальная работа над веткой «topic» ушла в ветку «temp» перед тем тем, как слилась с веткой «release». Позднее, ветка «release» была обратно влита во вновь ведущуюся ветку «topic».

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

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

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

[1] Одомашненные приматы — вероятно, отсылка к Тимоти Лири или Роберту Антону Уилсону — прим. перев.

Источник

Сходство и различие между Mercurial и Git

Немного истории

Толчком к созданию обеих систем, как Mercurial, так Git, послужило одно событие 2005 года. Всё дело было в том, что в упомянутом 2005 году ядро системы Linux потеряло возможность бесплатного использования системы контроля версий BitKeeper. После пользования BitKeeper в течение трёх лет разработчики ядра привыкли к его распределённому рабочему процессу. Автоматизированная работа с патчами сильно упрощала процесс учёта и слияния изменений, а наличие истории за продолжительный период времени позволяло проводить регрессию.

Другой немаловажной частью процесса разработки ядра Linux стала иерархическая организация разработчиков. В вершине иерархии стоял Диктатор и много Лейтенантов, отвечавших за отдельные подсистемы ядра. Каждый Лейтенант принимал или отклонял отдельные изменения в пределах своей подсистемы. Линус, в свою очередь, затягивал их изменения и публиковал их в официальном хранилище ядра Linux. Любой инструмент, вышедший на замену BitKeeper, должен был реализовывать такой процесс.

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

Среди множества инструментов подходящего не нашлось. Практически одновременно Мэт Макол (Matt Mackall) и Линус Торвальдс (Linus Torvalds) выпускают свои системы контроля версий: Mercurial и Git соответственно. В основу обеих систем легли идеи появившегося двумя годами ранее проекта Monotone.

Cходство

Отличия

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

Хранение истории

И Git, и Mercurial идентифицируют версии файлов по их контрольной сумме. Контрольные суммы отдельных файлов объединяются в манифесты. В Git манифесты называются деревьями, в которых одни деревья могут указывать на другие. Манифесты непосредственно связаны с ревизиями/фиксациями.

Mercurial для улучшения производительности пользуется специальным механизмом хранения Revlog. Каждому файлу, помещенному в хранилище, сопоставляется два других: индекс и файл с данными. Файлы с данными содержат слепки и дельта-слепки, которые создаются только когда количество отдельных изменений файла превышает некоторое пороговое значение. Индекс служит инструментом эффективного доступа к файлу с данными. Дельты, полученные в результате изменения файлов под контролем версий, добавляются только в файлы с данными. Для того, чтобы правки из разных мест файла объединить в одну ревизию, используется индекс. Ревизии отдельных файлов складываются манифесты, а из манифестов — фиксации. Этот метод зарекомендовал себя весьма эффективным в деле создания, поиска и вычисления различий в файлах. Также к достоинствам метода можно отнести компактность по отношению к месту на диске и достаточно эффективный протокол передачи изменений по сети.

В основе модели хранения Git лежат большие объектные бинарные файлы (BLOB). Каждая новая ревизия файла — это полная копия файла, чем достигается быстрое сохранение ревизий. Копии файлов сжимаются, но, всё равно, имеют место большие объёмы дублирования. Разработчики Git применили методы упаковки данных для снижения требований к объёму хранилища. По существу они создали нечто похожее на Revlog для указанного момента времени. Полученные в результате упаковки пакеты отличаются от Revlog’а, но преследуют ту же цель — сохранить данные, эффективно расходуя дисковое пространство. В виду того, что Git сохраняет слепки файлов, а не инкремент, фиксации могут легко создаваться и уничтожаться. Если при анализе требуется посмотреть разницу между двумя различными фиксациями, то в Git разность (diff) вычисляется динамически.

Ветвление

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

Ветки Git, по сути, являются лишь указателями на фиксации. В разных клонах хранилища ветки с одинаковыми названиями могут указывать на разные фиксации. Ветки в Git могут удаляться и передаваться по отдельности (каждая уникально идентифицируется по локальному имени в хранилище-источнике).

Практические аспекты использования

Различия в реализациях Git и Mercurial можно проиллюстрировать на примерах.

Mercurial позволяет легко фиксировать изменения, проталкивать и вытягивать их с поддержкой всей предыдущей истории. Git не заботится о поддержке всей предыдущей истории, он только фиксирует изменения и создаёт указатели на них. Для Git не имеет значения предыдущая история и на что раньше ссылались указатели, важно то, что актуально в текущий момент. Существует даже инструмент, гарантирующий сохранность локальной истории при вытягивании изменений из внешнего хранилища — fast-forward merge. Если этот механизм включен, то Git будет сообщать об изменениях, которые не могут быть улажены без продвижения по истории вперёд. Данные ошибки можно не принимать во внимание, если поступившие изменения ожидались.

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

Для решения различных проблем в Mercurial существуют расширения. Каждое расширение решает свои проблемы хорошо, если существует само по себе. Существует даже некоторые расширения, обеспечивающие сходную функциональность, но разными способами.

Для примера рассмотрим работу с отложенной историей. Допустим, нам необходимо записать изменения из рабочей копии без фиксации в хранилище. Git предлагает использовать stash. Stash — это фиксация или ветка, которые не сохраняются в обычном месте. Stash не показывается, когда выводится список веток, но всеми инструментами он трактуется как ветка. Если аналогичная функциональность требуется Mercurial, то можно использовать расширения attic или shelve. Оба этих расширения хранят «отложенную» историю в качестве файлов в хранилище, которые могут быть при необходимости зафиксированы. Каждое расширение решает проблему немного по-своему, поэтому имеет место несогласованность форматов.

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

Выводы

В последнем разделе этой статьи хотел бы высказать собственное мнение по выбору системы контроля версий. И Mercurial, и Git хороши в своих сегментах.

Источник