Synfig git fundamentals

Hi to all,
i would fix my ideas about branches on synfig and its git workflow
Let’s start :slight_smile:


the branches are:

[kinder@localhost synfig]$ git branch -r
  origin/HEAD -> origin/master
  • master is the stable branch
  • eldruin_new_cairo_core/eldruin_transformation_matrix/genete_cairo_core/genete_new_cairo_core are username_feature branches where new features are coded and then merged to master
  • 0.64.2/0.64.x/1.0.x are the branches of the old releases

So what is origin/dev-1.0.1 branch?

To contribute i should:

  • fork synfig on github
  • clone my forked repo (origin for convention) in my local machine
  • add original synfig repo (upstream for convention) with git remote add upstream …

At this point i have (in my local machine) all ten upstream branches, all ten origin branches and one master local branch.
So i starts coding in local master and when i have finished:

  • git add
  • git commit

My local master is now updated.
To synch local with upstream i should

  • git fetch upstream (update all branches in upstream)
  • git checkout master
  • git merge upstream/master | git rebase upstream/master

So my local master should be synchronized with original synfig repo (upstream).
Now i can update my forked repo on github (origin)

  • git push origin master
  • make a pull request on github

Now my new features are in local master and origin master, if i want to add them for example in old releases like origin/0.64.2 i should:

  • git fetch upstream
  • git checkout -b 0.64.2 upstream/0.64.2 (create my local copy of original 0.64.2)
  • readd my new feature in local 0.64.2 (git add; git commit)
  • git push origin/0.64.2

Is correct this workflow :confused: ?


It’s the bug fix branch for the 1.0.x version. Last stable from this branch is 1.0.2. This is where a 1.0.3 could be baked.

Looking at the commit history you could see near last 15/07/23 one is 1.0.1 release. This branch should be only a tag (

Nop, it’s recommanded to create a branch from updated master for hosting your contribution

$ git checkout master $ git fetch upstream $ git rebase upstream/master $ git branch your_branch $ git checkout your_branch
Nota : git checkout -b your_branch is a shortcut for last two commands

A nice name for your_branch help the brain to work less :wink: It’s also useful for the rest of the universe who take a look to your contributions .
And so for the rest of you workflow : master --> your_branch. Nota : if it’s a minor fix (typo / doxygen code documentation / … for example) you can do it from your origin master.

For sure, before you send to github, check the final integration of your contribution and the actual master code still are stable.

Yep could do it this way. Or let the leader (actually Konstantin Dimitriev aka Zelgadis) taking care of that.

I think it’s all …

Another link :Git : contribution workflow i have posted here.

All clear, thanks djay :wink: :wink: