0

I have always worked alone rather than in a Dev team, so this has never been an issue

I am about to take on someone else to code with so some kind of versioning control is required

I have been looking at GitHub and integrating it with Netbeans

I can make changes and commit them no problem.

I was expecting to be able to ‘check out’ a file or files which would prevent the other user(s) from editing those files while I was editing until I commit the file and check it in

Is this the normal procedure and I am missing something, or is my understanding of GitHub incorrect?

StripyTiger
  • 877
  • 1
  • 14
  • 31
  • https://git-scm.com/book/en/v2 – tkausl Oct 02 '20 at 19:11
  • Does this answer your question? [Understanding the basics of Git and GitHub](https://stackoverflow.com/questions/11816424/understanding-the-basics-of-git-and-github) – flaxel Oct 02 '20 at 19:44
  • Thanks - it does help with some general understanding, but is there anything to stop one of us editing a file the other one is currently editing? – StripyTiger Oct 02 '20 at 21:44
  • When you use a decentralized version control system, you typically don't want to do this—the pull, merge/rebase, and test workflow takes care of it for you (without the added inconvenience of having to stop people from editing). See the answer below by @VonC and my comment on it. If you really don't want people editing the files that you're working on, then consider communicating that to them somehow (perhaps put a comment at the top of the file, or write a note in a commit message). – Ben Zelnick Oct 03 '20 at 00:32

1 Answers1

1

it does help with some general understanding, but is there anything to stop one of us editing a file the other one is currently editing?

No: with a decentralized version control system, there is no (optimist or pessimist) locking mechanism possible or desirable.

The reconciliation is done when you are pushing your local work to the common remote repository: if other commits have already been pushed, you will have to pull first, merge their work to your branch (or rebase your branch on top of their work), test locally and, if everything is still working, try and push again.

Minimizing conflict and avoiding multiple team members are working on the same set of file remains an organization and communication issue.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Note: there is a `git worktree lock` (https://stackoverflow.com/a/30185564/6309), but that involves only multiple *local* copies of working trees. – VonC Oct 03 '20 at 00:20
  • 1
    If you're new to version control, "merge" refers to a method of combining (hence "merging") your changes with those that somebody else has made at the same time. This way, more than one person can work on the same file at the same time, and everybody's changes can be incorporated. – Ben Zelnick Oct 03 '20 at 00:28
  • 2
    @BenZ. True. The key point is: that merge is a *local* operation, where any possible merge conflict is resolved. – VonC Oct 03 '20 at 00:33
  • 1
    In addition to merging locally like @VonC said, you can merge with the pull requests feature on GitHub. But merging locally can give you more control than doing it online (on GitHub). – Ben Zelnick Oct 03 '20 at 00:36
  • Many thanks for all your input on this. It is clear to me that my understanding of it was not quite right, but you have pointed me in right direction. I now know not look for something that isn't there. Thanks again. – StripyTiger Oct 03 '20 at 14:49