It sounds like your team might be more familiar with something like Visual
SourceSafe. In the VSS model, VSS keeps your code, and one person can
check-it-out at a time. VSS discourages multiple users from accessing the
same file simultaneously.
In Git anyone with access to the repository can clone it and modify any and
every file in their local working directory. This is more flexible because
in VSS someone can checkout a file while they are at lunch, overnight, or
over the weekend, and the other team members are locked-out of making
changes to that file.
Also, the Git paradigm allows multiple users to edit the same file and
helps merge their results together. If I make changes in one part of the
file, and you make changes in another part, Git can automatically merge
those changes together when we commit and push.
The problem you are probably worried about if when two users make changes
to the exact same code; that is, when two developers edit the same lines of
code in the same source file. It's still possible to merge the files, but
Git will recognize that there is a merge conflict and someone will need to
review and resolve the conflict.
If you are worried about preventing these kinds of conflicts, the best
policy is for your team to clearly communicate their efforts. Assigned
responsibilities so that Team Member A is responsible for the
DataAccessLayer and Team Member B is responsible for the Customer object.
Or use an incident tracking system, like JIRA, and have your developers add
notes when they are taking ownership on an issue. Then other developers can
check to see if someone is already working on a specific issue before they
jump in and duplicate efforts.
But in the worse case scenario when two developers edited the same code,
you can still review and accept either person's modifications, or some
hybrid merge which combines some mods made by one developer with some lines
made by the other developer.
Konstantin, I see you wrote , "the whole point of 'I am editing this
source file at the moment' becomes quite moot.", but is that really true?
Don't you see how it can still be important for a team to avoid working on
the same exact lines of code in order to reduce wasted efforts (inefficient
use of resources) and to reduce complicated mergers? The nice thing about
Git is that we can all work on any part of the project at the same time.
When I edit the header portion of "home.html" and you edit the footer, we
can merge without incident. But if we both edit some HTML form in
contact.html, then we duplicated efforts and someone has to deal with merge
conflicts. So I don't feel it's entirely a moot point for a team to
communicate who tasks should be delegated, at least in a commercial
software development setting where time is money. Maybe it's less of an
issue in open-source where everyone is just voluntarily making
contributions and hoping theirs will get accepted. Thoughts?
On Wednesday, September 26, 2012 8:24:39 PM UTC+9, Salah wrote:
> I am doing a research on continuous integration process. I am reading some
> topics from the book available online and understood the Clone-Commit-Fetch
> -Push process.
> I have a little question though: Some team developers that I encountered
> would like to be able to see which files (codes) are modified in the
> time locally. They told me that in their projects, some codes have to be
> modified by one person at time. For example, developer A wants to modify a
> code, but receives a notification (or some alert) that developer B is
> changing the file in his local machine but that he has not committed yet.
> I am
> aware this stops work a little bit, but those are their requirements.
> I am wondering if GIT offers this possibility to developers.
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To view this discussion on the web visit
To post to this group, send email to email@example.com.
To unsubscribe from this group, send email to
For more options, visit this group at