CODEWITHSUNDEEP
gitversion-control
Markus
Markus

Reputation: 1285

How to prevent editing same files using git by multiple users

I am currently writing a paper in collaboration with a post doc for a conference. We investigated using version control software and git seemed to be a great candidate. Now we have to real experience with it and are facing some problems. Specifically that we sometimes edit the same files before pushing, resulting in errors for whoever wants to push second.

What are some tips / tools / etc. one can use in order to prevent this simultaneous editing? I know git is used for big projects with many collaborateurs that do not face these problems, so what are we doing wrong?

Any ideas?

Upvotes: 3

Views: 4570

Answers (3)

frank
frank

Reputation: 597

Actually, as you are writing a paper and not code, git might not be the perfect tool. By using google docs or something similar you will be able to see changes made by your partner nearly in real time. And you don't have to go through the commit/push/merge thing.

Upvotes: 1

Tom Kerr
Tom Kerr

Reputation: 10720

Git doesn't have any mechanisms for 'locking' files like TFS does. If two people are both actively editing the same part of a file, you should expect conflicts.

Major things:

Talk to your colleagues about what you are doing. Coordinate if you can, warn them if you must. This seems kind of pedestrian, but it usually happens later than it should. Scrum is nice because it makes it part of your routine.

The biggest factor is how long you keep your changes to yourself. The longer you have outstanding changes, the more opportunity there is for overlapping change sets.

Creating integration branches on features that you are working on together is a good thing. If you create checkpoints, push, and rebase frequently, then you are less likely to make big changes that are hard to correct. Small conflicts are pretty simple to handle though. You may have to go back and clean up some of your commits before pushing to master, but that is usually easy enough to coordinate.

Minor things:

Looking through diffs is an incredible tool for understanding how a piece of code has changed. People shifting between different formatting preferences breaks this tool.

Having a consistent format helps with these inconsequential conflicts. The process of choosing a consistent format is another matter. ;)

If you are working on a function and notice whitespace is incorrect, you'll fix it. Someone else working on the same function will do the same.

For instance, left indention:

namespace foo {
namespace bar {

    class Foo {
    public:
        void something();
    };

    class Foo {
        public:
            void something();
    };

}}

namespace foo {
    namespace bar {
    }
}

I personally prefer putting all namespaces left aligned like the first set. This keeps whitespace noise to a minimum. Consistency is the important thing though.

Tabs vs spaces is another one. Theoretically, it doesn't matter which one you choose, but do choose one.

Avoid moving code (without a good reason obviously). This is hard to do, but if you have more files with fewer things in each file, this is less of a problem.

Keep small "housekeeping" changes separate from your feature/bug fix commits. This makes it dead simple to merge changes on those commits. If one is a feature change and one is a whitespace change, then you can blindly take the feature change.

Upvotes: 1

Philip Oakley
Philip Oakley

Reputation: 14071

"Locking" is in a sense automatic. You have your own copy and they can't take it away from you! Just as they have their copy that you can't take it away from them. This assumes you are using the distributed nature of the git DVCS (rather than both accessing a file share :-( you will each have your own clone and either exchange branches or push to a common bare repo.

The next step is to ensure that the document processor you use is amenable to git merging, ideally that would be a plain text source such as Latex or markdown. Git will happily merge your separate contributions and highlight your conflicts. Don't use very long lines though.

If you are collaborating you will be able to discuss those common areas where merge conflicts occur and agree the best wording.

Enjoy the freedom to both work in parallel.

Upvotes: 0

Related Questions