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 https://groups.google.com/d/msg/git-users/-/D1fS0W0BySgJ. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
