m (Adamwill moved page Talk:Using Fedora GIT to Talk:Package maintenance guide: This is a better name. No-one else on earth capitalizes "git", and git is an implementation detail. This is about to get a dump of stuff from the 'package update HOWTO...) |
|||
| Line 15: | Line 15: | ||
git mergetool | git mergetool | ||
</code> | </code> | ||
== Working with branches == | |||
Currently we follow a ''merging-down'' strategy meaning fixes go in master and get merged down into <nowiki>f<X></nowiki> and <nowiki>f<X-1></nowiki> etc. | |||
However, this strategy can be confusing looking at the changelog of the spec file, e.g. when a rebuild happened in rawhide, which didn't take place in f<X>, but the changelog still has that entry on the f<X> branch. | |||
Of course, one could cherry pick a single commit, e.g. a version bump, down to a branch, but that would change the hashsum of the commit and hence "git branch --contains <HASH>" doesn't work anymore. | |||
Alternatively, one could follow a workflow as described in gitworkflows(7), like many project incl. FFmpeg do, which would apply the version bump on the lowest branch and merging it up to master. | |||
<code> | |||
fedpkg switch-branch f25 | |||
git commit -m "version bump" | |||
fedpkg switch-branch master | |||
git merge | |||
</code> | |||
where the last step might include some conflict resolving. | |||
Revision as of 22:29, 10 February 2017
Merging (request for discussion and inclusion on the main page)
Merging issues can be made much easier to solve with the following instructions:
yum install meld
Then configure git to use meld for merging:
git config --global merge.tool meld
Then, when merge conflicts occur, it can be resolved in a very nice, graphical interface by using the command:
git mergetool
Working with branches
Currently we follow a merging-down strategy meaning fixes go in master and get merged down into f<X> and f<X-1> etc. However, this strategy can be confusing looking at the changelog of the spec file, e.g. when a rebuild happened in rawhide, which didn't take place in f<X>, but the changelog still has that entry on the f<X> branch. Of course, one could cherry pick a single commit, e.g. a version bump, down to a branch, but that would change the hashsum of the commit and hence "git branch --contains <HASH>" doesn't work anymore.
Alternatively, one could follow a workflow as described in gitworkflows(7), like many project incl. FFmpeg do, which would apply the version bump on the lowest branch and merging it up to master.
fedpkg switch-branch f25
git commit -m "version bump"
fedpkg switch-branch master
git merge
where the last step might include some conflict resolving.