summaryrefslogtreecommitdiffstats
path: root/doc/GITGUIDE
blob: 41b4059a3c2cd34a2d0b399a00fb6e7a05b24f03 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
Guide for using GIT

Working with Git is significantly different that working with SVN. In particular, although similar, git pull is not svn update, git push is not svn commit, and git add is not svn add. If you are a SVN user, be sure to read the man pages for the different git commands.

The following workflow is recommended by Evan and is the guideline for contributing code to Rubinius.

   1.

      Create a local working copy of the source code (we did this earlier.)

      # See above for the exact invocation

   2.

      Change to the newly created directory that contains the local working copy. (Substitute the directory if you created it with a different name, obviously.)

      cd code

   3.

      Create a branch for your work. This will make a copy of the current branch (master) and name it "new_feature". Now you can work in this new branch without breaking the main one.

      git checkout -b new_feature

   4.

      Edit the code and test your changes. Then commit to your local working copy

      git commit -a

   5.

      When you are ready to send your local changes back to the Rubinius repository, you first need to ensure that your local copy is up-to-date. First, ensure you have committed your local changes. Then switch from your topic branch to the master branch.

      git checkout master

   6.

      Update your local copy with changes from the Rubinius repository

      git pull

   7.

      Switch back to your topic branch and integrate any new changes. The git rebase command will save your changes away, update the topic branch, and then reapply them.

      git checkout new_feature
      git rebase master

      Warning! If you are sharing a branch, you must use:

      git merge master

      Rebase causes the commit layout to change and will confuse anyone you've shared this branch with.

   8.

      If there are conflicts applying your changes during the git rebase command, fix them and use the following to finish applying them

      git rebase --continue

   9.

      Now, switch back to the master branch and merge your changes from the topic branch

      git checkout master
      git merge new_feature

  10.

      You might want to check that your commits ended up as you intended. To do so, you can have a look at the log

      git log

  11.

      Get your changes in the main repository. If you have commit rights, you can just use the git push command. Otherwise, see the section below for information on creating a set of patches to send.

      git push

  12.

      At this point, you can delete the branch if you like.

      git branch -d new_feature

When you're familiar with the workflow, you can use the rake tasks to help you out. For example, rake git will fetch the latest code from remote repo, rebase the current branch to master, fast-forward the changes to master and push the commits to the remote. This saves a lot of typing. Check rake -T git for all the git related tasks.

Taken from: http://rubinius.lighthouseapp.com/projects/5089/using-git