Git Training

[jburel]

Switch to Git Thursday 20/01
Some training and how to use git required.
Friday morning on TS to define how we want to use it??

Topics to include:

• use of git-flow
• use of remotes
• whitespace issues
• hudson integration
  • "After your first commit to git, you may need to go to the "People" tab and re-enter your email/jabber addresses *unless* you use your LDAP name as your git name (jmoore instead of "Josh Moore") See ​http://issues.hudson-ci.org/browse/HUDSON-7156

---

Training sessions:

• First session 21/01/11
• Second session 27/01/11 9.30am UK

[jburel]

first session: 21/01.

Commands from training
Getting started

---

git clone ​https://github.com/nvie/gitflow.git
cd gitflow; git submodule init; git submodule update; export PATH=$PATH:pwd

Nice coloring in ~/.gitconfig or ome/.git/config:

[color]

branch = auto
diff = auto
pager = true
status = auto
sh = auto

Typical workflow

---

git status # See if you have any changes

git flow feature start foo
# Same as:
# git checkout -b feature/foo develop

touch SOMEFILE
git add SOMEFILE
# or: git commit -a

git commit -m "MESSAGE"

# Repeat

git flow feature finish foo
# Same as:
# git checkout develop
# git merge feature/foo
# git branch -d feature/foo

# Get any changes from necromancer
git pull --ff-only origin develop
# If this fails, let's talk!

# If it's good send it to necromancer
# i.e. "commit to trunk"
git push origin develop

Sharing

---

# Chris will set up some kind of private developer space for the team
# for backups and internal/hidden sharing
git remote team ​ssh://git.openmicroscopy.org/home/git/team.git

# Create new name for others to see
git push team new_feature_name:refs/heads/new_feature_name

# Get changes from others
git pull --ff-only team new_feature_name

# Send changes to others
git push team new_feature_name

# Now go back to your regular work
# and finish the feature and commit
# to develop when ready.

# Once the branch is no longer needed, remove the name
git push team :refs/heads/new_feature_name

Rules we've discussed

---

• ​http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
• fast-forward only merges on git.openmicroscopy.org (ome.git and team.git)
• don't commit to master, 4_2, or 4_1 -- that's like tagging a release
• for any thing more than single commits, create a feature.
• Did I forget any? More sure to come...

Next steps

---

Try it out. We'll cover how to handle keeping develop and dev_4_2 in sync (via "cherry-pick"ing) soon. Don't hesitate to speak up.
~Josh.

[jmoore]

Just a heads up in preparation for the discussion on maintaining 4.3+4.2:

~/code/git $ git cherry -v ome/dev_4_2 ome/develop master_START
+ ca157bb094558e66fd5756c830a29b8e46b17d7b Adding to .gitignore as test (See #3949)
+ 0d3e9a64ff57301cee1b6db3faa743aaa32d97f7 Fixing whitespace in licenses/README as test (See #3949)
- 70b560fdb0c1b42af7206ef421860471f3e9f8a6 Moving OMERO.sh to git (See #3934)
+ a9c4be23f875c2c6bca501b98823a8e207303307 Removing unused policy file as test (See #3950)
- dd0ab1bd1788cad2e6782eb71ebcfdba4d93275f Temporary fix for test-compile with insight (See #3940)
- d57e6df76cb089ed983c30a3f6d0780c0de97207 Adding coalesce for restrictive RDBMs (Fix #3885)
+ dab06787eca53d7bfca9b41026686fe970eb7984 refactor code to display exception in tool tip (close #3967)
+ d9c2292bb2ece95943308c0f952df3e65ebc5eea Images_From_ROIs.py script returns a Dataset if one is created - See #3966

The items with plus signs need to be cherry picked. The minus signs have already been.

[jmoore]

Two sessions finished during this iteration. Latest notes:

Dealing with branches/merges/mistakes:
=====================================

git reset --hard 5020f4 # WARNING!! git status should be empty
git rebase -i HEAD # Rewrite last 2 commits
git cherry-pick # Just don't let duplicates sneak in

# Very useful for maintaining 4.2

We also looked at merging a feature branch multiple times, and
how you have to keep all your feature branches properly rebased.

Policies/Configuration?:
======================

We discussed a bit the need to have enough information in
your commits. Either keeping adding ticket numbers in all
your commits, or possibly use "git merge --no-ff"

​http://stackoverflow.com/questions/2500296/can-i-make-fast-forwarding-be-off-by-default-in-git
git config branch.develop.mergeoptions "--no-ff"

Though as Chris pointed out, there's some (a lot!) of debate
on this.

Other things:
============
git config alias.graph "log --date-order --graph --decorate --oneline"
git reflog

[jmoore]

Dealing with branches/merges/mistakes:
=====================================

git reset --hard 5020f4      # WARNING!! git status should be empty
git rebase -i HEAD^^         # Rewrite last 2 commits
git cherry-pick              # Just don't let duplicates sneak in
                            # Very useful for maintaining 4.2

We also looked at merging a feature branch multiple times, and
how you have to keep all your feature branches properly rebased.

Policies/Configuration:
======================

We discussed a bit the need to have enough information in
your commits. Either keeping adding ticket numbers in all
your commits, or possibly use "git merge --no-ff"

 http://stackoverflow.com/questions/2500296/can-i-make-fast-forwarding-be-off-by-default-in-git
 git config branch.develop.mergeoptions  "--no-ff"

Though as Chris pointed out, there's some (a lot!) of debate
on this.


Other things:
============
git config alias.graph "log --date-order --graph --decorate --oneline"
git reflog