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