5 votes

How to use Git to work on the same project on a distributed computer?

I have a few questions with git, well, the commands and such, I know, but I have doubts of how to organize myself. I tell you a little of my case:

I work with two computers, one at home and another at work (Not work of a programmer, but in the free time I do things). If I have a project on github, my question is how should I do to schedule in that project from the two computers.

To see if I am certainly directing a little bit about the correct way of working with git.

EDIT:

If I clonus the repository on both computers, the two would be using the branch "master", then if, for example, an afternoon so you may not get the changes I made in the work, then upon arriving home, can I continue as normal?

And if in each one of the computers I have a different branch, the way to do is to do a branch for each task? That is to say, in the work computer I create a branch to develop certain features of the program, then at home I another to develop on the other part and thus each branch for a task.

10voto

Madh Points 701

To work from two different locations, you must clone the github repository on both computers and to maintain and update both repositories.

When you make changes in the work, for example, adds the changes to the repository (git add and git commit ). Once done, upload the changes to the remote repository is at github:

git push origin RAMA

If you're not working with any branch part of the branch master, upload the changes to this.

When you get home, you only need to bring the changes that are in the remote repository (github):

git pull origin RAMA

The name of the branch must be the same, since you're specifying for which branch you want to bring the changes to your local repository.

Before adding any new modification, it is always advisable to check that there is no change to more updated in the remote repository. For this, you can use the command above, git pull.

Greetings.

10voto

Joel Ibaceta Points 2154

There are some good practices for development teams, which is usually called Git-Flow or work-flow with Git. This allows you to have a standard of development and to correctly organize the development of a project to have a vision all the time in the process, which is:

GitFlow

I'll explain the chart:

  1. Master: it Is the branch (branch) that has the latest version of production code.
  2. Release: Is the branch which contains new features finished that are developed for the next release (release) so that when you start a new one you can download all of the above so if you have any dependency.
  3. Develop: it Is the branch that contains the characteristics (features) in development in an iteration, this branch will be later part of Release using a pull request.
  4. Feature: it Is the branch that contains the feature you're working on personally (multiple developers can work on a feature), it must be sent to develop through a full request, usually approved by the technical leader.
  5. Hotfix: this Is the branch that contains urgent changes on master that allow you to fix a bug or solve an error, it must be sent to master, and should be notify all the developers so they can update their branches.

Tools

For this there are tools that can simplify this process by using command, for example git-flow http://danielkummer.github.io/git-flow-cheatsheet/

Which provides you with the following commands, which encapsulate the intermediate steps following the flow:

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]
...

For advanced users

In addition to this flow, Git provides many tools that allow us to improve our work flow, code management and automation.

Among them I can mention :

  • Git Tree, Git Submodules: This allows you to integrate repositories of independent code as part of a greater one to avoid repeating files, for example when you have a repository for a library and another for an application that uses the library.

  • CI, Travis, Code Climate: third-party Tools that allow you to automate code review and execution of tests and facilitates the task of collaboration have always defined the status of consistency of the code after you do a merge on the full request is sent.

  • Markdown, Pull Request comments, Tags: Are utilities which in particular belong to Github, Bitbucket or Gitlab which allows you to create a thread of conversation on the pull request, tag, or link to a branch, pull request, commit, user, or comment and or create rich-text, enriching the flow.

4voto

Robles Points 135

I think that the following image represents the outline of what you want to do. introducir la descripción de la imagen aquí

First you have to take into account, which type of repository is the one that you want to create or need (bare vs non-bare). I found the following article which explains on the basis of the image above see the link

On the other hand, possibly not go with your answer but, I think you can be useful. It is a small script that I found to upload our projects to git, which was developed by Alfonso Saavedra

#!/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

For my part I use it with GitLab and I runs very well. Well I hope will be helpful.

2voto

Wilfredo Points 2100

Well, for one experience the advice that I followed were:

  1. Branches or Limbs.

You need to work a lot with branches because you can work on a requirement without affecting the master, because, if you have something half done will do a push and continuous in-house without affecting the environment.

  1. Use of the Pull request

It seems to Me an organized manner that those branches or limbs that creastes, go fusionandose with your master. Additionally, if you do it this way and there is an error, it is easier to make rollback, and better yet it slows down to fall into conflict code.

Remember that the idea is that any of your requirement in progress may damage the master.

-1voto

Juan Barreto Points 99

To work on two different computers at the same time using Git, the solution that I have given to this problem for me, is to create my repository on an external drive: hard drive or Usb, this allows you to move your work between computers and upload your changes to your github when you are real and not stuff partial, as if you played with the options above.

I don't know which programming language you're using, but in Php you set up the http.conf and set the DocumentRoot in the external drive. If it is java, you should configure your IDE to find the project on the external drive.

HolaDevs.com

HolaDevs is an online community of programmers and software lovers.
You can check other people responses or create a new question if you don't find a solution

Powered by:

X