We have a main trunk branch and various other feature and personal branches in a bazaar repostiry. We'd like to keep personal branches in sync with the main trunk but allow each developer to remotely call 'pull' on his remote branch so that the remote is in sync with trunk. The developer then branches his personal branch to his machine, edits, commits (or branches additional branches as needed) and then can push the updates to his personal branch, or if the remote branch has updated - merge it (and thus latest trunk) with his working local branch before he pushes that up.
Later on a gatekeeper can pull the personal branches and merge them into the main trunk.
How can I issue such a remote pull request so that the remote branch pulls from trunk?
I think the step of pulling from the trunk to remote user branches is simply pointless.
In any case the pull operation is defined only for local branches. Triggering a pull in a remote branch would mean ssh server bzr pull -d path/to/branch, in other words you always need shell access (local or remote) to the branch you want to pull to.
Pulling to remote user branches seems pointless because the users could pull directly to their local branches instead. Your setup could be reworked like this:
Have a main trunk branch and various other feature and personal
branches in a bazaar repository. The developer then branches from
trunk to his machine, edits, commits (or branches additional branches
as needed) and then can push the branch to his personal remote branch.
Later on a gatekeeper can pull the personal branches and merge them
into the main trunk.
At any point, the developers could merge from the trunk to get new changes that have been merged by the gatekeeper since they started working in their local branches.
Comment if you think this would not accomplish the same.
If you really want to update remote branches without shell access, push is the only way. You could do an automated push on all remote personal branches triggered by new revisions in the trunk, but as explained above it would be pointless. If the users want to sync from the trunk, they should just sync from the trunk.
Related
I am having hard time devising a workflow for github now that we have swtiched over from clearcase ucm to github.
In clearcase ucm, I just had a development stream and an integration stream. all
developers check in under dev stream which finally gets merged to int stream and baselined.
How can the same thing be done in github?
A stream in ClearCase is a akin to a Git branch in order for multiple developers to collaborate to a common development effort (by delivering/rebasing to that stream)
Since Git is a distributed VCS, you can achieve the same collaboration by:
making local commit to a branch (typically dev for development)
pushing those commits to a common remote repo
If others have already pushed their own commits (like a deliver), you would git pull --rebase first (a bit like a rebase), resolve any conflict, and push back.
A true Git workflow would involve feature branches, that you would then combine and merge to a dev branch, then an integration branch, then, for release, master. Like gitworkflow.
The remote repo can be managed by a Git repository hosting service, like GitHub, BitBucket or Gitlab.
I've got a repository with my develop branch protected and I'm using the GitFlow branching model. There's two branches; develop (containing features currently being developed) and master (latest deployed production code).
My develop branch prevents commits being directly made via GitHub's Protected branches. When you locally finish a hotfix using GitFlow, it automatically merges the hotfix branch into your local master and develop branches. However, pushing changes directly on the develop branch are not permitted as this is a protected branch
How can you overcome this? At the minute everytime I am creating a hotfix I have to:
Manually turn off the branch protection
Push the develop branch
Turn it back on
This is not automated and therefore, not really acceptable.
Are you the owner of the GitHub project and do you have the administrator role setup with your account (or can you grant administrator access to your account)?
In this case I would recommend you not to protect the branch for administrators. This way you can guarantee that other persons are not pushing directly to develop, but all "knowledged devs" with administrator access are able to. They should be aware of what they are doing, though.
You can edit this behaviour under https://github.com/${name}/${repo}/settings/branches/. My settings do look like this (the last checkbox is important):
Note: maybe you could also use the "Restrict who can push to this branch" option.
Enable 'Require pull-requests' on GitHub.
After you merge the hotfix in your local master you can create a hotfix branch from it, to create a pull-request in origin. Your master will be different, but you can reset and stash and pull in the origin/master.
git checkout -b hotfix
git push origin hotfix
# merge
git checkout master
git reset origin/master
git stash
git pull --rebase
I am trying to find out what would be the best way to set up egit repos for mutliple developers.
I found some arguments to set up independant repos for each developer and then the recommendation to merge the files by setting the respective external upstream repo to eg developer B in Eclipse of developer A so A can pull and merge with B. However A then needs to change the repo back to his own all the time. And switching upstream repos in the settings is quite cumbersome.
Alternatively all developers could work off the same repo in different braches - then merging would be easier since noone has to go to settings and change the upstream repo. On the other side this is also kind of "dangerous" since every developer is working on the same repo without restrictions (so I heard)
Which way is better in the long run?
In the long run, having one upstream repository is easier to manage.
Each developer can make their own branches locally.
They should agree on a common branch to push to though. It can be master, or a feature branch (if a few of them are collaborating to a specific feature).
The idea is, before each push, to pull --rebase that branch from the upstream repo in order to replay your local work (the commits you haven't pushed already) on top of upstream/branch (git pull --rebase will fetch and then rebase your local work on top of what has just been fetch).
That way, a developer will only push commits which will be merged on upstream as a fast-forward merge.
In EGit terms, that pull --rebase is configured when you create a tracking branch.
Rebase: When pulling, new changes will be fetched from upstream and the remote tracking branch will be updated. Then the current local branch will be rebased onto the updated remote tracking branch
This is the first time I am using Git Hub. So please co-operate with me.
I am working on an iOS project with another developer. Now since we are working on 2 different functionalities, I thought making separate branches for each developer is good way. So my plan in to follow below steps
Create a local branches named functionality1 from the current one using
git checkout -b functionality1
Commit my code in functionality1 branch
Push that branch to the remote using
git push origin functionality1
This will add my branch to remote server. I need branches on remote because I can work from anywhere.
I will merge it in Master branch using
git checkout master
git merge functionality1
Now functionality1 is merged into master branch (provided no conflicts occurred)
Other developer will follow same steps.
We don't want to delete the branches yet.
Now once both branches are merged into master, how can each developer will get the merged code from master branch into their respective branches (functionality1 & functionality2) & then continue on working on same branch (functionality1 & functionality2)?
IMHO you shouldn't unless you really need the new functionality. Because by merging e.g. master back into functionality1 you make it dependend upon the other feature branch. A good read is the gitworkflows(7) man-page.
I'm using Egit on Eclipse Mac and PC to sync a project that has three branches:
master
dev
rendersystem
I've created the project on the Mac and when I created the two branches dev and rendersystem I've used revs/heads/master as the Source ref and as Pull strategy I've used Merge.
Now I've switched to my PC and imported the project with Egit incl. all three branches. But if I change to dev or rendersystem branch it tells me that these branches are remotely tracked (in Branches dialog, Remote Tracking /origin/dev and /orginin/rendersystem).
If I check out dev or rendersystem branch and change my code, then commit it and try to push it to Github, it doesn't push the dev or rendersystem branches, only the master it pushed.
My question is now: How do I change the dev and rendersystem branches so that they are in a state where I can push them to Github from my Mac and PC?
Sorry if this question sounds confusing, but Git is one hell of confusing for beginners.
Remote tracking branches are read-only in git, as they represent remote changes. A Fetch will only update these remote tracking branches. A Pull first executes a Fetch, and then merges the changes with a locally editable branch.
On the source computer there was no need to create this branch, as it was initialized locally, and pushing the branch can create the remote branch.
You can create a local branch from the remote branches by Right clicking on the Remote branch in the Git Repositories view, and selecting Create branch... After that, your branch would be writable.