Git

popular DVCS

http://git-scm.com/

Very popular because of GitHub.

Common boo-boos and how to fix them: http://ohshitgit.com/

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

• do git init, then git status to see what it sees, then edit .gitignore
• then git commit -a to add untracked files and get an editor window to enter/save your commit-message.
• then, if you want to make a repository on GitHub to push to, you go to GitHub site to create the repository, then it gives you the command lines to enter to define the remote and push to it.

Then, after you make more changes

• git status to review
• git commit -a to add/commit
  • git commit -a -m "<commit comment>" if you have short commit comment
• git push origin main to push to GitHub (or GitLab)
• git pull origin main to pull from GitHub/Gitlab into your local instance

removing a file you don't want

• To remove the file from the repo and not delete it from the local file system use: git rm --cached file.txt
• but GitHub adds messiness https://help.github.com/articles/remove-sensitive-data

Flowchart of options for undoing a commit, from GitForTeams.

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 Git Flow - 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.

http://reprog.wordpress.com/2010/05/10/git-is-a-harrier-jump-jet-and-not-in-a-good-way/

http://theappleblog.com/2009/03/10/using-git-with-os-x-6-tools-to-get-you-up-and-running/

Git Flow 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.

• he compares to a different style/workflow used by Ryan Tomayko, which works around his habit of working on unrelated chunks of code in the same working copy, then realizing he wants to commit just some of that work (The Case of the Tangled Working Copy.) The Index is also sometimes referred to as The Staging Area, which makes for a much better conceptual label in this case. I tend to think of it as the next patch: you build it up interactively with changes from your working copy and can later review and revise it. When you’re happy with what you have lined up in the staging area, which basically amounts to a diff, you commit it. And because your commits are no longer bound directly to what’s in your working copy, you’re free to stage individual pieces on a file-by-file, hunk-by-hunk basis.

• a commenter compares this to MercurialQueues.

• note that both Oliver's and Ryan's processes focus on a single developer.

Nov'2008: Joseph Perla uses a Python script to manage his Git merges.