Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Since git is used by Linux kernel developers it's easily available on most modern distributions. If you use, say, Fedora, run this (as root) to install the git distributed version control system:

Panelcode
yum install git*

 

Note

...

This is a crude way to perform such an installation, and will install many possibly unwanted packages.

More elegant is to install just what is sought, to avoid over-filling a development environment with un-needed and potentially unwanted packages:

Panelcode
yum install git

If you are using CentOS you may wish to add and temporarily enable the EPEL repository before installing git via yum. More information here Alternatively, more current git RPM packages are available here from the primary 'upstream' for the development of git

Branching

Let's develop a new 'super' features. You should never write new code develop new code against the 'master' branch. In the mirror source code repository, 'master' is used only to provide a record of the former subversion mainline.

To write new code, create a new branch and check it out. (Since the branch is local, creating a new branch takes only a second or two).

Panelcode
git checkout -b super-feature

Option -b means that you are creating a new branch and checking it out. If you later want to switch to this branch, run the same command without a -b option. 'git checkout' is similar to 'svn switch' (not to 'svn checkout').

You can make some changes now

...

now using your favorite editor

Once you happy with your changes, and they pass your local testing, commit them. You'll be only checking in to your local git repository, so commit early, commit often.

Panelcode
git commit -a

Option -a means that you want to add all changed files to the commit. Alternatively you can run

Code Block
git add

and add the files one by one, or on a directory by directory bases. Differently than in subversion, when using git you must tell it explicitly which files you are committing.

...

Before you generate a patch against 'master' release-4.6, it's a good idea to rebase master release-4.6 against the git mainline and then rebase your branch against a fresh copy of: master

...

release-4.6

  • Switch to active development release-4.6 branch
Code Block
git checkout release-4.6

Retrieve the latest commits from

...

git repo

git checkout super-feature # switch to your feature branch
Code Block
git
rebase master # rebase your branch against the active development master
 svn rebase

 

Git is quite efficient at merging your changes during rebase. Check here about how to resolve conflicts if you have any (not sure where "here" was meant to be, but 'git mergetool' is useful).
Now you're ready to generate the patches.

...