Hi Salah,

It sounds like your team might be more familiar with something line Visual 
SourceSafe. In the VSS model, VSS holds keep your code and one person can 
check it out at a time. The VSS discourages multiple uses 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 lock-out of making changes 
to that file.

Also, the Git paradigm allows multiple users to edit the same file and 
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 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 
> present 
> 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.
> Salah

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 git-users@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to