Git Reliability and Usability in a centralised workflow

We recently started using Git as source code version tool. We use it in a centralised fashion where the central repository is hosted on Atlassian Bitbucket. It is worth highlighting that the central repository on Bitbucket is not bare.

As per the Git client we used, we started using the e-git Eclipse plugin. But it didn't seem to be reliable and usable enough, so we switched to TortoiseGit (which was more familiar to developers, as most of them had already used TortoiseCvs or TortoiseSvn in the past).

We've already faced some serious repetitive counter-productive issues with basic use cases such us committing or updating local copy. We are worried that when we get to more elaborate use cases such us branching/merging this may get worse.

Main issues we had so far:

  • Instances where files disappeared from the central repository, following a push from a local repository, without any trace in the log (i.e. they weren't git-deleted). Regardless of the client used (e-Git or TortoiseGit), this worries me about the robustness and reliability of the tool, why a file that wasn't git-deleted explicitly should suddenly disappear from the central repository? Surely a respectable tool should prevent this from happening during the push process regardless of the client used for issuing the git push command (SVN does that very well). Can this be explained by the central repository not being "bare"? (Some Git tutorials recommend using bare repositories for centralised workflows)

  • Synchronising local repository from central repository (using TortoiseGit "pull" command) doesn't have the simple outcome it should have, i.e. a working copy up-to-date with the central repository (compared to SVN for example); instead it applies the updates from central repository as modifications to the local working copy which then need to be committed and pushed to the central repository again. Could this be down to the use of TortoiseGit's plain "pull" command without the --rebase option? (Some Git Tutorials recommend the use of "pull --rebase" instead of a plain "pull" to avoid "merge commits" when updating local repository from central repository)

  • Are Git clients (e-Git 3.0.0 and to a less degree TortoiseGit 1.8.7) reliable and robust enough? Could the unreliability of the Git client tools be causing the issues described above. If that's the case, being restricted to using the git command line without clients, would still be concerning: at the end of the day a developer doesn't want to be using command lines for frequent operations like commits and updates etc. as this can be counter-productive and error-prone, he/she ideally wants to have the code versioning integrated in the IDE.

In summary the fundamental questions are:

  1. Is it worth using Git instead of SVN knowing that all our code-versioning workflows are "centralised" (at least in the foreseeable future)? What would be its added value compared to SVN for a centralised workflow (apart from the ability to work offline maybe, which I am sure developers can survive without it)?
  2. If the answer to the previous question is yes, what are the guidelines to use Git as a centralised VCS effectively (i.e. with a STABLE client that is ideally integrated in Eclipse) and reliably (i.e. without the issues described above)

Answers


Many questions here.

Instances where files disappeared from the central repository, following a push from a local repository, without any trace in the log (i.e. they weren't git-deleted). Regardless of the client used (e-Git or TortoiseGit), this worries me about the robustness and reliability of the tool, why a file that wasn't git-deleted explicitly should suddenly disappear from the central repository? Surely a respectable tool should prevent this from happening during the push process regardless of the client used for issuing the git push command (SVN does that very well).

Apart from misunderstandings (i.e. the file isn't really gone) the only reasonable explanation for a file vanishing from all versions of the codebase is that someone screwed up and made a non-fast forward update of the branch and annihilated the file in the process. Git does allow this to happen, but such potentially dangerous updates can easily be turned off and usually should be turned off. Some Git hosting systems (possibly including Bitbucket) support ACLs to control which users are allowed to perform non-fast forward updates.

If that indeed is what happened you should be able to recover what was lost if you act reasonably quickly before the objects have a chance to get garbage-collected.

Can this be explained by the central repository not being "bare"? (Some Git tutorials recommend using bare repositories for centralised workflows)

No, but it's still unclear why your central repository isn't bare. By default Git refuses to push into non-bare repositories, and while the reasoning behind that might not apply to you I see no advantage of having a non-bare repository.

Synchronising local repository from central repository (using TortoiseGit "pull" command) doesn't have the simple outcome it should have, i.e. a working copy up-to-date with the central repository (compared to SVN for example); instead it applies the updates from central repository as modifications to the local working copy which then need to be committed and pushed to the central repository again. Could this be down to the use of TortoiseGit's plain "pull" command without the --rebase option? (Some Git Tutorials recommend the use of "pull --rebase" instead of a plain "pull" to avoid "merge commits" when updating local repository from central repository)

To avoid these merge commits (which I agree are a nuisance) without having to specify --rebase in each push command, the branch.autosetuprebase and branch.<name>.rebase configuration options might be useful. See the git-config(1) man page for details.


Answer to question #1: Yes, it is worth using. Check out SourceTree by Atlassian. Also get to know Git from the command line. Know thy tools. :)

Merging in Git is so much easier and more accurate.

<opinion>Frankly if you have a code base with many developers and a chaotic business environment where priorities are constantly shifting, I don't like using anything else.</opinion>

Answer to question #2: I've found this blog post to be very helpful: A successful Git branching model. I know "branching" doesn't sound much like "workflow", but with Git they are intimately intertwined. The Git book online also has a good overview: Distributed Workflows - gitscm.com.


Need Your Help

How to get a message from a redirect in Laravel

laravel laravel-4

return Redirect::to('KSMschema')->with('message', $HeadNr)->withErrors($v);