4

For git, "A successful Git branching model" gives great advice.

I want to give Fossil a shot, and it seems to be very compatible with git (the most striking difference (of SCM features) I noticed so far is the denial of git-rebase's functionality, partly mitigated by the shunning feature). So can the git workflow be simply adapted 1:1 or is a different workflow more recommendable? E.g. how can the additional features of fossil (integrated Issue Tracker and Wiki) be integrated?


(source: nvie.com)

Glorfindel
  • 21,988
  • 13
  • 81
  • 109
Tobias Kienzler
  • 25,759
  • 22
  • 127
  • 221
  • 1
    FWIW, I use that sort of pattern in my fossil-hosted projects (and I'm not currently using either the issue tracker or the wiki). The major workflow difference is that fossil doesn't have anything like the `git rebase` operation (because its developers think it _shouldn't_ have that). – Donal Fellows Nov 15 '12 at 05:34
  • So do you have a bunch of typo and quick fix commits in the hostory? Or do you have some other way to clean up commits? Or do you not commit until the code is completely ready, which seems risky to me? – Thayne Jul 04 '21 at 04:22

1 Answers1

1

As I know, fossil use auto-sync mode to reduce the the branch which possible make developer busy.

So every developer setup auto-sync with main backup repository. Then when want to enhance a feature, just set a branch on check in. When the feature workable, merge back to trunk.

If you want to let all developers shared the same branches tree for review purpose add --private option when clone.

So, in the picture which you gave. We can treat 'develop' as 'trunk'. And all others as --branch option of commit.

When we wan to develop under one branch, just 'fossil update

Daniel YC Lin
  • 15,050
  • 18
  • 63
  • 96