How to actually work with Git in a concurrent enviornment

Question

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

Answer 1

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

Answer 2

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