I was thinking of bringing up a git service on an Ubuntu server. However, the way me and another programmer operate -- we really want to try and stick to one person working on a project at a time.
How would I make a Bash script to create a check in and check out with git? We want to prevent anyone from checking in code that hasn't already been checked in, and it should error out with the name of the person who has the code checked out.
EDIT: I'm not really interested in using Git with its fantastic diff features. I move 100mph and don't have time to play diff games with the other developers. That's why we're using Git. If the other developers want to play the diff game, they can still do so. But when I check something out, I want it locked to everyone until I check it back in again.
Errr... sorry, this isn't how a DVCS (with a D as "Distributed") works at all.
a/ you don't "checkout" a file (like you would in ClearCase for instance). You just start modifying it, and Git will detect the change as a candidate for indexing (
git add) and for committing (git commit, the "checking" part)b/ When you "checkout" (i.e. modify) or checking a file, the other developers, with their associated other repos, don't know anything about that.
You "locking" everybody in that everybody can't access your repo and modify your files.
But when you publish (i.e push those changes), then you need to solve any concurrent modification. In a DVCS, there is no central referential able to detect a concurrent change and/or to record a "lock".
That's not exactly the way git was designed to work. That is, it isn't the typical git workflow. If you really want that workflow, consider using something built around that kind of workflow like SubVersion. Locked files result in notifications if someone else wants the file, but you own the file:
http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.advanced.locking
I don't know if the git-svnserver gateway supports locking but it might. If it does, then you can have the best of both worlds.
Git is very flexible, however. If you want to be mean it will support that. Git lets you blindly wipe away anyone else's changes that may have occurred while you were using the file. Every time you want to push to the main repository just do:
No need for that merge feature.
That pair of commands will push your changes to the server ignoring any changes other people have made since your last sync.
Another option to consider is "git pull --strategy recursive -Xours".
Is communication with the other programmer an option? For a small team that's almost certainly a better way than relying on locking.
If you insist on locking, Git's distributed model is not really a good fit. Instead of Git you should probably look at using a centralised version control system, like SVN. This allows you to put a lock on files in the repository. Your fellow programmer will receive a warning when he/she tries to commit to the repo.
You really don't need this.
Gitand other good source control systems handle merges well enough that you don't need to lock files on checkout. Instead, make sure you both make frequent commits and regularly push your changes upstream.As for writing a bash script to checkin and out, you could always write a bash script like anything else ... just a series of commands like you would run them on the command line, but again you don't need this. You only need one command to update your local repository, one command to commit, and one command to push upstream. It would behove you to learn git first, then consider scripting later when you find a task that is tedious to run as individual commands yourself.