From Fedora Project Wiki

(→‎Working with branches: FFmpeg actually follows the branch and cherry-pick from master approach, not merge up.)
 
(2 intermediate revisions by 2 users not shown)
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 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.

Latest revision as of 20:56, 12 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 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.