How to keep track of origin/master in my dev git branch
Asked Answered
D

2

6

I am new to git and I would like to know how to tackle a very basic scenario. I read so many posts on stackoverflow about git but still can't figure out the answer.

We have an origin/master remote branch that everybody is working on. I have a featureA that I want to implement and might take time to develop. Meanwhile, people might be checking in code to the origin/master.

What would my workflow look like and how should I go about setting up my git branch, given the following needs:

  1. I want to be able to commit code changes to my branch and push them to a remote branch on our server so I don't loose the changes in case my computer is fried.

  2. I want to keep my branch up-to-date with the master branch.

  3. I want to minimize regular merges. I like to concept of git rebase so I would like to maximize its use and hence fast-forward merges.

  4. At some point we will have to merge my branch FeatureA into origin/master.

Summarizing:

How do I setup a branch that pulls from origin/master but pushes to origin/MY-BRANCH?

What would my workflow look like?

UPDATE:

Thank you @will-pragnell! What is the difference between your solution and the following.

This page on github suggest:

https://github.com/diaspora/diaspora/wiki/Git-Workflow

In order to get the latest updates from the development trunk do a one-time setup to establish the main GitHub repo as a remote by entering:

$ git remote add upstream git://github.com/diaspora/diaspora.git
$ git fetch upstream
$ git checkout master
$ git rebase upstream/master
$ git checkout 100-retweet-bugfix

[make sure all is committed as necessary in branch]

$ git rebase master
Deepfry answered 20/1, 2012 at 9:57 Comment(0)
E
5

You probably don't want a branch that pulls from master and pushes to your own branch. What you want is to pull from master on to your local master, handle rebasing locally, and then push to your own remote branch for the feature. This is a fairly standard workflow and gives you complete control and a minimal amount of merging. Personally I would do it like this:

Create a new local branch

git checkout -b myFeature

Push that to a new remote branch (see this stackoverflow question if you need more info on this step)

git push origin myFeature

Now you can work away hapily on the myFeature branch, pushing using the above command when you need to without messing up the master branch. When you need to get hold of commits that others have done on master, you can do so like this:

git checkout master
git pull (this will just fast-forward if you don't make any local changes to master)
git checkout myFeature
git rebase master

When your feature is finished, you can the merge or rebase your branch back in to master so that everyone else gets your new feature. Like this:

git checkout master
git merge myFeature
git push origin master
Erickson answered 20/1, 2012 at 10:58 Comment(4)
Thank you @will-Pragnell! My question is updated with the following: What is the difference between ur solution and the following. This page on github suggest: github.com/diaspora/diaspora/wiki/Git-Workflow In order to get the latest updates from the development trunk do a one-time setup to establish the main GitHub repo as a remote by entering: $git remote add upstream git://github.com/diaspora/diaspora.git, $git fetch upstream, $git checkout master, $git rebase upstream/master, $git checkout 100-retweet-bugfix, [make sure all is committed as necessary in branch], $git rebase masterDeepfry
after doing: git checkout master git merge myFeature git push origin master I got ` ! [rejected] multi-senders -> multi-senders (non-fast-forward) error: failed to push some refs to 'ssh://xxx' To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes (e.g. 'git pull') before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details.`Deepfry
Regarding your second comment - did you rebase onto master before you tried to merge? (Will have a look at your first comment a little later when I have a spare moment - sorry, super busy here!)Erickson
It looks like the guide on git hub has an added step of adding a new remote called 'upstream'. In my guide I've assumed you don't need to do this based on what you said in your question: "We have an origin/master remote branch that everybody is working on." I've not yet used github but I think this is something that's specific to the use case presented in that guide.Erickson
I
0

git checkout -b FeatureA ( create and checkout branch )
git push origin FeatureA ( push your newly created branch to origin )

Work on new branch FeatureA. You do not want frequent merges then to rebase

git rebase origin  

In future whenever you want to merge into master.

git checkout master  
git merge FeatureA  
git push origin master  
Interdependent answered 20/1, 2012 at 11:42 Comment(1)
Anytime I do 'git rebase master' then 'git push origin/multi-senders' I get the following To ssh:xxx ! [rejected] multi-senders -> multi-senders (non-fast-forward) error: failed to push some refs to 'ssh://xxx' To prevent you from losing history, non-fast-forward updates were rejected. Merge the remote changes (e.g. 'git pull') before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details.Deepfry

© 2022 - 2024 — McMap. All rights reserved.