CODEWITHSUNDEEP
git
MiniMe
MiniMe

Reputation: 1275

GIT: Workflow to sync work from two desktop and laptop and a central repo (server shared folder)

I created a central repository (protocol:file) and I want to use that to keep in sync the work I do on my work laptop and my work desktop. I am able to push and fetch files from the repo but I am not clear on how to merge things. As far as I understand, after the files are in the central repo each computer will have a local master/head and a remote master/head. The local master/head is considered a branch of the remote so every time when I commit and push a new branch shows up in the central repo. Here is the link that shows how I created the above described structures Working with GIT4Windows, shared folder and two computers-is this workflow correct?

I thought I was done and I planned to starting the work later (today is "later") and today I realized that I overlooked some aspects.

Consider this situation:
-a new module/feature was created on the laptop
-a new module/feature was created on the desktop
-each computer pushes its changes to the central repo
-now each computer can check out the other computer's new module and merge it in the local master and the two computers are in sync but the central repo has just two branches (the laptop one and the desktop one).

What happens if a third party wants to access the central repo? It will be confusing, when the repo is cloned the user gets an origin/master and two branches, one for the desktop one for the laptop.

What is the work flow to merge the two branches in the central repo? Is this the proper way to work with this setup?

Upvotes: 0

Views: 255

Answers (1)

tkausl
tkausl

Reputation: 14279

There seem to be some slight misconceptions, so lets try to clear them up:

As far as I understand, after the files are in the central repo each computer will have a local master/head and a remote master/head.

Both repositories should have a master branch, correct. head has nothing to do with all of this, I think you're misusing this term.

The local master/head is considered a branch of the remote so every time when I commit and push a new branch shows up in the central repo.

Local master is a local branch. It is tracking the remote master, yes, but they are two different branches. Tracking means this branch will pull from X and push to X, however they are still two branches which can evolve independently. I'm particularly confused by your statement a new branch shows up in the central repo because when you push from master to master then no new branch shows up, master already existed. A few new commits show up on master though.

Consider this situation: -a new module/feature was created on the laptop -a new module/feature was created on the desktop -each computer pushes its changes to the central repo -now each computer can check out the other computer's new module and merge it in the local master and the two computers are in sync but the central repo has just two branches (the laptop one and the desktop one).

What happens if a third party wants to access the central repo? It will be confusing, when the repo is cloned the user gets an origin/master and two branches, one for the desktop one for the laptop.

You're missing an important step in your workflow, merging. There exist different workflows for git, however they pretty much share one true fact: There is one and only one branch in which all changes are collected, possibly merged from a feature branch. There is noting wrong with working directly on master though. Since - again - your local master and remote master are technically two branches, you can work on your local master directly, and when you're ready to "release" your code, push to remote. You'd possibly need to pull first to get new commits you haven't received yet, but it works. Now you can of course work in different branches. Some git workflows recommend one branch for each feature (GitHub's pull-requests work using this model), or one branch for each computer or developer. But every once in a while, you need to collect all those changes made in different branches and put them in a single branch, usually master, which means you need to merge your changes to master. When and how is up to you. Usually, one would work on a development branch for a while until a feature is stable and works and then merge. master would, in this case, always contain a stable software and your development branches contain not-yet-finished features.

Upvotes: 2

Related Questions