CODEWITHSUNDEEP
gitversion-control
Bruno Brs
Bruno Brs

Reputation: 693

How to actually work with Git in a concurrent enviornment

So, we are migrating from CVSNT to Perforce or Git, and i've been studying their features in the last weeks, and it is clear for me that Perforce actually is a bit more similar since it is centralized.

Git seems fast, but we are a company where all the developers stay in the same room, even though there's over 100 developers, still all computers are connected to a CVSNT server...

For this reason, i can't see how i could adapt Git to work as well as Perforce would do..

For being offline, when one clones a Git repository, he will copy the history and all about that repository to have it working offline, however, working in a concurrent way, it seems weird that you have a local file's history for example...

So if the developer B commits and push to the server, the developer A won't know it, it won't be in his file's history...unless he actually pulls from the server, right?! (as long as they are in the same branch..)

But if it works this way, then i'd be actually working in a centralized way with a distributed SCM...and have to 'guess' when one has pushed to the server.. even if there's a command to know if a file has a new revision, it is bad having to check it manually..

Can someone explain me better how actually Git can work in a concurrent way without one having to know when the other actually push to the server, etc..?

Another thing, i couldn't find any nice Revision Graph on Git, i've found in Tortoise Git, but its more like a branch graph than a revision's graph..

Upvotes: 2

Views: 1554

Answers (3)

fjarri
fjarri

Reputation: 9726

A usual scenario (very simplified) is the following:

  1. A developer checks out the master branch to his machine (AKA "trunk" in SVN, the place with the most recent commits).
  2. He branches off from it and creates a local branch.
  3. In this local branch he creates necessary commits.
  4. He creates a "pull request" from this branch (in other words, asks for it to be merged back to master).
  5. Whoever is in charge of the master branch reviews the changes and merges them into the master.

The master branch could change from the time the developer had branched off, but if the new changes do not intersect the changes made to the master branch, the merge is done automatically. So the master branch is only blocked for a negligible time when git performs the merge.

If they do intersect (which is not that often), there are two ways to resolve it. First, the guy who is responsible for handling pull requests can resolve the conflicts manually. Second, he can call the developer and ask him to do it. The developer then checks out the updated master branch, merges it to its local branch (resolving conflicts) and creates a new pull request, which is now almost guaranteed to succeed.

In reality, of course, there may be several concurrent branches (say, master, some branches for major features, a release branch and so on), and several managing persons. But in any case, there are no global locks and no need to maintain a connection with the main repository.

A very good development process with Git is described in Git Flow.

Upvotes: 3

VonC
VonC

Reputation: 1328712

The usual workflow with a DVCS like git doesn't rely on you guessing if someone has push or not.

You just push, and if anyone else has pushed before you, your action will be, by default, denied (as being not "fast-forward").

Then you pull:

  • ideally, you git pull --rebase in order to redo your work on top of the most recent commits of that branch).
  • you check if everthing still works
  • you push back

As for the revision graph, a simple git log --graph can help you see what is going on (I like this alias).

Upvotes: 4

Emil Davtyan
Emil Davtyan

Reputation: 14089

... and have to 'guess' when one has pushed to the server.. even if there's a command to know if a file has a new revision, it is bad having to check it manually..

Well for this there is a feature called git hooks which would allow you to fire up a script before or after each commit (and at some other times).

So you could use it to notify (email, sms, pigeons) other people working on a particular branch that someone has pushed to it, so they should do a fetch.

Upvotes: 5

Related Questions