Pull for another Git branch without switching

we recently switched from SVN to Git and at the same time put our live systems into version control (instead of local checkout and file copy to live).

On the project i'm assigned to we all access the same repository and to get changes into live we just git pull there. This causes problems because our webdesigners push changes into the VCS that should not be live yet but should be on the web-testing environment.

When one of the developers now pulls into live he gets all (possibly unfinished) changes.

I thought of switching live to an extra branch and just merge what changed but due to my lack of git knowledge i have no idea how.

My idea is:

Create a new Branch in live (git branch live).
Every time something has to go live
- Pull changes in master (like: git checkout master; git pull; git checkout live)
- git merge master

The problem is that switching to master or pulling everything directly into the live system would cause problems so i'd prefer to avoid this.

Is there any way to do this or is there any better way to manage the Live system (except for training the webbies to not push unfinished stuff).

Morfildur

Posted 2010-07-13T12:07:31.650

Reputation: 795

– Ciro Santilli 新疆改造中心法轮功六四事件 – 2014-08-11T15:29:20.243

1git pull --all will by default not pull master into live, it will pull master and merge it with master, and (if existing on the server) pull live to merge into live. Did you try it? – Tobias Kienzler – 2010-07-16T07:56:05.043

Is your problem caused by a file that was not under version control before branching off live and git-added after modification to master later on? That's what happened to me before, usually it should suffice to temporarily rename that file, or if it isn't needed at live, use git checkout -f to ignore the problem - but make a backup! – Tobias Kienzler – 2010-07-16T10:37:40.680

Answers

109

I was able to pull changes from origin/master into master while working in another branch by using this command:

git fetch origin master:master

Jeff B

Posted 2010-07-13T12:07:31.650

Reputation: 1 689

7Awesome! Exactly what I was looking for - this needs to be much more prominently documented... – Markus Shepherd – 2019-01-14T09:22:05.227

You can find documentation on this here: https://git-scm.com/docs/git-fetch#_examples

– c1moore – 2019-02-08T14:16:00.123

2fetch != pull – D. Kovács – 2019-07-16T07:21:23.333

1This does update the specified branch to the upstream branch. – sean – 2020-01-16T07:15:33.140

1Add -f in case it's not a fast-forward, and you want to force update it: git fetch -f origin master:master – Diego – 2020-01-30T11:37:17.463

You can use git stash before checking out master and pulling, and after checking out live again use git stash pop (or if your git is older, git stash apply and git stash clear assuming you haven't stashed anything else)

Tobias Kienzler

Posted 2010-07-13T12:07:31.650

Reputation: 3 262

@Superole Good point, I edited that one out. Sorry for not having read your comment earlier... – Tobias Kienzler – 2014-09-22T10:53:01.813

7git pull --all will fetch all remotes, but it will still try to merge a branch (or the default branch) into the current branch as well. – mipadi – 2010-07-15T16:21:52.097

@mipadi yes, but only the current branch into itself whithout trying to checkout master and causing the conflict, no? – Tobias Kienzler – 2010-07-16T06:13:18.253

It'll merge whatever branch is configured to be automatically merged into the current branch (if such a branch is configured). – mipadi – 2010-07-16T06:26:37.737

The --all option has nothing to do with branches. – Superole – 2013-07-25T08:51:15.740

1@Superole It's documented as "fetch all remotes", which includes not only multiple repositories, but also branches. Though in hindsight, git fetch --all might have been a better answer – Tobias Kienzler – 2013-07-25T09:02:09.070

2@TobiasKienzler It only instructs git to fetch from all configured remotes. The most common case is to have only one remote named origin. IF you happen to have more than one remote with the same branch as your current, and they are not in a fast-forward relationship to eachother, THEN using the --all option will give you an octopus merge of the different versions of the branch into the current! So my advice is to stay away from --all unless that is what you're after, because in most other cases it will give you nothing. – Superole – 2013-07-25T09:24:02.213

Solve the problem first. They should not be pushing to a branch they have no business pushing to.

What you seem to be asking would be something like

git checkout live
git pull origin master

This will attempt a merge of the remote master and your live branch.

Josh K

Posted 2010-07-13T12:07:31.650

Reputation: 11 754

The problem is that we currently have only one branch and it won't really be possible to change that since everyone is too used to SVN and not willing to learn the advantages of something new. It will only be possible to create a new branch in the live directory. Merging the remote master to the live branch is what i want to avoid as i cannot prevent anyone from pushing debug code, incomplete functions, syntax errors and anything else to the master (I'm just the junior developer after all). Thanks for your suggestion though. – Morfildur – 2010-07-13T14:16:43.857

2@dbeme: You could use tarballs and patches. ;) Unless they're willing to learn git (and it's not hard at all to branch and merge) you're going to have issues. – Josh K – 2010-07-13T15:52:41.280

I recommend that you create a testing git repo for everyone to commit. All repos, including your live website will be clones of the testing repo. In this manner, anyone can push to testing without touching the live web site. When someone needs to update the live site, then you can pull the live site from the git testing repo. This workflow is fairly similar to SVN. For extra flexibility, I recommend using the "live" branch that you describe.

To summarize, everyone's git repo is a clone of the testing repo. The live production site is just a clone of the testing repo as well. Alternatively, testing could be a clone of live prodcution so that a "git push" always moves toward production.

Other options including adding the "live" branch to this arrangement or including a "staging" repo between testing and production. For extra security, I recommend restricting access to the live git repo and forcing people to use a secured script that does the pull to live production.

edgester

Posted 2010-07-13T12:07:31.650

Reputation: 172