Difference between revisions of "Git howto"

From Freeplane - free mind mapping and knowledge management software
m
Line 55: Line 55:
  
 
# Find and checkout original source branch (the branch you want to base
 
# Find and checkout original source branch (the branch you want to base
   your work on, usually master) to the local work space:
+
   your work on, '''usually master''') to the local work space:
 
+
#*Using command line git:
Using command line git:
 
 
  # fetches the remote (tracking) branch (may not be necessary)
 
  # fetches the remote (tracking) branch (may not be necessary)
 
  $ git pull  
 
  $ git pull  
 
  $ git checkout <branchname>
 
  $ git checkout <branchname>
 +
#*Using Eclipse/EGit:
 +
#*# ''Team->Pull'' fetches the remote (tracking) branch (may not be necessary)
 +
#*# ''Team->Switch To->New branch...'', select ''Source ref = refs/remotes/origin/<branchname>''
  
Using Eclipse/EGit:
+
# create your own ''local'' branch based on the original branch:
## ''Team->Pull'' fetches the remote (tracking) branch (may not be necessary)
 
## ''Team->Switch To->New branch...'', select ''Source ref = refs/remotes/origin/<branchname>''
 
 
 
# create your own branch based on the original branch:
 
 
  $ git checkout -b <devbranch>
 
  $ git checkout -b <devbranch>
  
# Work with your local branch: add and commit changes:
+
# Work with your local branch: add changes to the ''index'' and commit them:
 +
Please read [http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository chapter 2.2 of the official git book]
 +
in order to get started with working with git locally.
 +
You should understand how to stage and commit changes.
 
#* modify files...
 
#* modify files...
 
#* add the modifications to the ''index'':
 
#* add the modifications to the ''index'':
Line 86: Line 87:
  
 
# Publish ("push") your branch (including the commits you made) so that
 
# Publish ("push") your branch (including the commits you made) so that
others can see it (currently it's best to do this on the command line,
+
others can see (and review!) it. Currently it's best to do this on the
because ''-u'' sets up the tracking branches properly):
+
command line, because ''-u'' sets up the tracking branches properly:
 
  $ git push -u origin <devbranch>
 
  $ git push -u origin <devbranch>
(in eclipse you ''have to configure the remote tracking branch'' and then
+
(When pushing from eclipse you ''have to configure the remote tracking
''Team->Push to Upstream'')
+
branch'' manually!). In any case (tracking branch configured
 +
automatically or manually), ''Team->Push to Upstream'' will push the current
 +
branch to its (configured) remote branch on origin.
  
 
# Follow the cycle:
 
# Follow the cycle:
 
  $ git checkout <devbranch>
 
  $ git checkout <devbranch>
## pull other people's changes:
+
## pull other people's changes on your devbranch:
 
  $ git pull
 
  $ git pull
## resolve conflicts, see Knowledge Base XXX section
+
# you might have to resolve conflicts: (might want to use 'git mergetool'
## create local commits: see Knowledge Base XXX section
+
# or [http://wiki.eclipse.org/EGit/User_Guide#Resolving_a_merge_conflict Eclipse/EGit])
 +
# git will place <<<<<<<<<< and >>>>>>>>>> comments to show the locations of the conflict(s)
 +
for each conflict x:
 +
  1. resolve conflict in ''x'', remove markers
 +
  2. git add x # mark ''x'' as resolved
 +
# commit the conflict resolution(s):
 +
$ git commit [-m message]
 +
## create local commits (you might want to read [])
 
   # in short: git add file; git add file2; git commit
 
   # in short: git add file; git add file2; git commit
 
## merge from master
 
## merge from master
Line 104: Line 114:
 
  $ git push
 
  $ git push
  
When you are done with your branch, and you have completed a code review of
+
# When you are done with your branch, and you have completed a code review of
 
your dev branch, merge it into master (!):
 
your dev branch, merge it into master (!):
 
  $ git checkout master
 
  $ git checkout master
 
  $ git pull
 
  $ git pull
 
  $ git merge <devbranch>
 
  $ git merge <devbranch>
  $ git push orgin master
+
  $ git push origin master
  
 
== Knowledge Base ==
 
== Knowledge Base ==
TODO: intro
+
This section contains useful information for working with git, including stuff
 +
like checking that tracking branches are set up correctly, details about working
 +
with branches, undoing commits/reverting files, and a bit more.
  
 
=== Installation ===
 
=== Installation ===
Line 268: Line 280:
 
TODO: how to rename the remote tracking branch => difficult!!
 
TODO: how to rename the remote tracking branch => difficult!!
  
==== How to merge branches ====
+
==== How to merge local branches ====
  
 
  $ git checkout <destination_branch>
 
  $ git checkout <destination_branch>
 
  $ git merge <source_branch>
 
  $ git merge <source_branch>
 +
 +
  
 
If you want to abort a merge (revert the working directory to the state
 
If you want to abort a merge (revert the working directory to the state
Line 284: Line 298:
 
* Team->Merge... and choose <source_branch>
 
* Team->Merge... and choose <source_branch>
  
TODO: how to make eclipse update the list of branches etc. (e.g. if a
+
In Eclipse, you may have to refresh all projects (F5) if a branch
branch has been deleted from the command line)??
+
has been added/modified/deleted via the command line.
  
 
===== Fast-Forward Merges (merge-nodes) =====
 
===== Fast-Forward Merges (merge-nodes) =====

Revision as of 18:44, 30 August 2012

Working with freeplane's git repository

Quickstarter Guide

You can (and probably want to) use eclipse for most operations. I try to explain this in each section, but it is a good idea to read the EGit documentation.

NOTE: Some instructions cover only the temporary freeplane repository on github, it will need to be adapted to the sourceforge hosting service.

There is a fun Google Tech Talk by Linus Torvalds on git.

Installation / Configuration

Install git as described here. You probably want to use the latest Eclipse (use Eclipse for RCP and RAP Developers) with EGit (Eclipse-git) plugin (integrated by default).

The author details (which will be recorded for each changeset) can be set globally:

$ git config --global user.name "<Firstname> <Lastname>"
$ git config --global user.email "<email address>"

Initial checkout ("clone")

Create directory for git repositories:

$ cd $HOME
$ mkdir git
$ cd git

Create a local copy of the (whole!) git repository by cloning (git-speak for "checking out"): $ git clone https://github.com/fnatter/freeplane-git.git freeplane

This will create a local copy of all history and all branches. Therefore it is possible to develop and make commits offline and only connect for the purpose of getting changes from other devs ("pull") or sending your commits to a remote branch ("push").

In Eclipse/EGit you have to select the clone option in the Git Repositories View on a repository with the above URL, then enter credentials, choose all branches (!), then accept the defaults or choose a different location (for the local copy of the repo) check import all existing projects after clone finishes and be patient (should take <10 minutes). Afterwards, delete the freeplane_mac project unless you're on Mac, and close the freeplane_ant project. Finally, run the ant-build in freeplane_framework.

Working with branches

Freeplane branches sometimes have prefixes separated from the name by a '/', i.e. docear/trunk.

Here are the basic steps for working with branches:

  1. Find and checkout original source branch (the branch you want to base
 your work on, usually master) to the local work space:
    • Using command line git:
# fetches the remote (tracking) branch (may not be necessary)
$ git pull 
$ git checkout <branchname>
    • Using Eclipse/EGit:
      1. Team->Pull fetches the remote (tracking) branch (may not be necessary)
      2. Team->Switch To->New branch..., select Source ref = refs/remotes/origin/<branchname>
  1. create your own local branch based on the original branch:
$ git checkout -b <devbranch>
  1. Work with your local branch: add changes to the index and commit them:

Please read chapter 2.2 of the official git book in order to get started with working with git locally. You should understand how to stage and commit changes.

    • modify files...
    • add the modifications to the index:
$ git add foo.java # (Team->Add to index in eclipse)
    • create a commit from the changes in the index:
$ git commit [-m message] # (Team->Commit in eclipse)

(if you omit -m then you will be prompted for a commit message)

    • create more commits, this is all done locally!
  1. setup git so that only the current "upstream" branch gets pulled/pushed

(instead of pushing all branches that have an upstream tracking branch which can be confusing!):

$ git config push.default tracking

Note: this option is ignored by current EGit. On EGit you get the same behavior by selecting Team->Push To Upstream.

  1. Publish ("push") your branch (including the commits you made) so that

others can see (and review!) it. Currently it's best to do this on the command line, because -u sets up the tracking branches properly:

$ git push -u origin <devbranch>

(When pushing from eclipse you have to configure the remote tracking branch manually!). In any case (tracking branch configured automatically or manually), Team->Push to Upstream will push the current branch to its (configured) remote branch on origin.

  1. Follow the cycle:
$ git checkout <devbranch>
    1. pull other people's changes on your devbranch:
$ git pull
# you might have to resolve conflicts: (might want to use 'git mergetool'
# or Eclipse/EGit)
# git will place <<<<<<<<<< and >>>>>>>>>> comments to show the locations of the conflict(s)
for each conflict x:
  1. resolve conflict in x, remove markers
  2. git add x # mark x as resolved
# commit the conflict resolution(s):
$ git commit [-m message]
    1. create local commits (you might want to read [])
  # in short: git add file; git add file2; git commit
    1. merge from master
$ git pull origin master
    1. push merge with master (run with --dry-run first!)
$ git push
  1. When you are done with your branch, and you have completed a code review of

your dev branch, merge it into master (!):

$ git checkout master
$ git pull
$ git merge <devbranch>
$ git push origin master

Knowledge Base

This section contains useful information for working with git, including stuff like checking that tracking branches are set up correctly, details about working with branches, undoing commits/reverting files, and a bit more.

Installation

This chapter of the git book has some info about installing git from source or binary form on Linux/Mac OS X/Windows.

The author details (which will be recorded for each changeset) can be set globally:

$ git config --global user.name "Felix Natter"
$ git config --global user.email "fnatter@gmx.net"

Checkout

Checking out is termed cloning in git speak:

$ cd ~
$ mkdir git
$ cd git
$ git clone https://github.com/fnatter/freeplane-git.git freeplane

If you want/have read-only access, use this as the last command:

$ git clone git://github.com/fnatter/freeplane-git.git freeplane

However, this will only configure the master branch (named trunk in other VCS's such as svn) locally:

$ git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/docear_trunk
  remotes/origin/master

In order to check out a branch (which is simply a reference to a commit) that currently only exists remotely (the remotes/origin/* references are called remote tracking branches), simply switch to that branch:

$ git checkout docear_trunk

This can be done more easily using Eclipse. This page also describes how to import a repository into eclipse.

Basic workflow with one branch

Please read the chapter on git basics in order to get started with git. You should understand how to stage and commit changes.

In the following there is a simplified list of steps for working with git. Please read the following sections!

  • clone repo (see above)
  • switch to the desired branch (see next section for more about branches!)
$ git checkout <branch> # Eclipse: Team->Switch to
  • make sure you have the latest version of the branch (pull = fetch + merge)
$ git pull

(resolve and commit any merge conflicts)

  • modify files...
  • add the modifications to the index:
$ git add foo.java # (Team->Add to index in eclipse)
  • create a commit from the changes in the index:
$ git commit [-m message]

(if you omit -m then you will be prompted for a commit message)

  • create more commits, this is all done locally!
  • push changesets (commits) to sourceforge:
$ git push

(you might have to pull before the push if someone has pushed to the branch after you pulled!)

Using Tags

Show all tags:

$ git tag

Search for a tag:

$ git tag -l "release-1.1*"

Show information about a tag:

$ git show release-1.1.2

Define a tag locally:

$ git tag -a <tagname>
# (an editor opens for you to add a description)

Tags are not automatically transferred when doing a git push, you have to push individually:

$ git push origin <tagname>

or push all tags:

$ git push --tags origin

You might need a

$ git pull --tags

to get all tags. See git-fetch(1) for situations when you will need this (rarely).

TODO: sign tags?

Working with branches

Branches are very central to git. Do not hesitate to create feature, team and (of course) maintenance branches.

You probably want set push.default to tracking or upstream which makes sure that only the current branch is pushed to its upstream branch (and NOT all configured branches): Note: this option is ignored by current EGit. On EGit you get the same behavior by selecting Team->Push To Upstream.

$ git config push.default tracking

(you can equivalently set this to upstream in recent git versions).

Switch to another branch

$ git checkout <branchname>

(Team->Switch To->... in Eclipse)

How to create a new branch

New (feature) branches should be named <user>/<feature> or (if several devs work on a feature): <feature>.

# commit everything that should go into the new branch
$ git status
$ git add <file>
[...]
$ git commit -m "my changes"
# create new branch locally
$ git checkout -b <newbranch>

# check commit log to see that above commit is in there
$ git log

# new branch must be visible and selected:
$ git branch -a  
# (make sure that the name of the new branch is correct! it is diffcult/impossible
#  to rename published branches!)

# create branch remotely, use -u to automatically configure upstream location
$ git push -u origin <newbranch>
# this should output something like this:
  Branch <newbranch> set up to track remote branch <newbranch> from origin.
# (Note: -u is important if you want to use git pull/push without
  specifying a remote/refspec)
# remote branch of <newbranch> must be visible:
$ git branch -a

So the short story is:

$ git checkout -b <newbranch>
$ git push -u origin <newbranch>

Rename a local branch

$ git branch -m <old-branch-name> <new-branch-name>

TODO: how to rename the remote tracking branch => difficult!!

How to merge local branches

$ git checkout <destination_branch>
$ git merge <source_branch>


If you want to abort a merge (revert the working directory to the state before the merge command), do this:

$ git reset --hard

(WARNING: this will remove all uncommitted changes!!)

In eclipse, this can be achieved by:

  • Team->Switch To and choose <destination_branch>
  • Team->Merge... and choose <source_branch>

In Eclipse, you may have to refresh all projects (F5) if a branch has been added/modified/deleted via the command line.

Fast-Forward Merges (merge-nodes)

Often the creation of a merge commit (merge node) is not necessary, and git merge uses a fast-forward merge, omitting the merge node:

$ git merge foo
Updating 9e9a63a..732b657
Fast-forward
 testfoo.txt |    1 +
 1 file changed, 1 insertion(+)
 create mode 100644 testfoo.txt

results in:

* 732b657 commit in branch foo
* [...]

Using the option --no-ff you can force git to create a merge node even if isn't absolutely necessary (non-fast-forward merge):

$ git merge --no-ff foo2
Merge made by the 'recursive' strategy.
 testfoo2.txt |    1 +
 1 file changed, 1 insertion(+)
 create mode 100644 testfoo2.txt

which will result in:

*   3890bc8 (HEAD, master) Merge branch 'foo2'
|\  
| * 6bc24c5 (foo2) commit on foo2
|/  
* 
* [...]

This is useful when merging feature branches because it clearly shows the integration of a new feature. On the other hand, many merge nodes make the commit graph less readable.

Merge master->dev-branch
$ git checkout <devbranch>
$ git merge master
Merge dev-branch->master
$ git checkout master
$ git merge <devbranch>

How to remove a branch

# remove branch locally
# (use -D instead if you want to delete a branch that is not fully merged into HEAD!)
$ git branch -d <branchname>

If you accidentally deleted a (local) branch, you can recover it by starting a new branch from the location that git branch -d <branchname> echoed (or by searching for the last commit on that branch in git reflog):

$ git branch -D foo
Deleted branch foo (was 732b657).
$ git branch foo 732b657

(remember that branches are simply pointers to commits)

Warning: this only works if the delete was quite recent as orphaned commits will be deleted after some time!

Delete a remote branch(!):

$ git push origin --delete <branchname>

Now the local and the remote tracking branch should be gone:

$ git branch -a
  docear_trunk
* master
  remotes/origin/docear_trunk
  remotes/origin/master

NOTE: The stale branch will still exist in other checkouts, until you do a:

$ git remote prune origin

in that other checkout. TODO: but it still exists there as a local branch!

Check whether your branches are set up correctly

Make sure your branches are set up correctly for push/pull:

$ git remote show origin
* remote origin
  Fetch URL: https://github.com/fnatter/freeplane-git.git
  Push  URL: https://github.com/fnatter/freeplane-git.git
  HEAD branch: master
  Remote branches:
    docear_trunk tracked
    master       tracked
  Local branches configured for 'git pull':
    docear_trunk merges with remote docear_trunk
    master       merges with remote master
  Local refs configured for 'git push':
    docear_trunk pushes to docear_trunk (up to date)
    master       pushes to master       (up to date)

Importing a remote branch

Using command line git:

$ git pull # fetches the remote (tracking) branch
$ git checkout <branchname>

Using Eclipse/EGit:

  • Team->Pull fetches the remote (tracking) branch
  • Team->Switch To->New branch..., select Source ref = refs/remotes/origin/<name>

General workflow

Create a dev branch (see section on creating branches above).

Work on your feature branch

# switch to feature branch
$ git checkout <feature>
# fetch and merge changes (in case another dev works on this)
$ git pull
# you might have to resolve conflicts: (might want to use 'git mergetool'
# or Eclipse/EGit)
for each conflict x:
  1. resolve conflict in x, remove markers
  2. git add x # mark as resolved
# commit the conflict resolution(s)
$ git commit
$ git add ...
$ git commit
[...]
# This will push commits to the remote branch that is tracked
# make sure that push.default=tracking|upstream (see above),
# otherwise other branches will be pushed as well!
$ git push [--dry-run]

Merging

Merge master -> <devbranch> (see section on merging above) every once-in-a-while.

After a final code review (on your dev branch), merge <devbranch> -> master (see section on merging above).

Miscellaneous

Revert (reset) files

git checkout <filename>

Revert all files in working copy (!):

git reset --hard

Undoing/editing commits

TODO: how to remove/edit a commit locally using rebase.

Undoing a commit that is already pushed

Use git revert <commit-hash>, like this:

$ git revert b1e9b4c9755b091f95aaa3035aca04dcb02ec1fd

This will generate an inverse commit, it will not remove the original commit:

* 171881e (HEAD, master) Revert "a simple commit"
* b1e9b4c a simple commit