Hands-On Software Engineering with Python
上QQ阅读APP看书,第一时间看更新

Basic workflows for Git and SVN compared

Although the basic checkout, work, merge, and commit workflow is supported by all mainstream SCMs, it's worth looking at some of the additional process steps that Git requires. Each additional step is, obviously, an additional task that a developer will have to perform before code is fully committed, though none of them are necessarily long-running tasks, so the impact is rarely going to be substantial. On the other hand, each additional step involved provides an additional point where additional code modification can be made before it's attached to the master version of the code.

Compare the Git Workflow (left) and SVN Workflow (right):

  • The processes of getting the current version of the code and editing it are fundamentally the same.

  • Git allows the developer to Stage Changes. However, perhaps the modifications to the code in three out of five files are complete, and ready to be committed, at least locally, while there are significant efforts still needed on the other two. Since changes must be staged in Git prior to committing, the files that are done can be staged and then committed separately, leaving the others still in progress. Uncommitted staged files can still be edited and re-staged (or not) as needed as well; until a change-set is actually committed, everything is still in an in-progress state.

  • Git's Commit Changes is to a local repository, which again means that continued editing can happen, as well as manipulation of local commits, until everything is as it needs to be for the final master repository commit.

  • Both provide the ability to perform a Merge from Master before the final Push or Commit to Master operations. Realistically, this can happen at any point prior to the final commit, but the granularity of Git's stage-then-commit approach lends itself well to doing so in smaller, more manageable chunks, which will often mean that any merges down from the master source code will also be smaller and easier to manage. There's no reason, on the SVN side, why similar periodic merges down can't be performed, it's just easier to remember to do so during a local commit routine during development.