popular DVCS


Very popular because of GitHub.

Starting a new repository/project when you have code ready to commit

Then, after you make more changes

removing a file you don't want

Flowchart of options for undoing a commit, from Git For Teams.

In response to: Make sure you you have a clear branch strategy. See http://www.acquia.com/blog/pragmatic-guide-branch-feature-git-branching-strategy versus http://nvie.com/posts/a-successful-git-branching-model/ as two options. A friend responds: Honestly, these are both perfect examples of the unnecessary complexity that a lot of people are creating with Git. It’s the same issue as with GitFlow - sounds great, but the more integration branches and the more merging you do, the harder it gets to reason about the issues that come up. It’s amazing how much you can do with feature branches, merging in one at a time, rebasing before merge to integrate on the branch, and then just tags for releases. Turn the tags into branches if hot fixes required, and then re-tag, push to production and then merge into master after fixing. Optional long running release branches if your clients keep paying you to support 4 yr old releases, but know your life will suck cherry picking and stashing to reuse small units of code and you copy and tweak security patches across the various long running release branches. Other high points are short running feature branches (if your fb's exceed a week you’re doing it wrong) with feature toggles/feature flags and if necessary branch by abstraction to handle longer running rework.



GitFlow for managing branches.

May'2008: Oliver Steele describes his workflow. I use the index as a checkpoint. When I’m about to make a change that might go awry — when I want to explore some direction that I’m not sure if I can follow through on or even whether it’s a good idea, such as a conceptually demanding refactoring or changing a representation type — I checkpoint my work into the index (by doing add but not commit). If this is the first change I’ve made since my last commit, then I can use the local repository as a checkpoint, but often I’ve got one conceptual change that I’m implementing as a set of little steps. I want to checkpoint after each step, but save the commit until I’ve gotten back to working, tested code... I actually don’t want the fine-grained history in the repository. I might make a checkpoint every five minutes, and many of these checkpoints are pretty low quality; I don’t want them persisted.

Nov'2008: Joseph Perla uses a PyThon script to manage his GiT merges.

WebSeitzWiki: GiT (last edited 2015-03-17 02:47:15 by BillSeitz)

blog comments powered by Disqus