4

As a longtime git user, I'm familiar with the following workflow for collaborative projects:

  1. My private repository is where I make local changes.

  2. My public repository is where I push changes that I have made that are ready for others to pull

  3. The project repository is where I pull centrally approved changes from. (It's the one that is managed by gatekeepers.)

In this workflow, I set the "remote" to the project repository, and that's where I pull form. I set the "push remote" to my public repository, and that's where I push to.

As a recently arrived and very happy Magit user, I'm trying to figure out what corresponding workflows work well with Magit. The ability to push to two different remotes (P p and P u) has me baffled. I'm not sure if these two correspond to the remotes that I'm used to, and I'm definitely not accustomed to push to more than one remote.

I have read the section on the two remotes in the Magit manual, but I am not enlightened. Can anyone explain to me what are good workflows for Magit's two remotes? Or point me to an explanation written elsewhere that you like?

3
  • Perhaps the question is a little too broad? but I hope to see interesting answers...
    – YoungFrog
    Jul 3, 2016 at 18:52
  • 1
    You should also read the close by section [magit.vc/manual/magit/… branch config popup) which describes the relevant variables and how to change then from within Magit. I'll consider adding some cross references to the manual and intend to later summarize the steps involved in a proper answer.
    – tarsius
    Aug 1, 2016 at 15:35
  • Fixed link: The branch config popup
    – tarsius
    Aug 1, 2016 at 21:49

1 Answer 1

2

Not sure if it qualifies as good, but these are two workflows I use.

For fork -> master workflow: In this case I have the main remote called origin and a my fork remote which I imaginatively call fork I set the origin as my upstream and the fork as my push:Remote. So my changes are always pushed to my fork and any new changes on upstream are pulled from upstream

For feature-branch -> master workflow: My master branch/epic branch is the upstream here and my feature-branch is the push:Remote branch. Changes are pushed to my feature and upstream changes are pulled from my master/epic branch. The need to push to both remotes usually never appears in my workflow.

It might however be necessary for people who might be part of the organisation itself and have a dedicated branch for that feature in both repos. In this case the dedicated branch in the original repo might receive commits from multiple authors while the same branch on the fork will be used only by one author. In such cases, it might be necessary to push to both remotes.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.