Home/ Questions/Q 8876633
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-14T19:15:36+00:00

I try to set up a development environment redmine, that should make it easy

  • 0

I try to set up a development environment “redmine”, that should make it easy for multiple people to develop and maintain our own version of “redmine” including our own features and adjustments. I’m not that familiar with remote branches, but I thought of a config like this:

  • master branch: for deployment
  • dev branch: here we’re developing our new features
  • community branch: this is where i got stuck. I’d like have a branch which is tracking the github community repo of redmine, so that I can say in this branch ‘git checkout v2.0’ and then in the dev branch ‘git merge community’ and solving merge conflicts to due to our own features there. After the next redmine relase I would then checkout v2.1 in the community branch and merge it to the dev branch again and so on …

Of course, I can add a remote to my local branch, pull from the community repo and push to my origin, but then the other people wouldn’t see that and would have to add the community remote repo themself (right?). Is this possible or what is another approach to solve this ‘track a reference project in my own project’ problem?

Thanks

Jan

BTW: my origin repo is created using gitosis.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Whether you are in your dev or community branch (working arena), you will need to use feature branches to develop, edit, and propose your developments so that the can be brought together in a structured manner. That is, you should choose an approach to merging contributions and to promoting them to a higher level. git-scm.com/book/en/Git-Branching-Branching-Workflows

    Do take the time to understand the way remotes work, and that the tracked branches are exact duplicates (up to the point of the common fetch/push), so you cannot plan to have different people’s contributions allocated the the same community branch – that’s why each person should have their own feature branch. You can re-use branch names once the feature is complete.

    git itself (github.com/git/git) has a published sequence of branches:- pu (potential updates), next, and finally master. Before pu there are individual contributor branches (each built from patch series submissions in the git list’s case), and pu can be rewound if/when the maintainer needs. next is more stable. Users fetch updates and rebase their work on the relevant latest release.

    • 0