Как использовать Git, чтобы работать в том же проекте в распространенной команде?

У меня есть сомнения с git, хорошо, команды и такой я знаю их, но у меня есть сомнения, как организовывания. Я рассказываю вам немного мой случай:

Я обычно работаю с двумя компьютерами, одним дома и другой в работе (я не работаю программистом, но в свободном времени я делаю cosillas). Если у меня есть проект в github, мое сомнение такое, как я должен делать, чтобы программировать в этом проекте с двух компьютеров.

Посмотрим вы ориентируете меня немного на правильном способе работать с git.

Я ИЗДАЮ:

Если я клонирую хранилище в двух компьютерах, в двух он использовал бы ветвь "степень магистра", тогда, если, например, однажды вечером из-за чего-нибудь в этом роде я не пересылаю изменения, которые я сделал в работе, потом прибыв в дом: Я могу оставаться с нормальностью?

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

6
задан 11.06.2016, 15:33
5 ответов

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

Когда ты сделаешь изменения в работе например, добавь изменения к хранилищу (git add и git commit корреспондент). Однажды сделанный, перешли изменения в удаленное хранилище, которое в github:

git push origin RAMA

Если ты не работаешь ни с какой ветвью в часть ветви master, перешли изменения в эту.

Когда ты прибудешь в дом, только ты нуждаешься в том, чтобы принести изменения, которые находятся в удаленном хранилище (github):

git pull origin RAMA

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

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

Привет.

10
ответ дан 24.11.2019, 14:11

Существуют некие хорошие практики, рекомендуемые для команд разработки, которая обычно называется Хит Флов или разгрузка работы с Git. Это позволяет иметь стандарт разработки и организовывать правильно разработку проекта, чтобы иметь взгляд все время процесса, который:

GitFlow

Я объясняю тебе график:

  1. Степень магистра: Это ветвь (branch), у которого есть последняя производительная версия кода.
  2. Будьте перечитан: Это ветвь, которая содержит новые законченные features, которые разработаны для следующего запуска (будьте перечитан), так что после того, как инициализируйте новый один, ты можешь загружать все предыдущие, если у них есть какая-то зависимость.
  3. Develop: Это ветвь, которая содержит характеристики (features) в стадии строительства в повторении, эта ветвь будет позже частью Release посредством pull request.
  4. Feature: Это ветвь, которую содержит feature, в котором ты работаешь лично (несколько разработчиков могут работать в feature), этот должен быть посланным в develop посредством full request, в общем принятого техническим лидером.
  5. Hotfix: Это ветвь, которая содержит срочные изменения на степени магистра, которые позволяют исправлять вирус или решать ошибку, этот должен быть посланным в степень магистра и нужно сообщать всем разработчикам для того, чтобы они смогли обновлять Ваши ветви.

Инструменты

Для этого существуют программные средства, которые позволяют упрощать этот процесс посредством команд, например git-flow http://danielkummer.github.io/git-flow-cheatsheet/

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

git flow init
git flow feature start MYFEATURE
git flow feature finish MYFEATURE
git flow feature publish MYFEATURE
git flow release start RELEASE [BASE]
git flow release publish RELEASE
git flow hotfix start VERSION [BASENAME]
...

Для передовых пользователей

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

Между ними я могу выделяться:

  • Git Tree, Хит Субмодулес: Это позволяет объединять независимые хранилища от такого кода как часть большего одного, чтобы избегать повторять файлы, например, когда у тебя есть хранилище для книжного магазина и другого для приложения, которое использует книжный магазин.

  • Интегральная микросхема, Трэвис, Коде Климате: Программные средства третьих, что позволяют автоматизировать ревизию кода и выполнение теста то, что облегчает задание сотрудничества после того, как считает всегда определенным статус консистенции кода, сделав merge на посланном full request.

  • Markdown, Пуль Рекест comments, Этикетки: Это прибыли, которые в особенности принадлежат Github, Bitbucket или Gitlab, который позволяет создавать трэд чата на pull request, приклеивать этикетку или соединять branch, pull request, commit, пользователь или комментарий и или создавать форматированный текст форматируя разгрузку.

9
ответ дан 24.11.2019, 14:11
  • 1
    Он у меня не остается ясным c и # 243; mo это отвечает на вопрос OP. – dwarandae 11.06.2016, 03:16
  • 2
    Ответь завершение вопроса, который включает главный вопросительный знак " Посмотрим я orient и # 225; is немного на правильном способе работать с git. и quot; ответ выставляет более широкой формы правильную разгрузку работы с git, который я предлагаю, чтобы он принял, что улучшает Вашу форму работы над только решением главной проблемы, где давать, и # 237; в равный работать с git или svn – Joel Ibaceta 11.06.2016, 04:11

Я думаю, что следующий imágen представляет схему того, что ты хочешь реализовать. introducir la descripción de la imagen aquí

Сначала ты должен иметь в виду, что тип хранилища - тот, которого ты хочешь создать или нуждаешься (bare vs нечетное число - bare). Я нашел следующую статью, которая объясняет на основании предыдущего изображения видеть соединение

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

#!/bin/bash

# UpToGit 0.1
# Actualiza facilmente tu repositorio Git
# (CC) 2011 Alfonso Saavedra "Son Link"
# http://sonlinkblog.blogspot.com
# Bajo licencia GNU/GPL

# Modo de uso: copia o mueve este script a /usr/bin o /usr/local/bin y desde el directorio donde se encuentre la copia de un repo git, ejecútalo de esta manera:
# uptogit <ficheros>

# Comprobamos si el directorio en el que estamos es de un repositorio git
if [ ! -d '.git' ]; then
    echo 'Esta carpeta no contiene un repositorio Git'
    exit -1
fi

# Ahora comprobamos si se le paso algun parametro
if [ $# == 0 ]; then
    echo "UpToGit: ¡Error! No se le a pasado ningún parámetro"
    echo "uptogit fichero1 fichero2 ... ficheroN"
    exit -1
else
    # Recorremos los parametros para comprobar si son ficheros o directorios
    for file in $*; do
        if [ ! -e $file ]; then
            echo "UpToGit: El archivo o directorio $file no existe"
            exit -1
        fi
    done

    # Si llegamos hasta aquí, indicamos a Git los archivos a subir
    git add $*

    # Esto nos pedira el mensaje del commit
    echo "Introduce el mensaje del commit:"
    read TXT
    git commit -m "$TXT"

    # Y terminamos subiendo los archivos
    git push origin master
fi

С моей стороны я это использую с GitLab и он скроллирует меня очень хорошо. Хороший надеюсь, что он ты полезный.

4
ответ дан 24.11.2019, 14:11
  • 1
    Я думаю, что эта диаграмма соответствует так называемому SVN mode, которого он использует git как будто он относился друг к другу svn, cvs и другие немного устаревшие решения, не эксплуатируя потенциала git, рекомендуется для людей, что est и # 225; n мигрируя или инициализируясь с git, но рекомендует расти в комплексности, чтобы улучшать разгрузку работы. – Joel Ibaceta 10.06.2016, 21:15

Ну, из-за опыта совет, который я продолжил, они пошли:

  1. Branches или Ветви.

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

  1. Использование Pull request

Он мне кажется организованным способом, которого эти branches или ветви, которые creastes, объединялись с твоей степенью магистра. Adicionalmente, если ты делаешь это этой формой, и есть ошибка, - более легкий делать ему rollback и наиболее еще уменьшается тот, который падает в конфликты кода.

Помни, что идея состоит в том, чтобы ни один твой требование в прогрессе они нанесли вред степени магистра.

2
ответ дан 24.11.2019, 14:11
  • 1
    В этой схеме лично я рекомендую добавлять уровень под степенью магистра, " develop" например так что в степени магистра у тебя всегда были c и # 243; я говорю производительно, так ты можешь автоматизировать пропуска в producci и # 243; n с хранилища, несмотря на то, что принимает pull request в степени магистра – Joel Ibaceta 10.06.2016, 20:58

Чтобы работать в двух различных компьютерах в то же время используя Git, она soluciГіn, который я дал этой проблеме для меня, он состоит в том, чтобы создавать мое хранилище во внешней единице: жесткий диск или Usb, это позволяет двигать твою разработку между компьютерами и пересылать изменения в твой github, когда они будут реальными, и ты не сшил частичные, как будто ты tocarГ - в с предыдущими выборами.

Я не Знаю который язык programaciГіn ты используешь, но в Php ты конфигурируешь http.conf и определи DocumentRoot во внешней единице. Если он java, deberГ, - чтобы конфигурировать твой IDE для того, чтобы он искал проект во внешней единице.

-1
ответ дан 24.11.2019, 14:11