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
Related
We have a Master branch and a Develop branch for our repo. We are supposed to check-in (commit, push) to our Develop branch and then merge that with our Master branch. Then a build is run for the Master branch. I pushed my changes directly to Master (then tagged it), putting Master multiple commits ahead of Develop and now want to bring Develop in sync with Master. What is the best practice to do this? I use GitExtensions and Visual Studio 2015 (am ok doing the operation in either). Do I 'push' Master into Develop or do a check out of remote branch Master and merge with my local?
I would find it most clear to just check out both branches locally, merge in the changes from your local master to your local develop. Then push your local develop to remote.
The workflow I use works something like this in the scenario you describe:
Switch to Develop branch
Fetch All
Choose last (newest) commit in Master, right click => Rebase current branch on => (commit ID)
If Rebase works successfully you're done. If not, you may need to resolve conflicts or cancel the Rebase and merge from scratch.
The reason for using Rebase is that it maintains a single line of commits thus helping keep everything clear.
For more info on the difference between rebase and merge see:
https://www.atlassian.com/git/tutorials/merging-vs-rebasing
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.
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.
When I create a new branch from a remote branch using EGit I get the wrong remote tracking set up:
I create the local branch feature1 from the remote branch refs/heads/master and immediately push to upstream. The followign remote tracking gets configured in my .git/config file:
[branch "feature1"]
remote = origin
merge = refs/heads/master
So, pull and push in that branch will pull and pull from/to the remote master branch. I would expect the following tracking configuration instead:
[branch "feature1"]
remote = origin
merge = refs/heads/feature1
I know I can fix it even from EGit, but I'm worried about other developers in my team not realizing this and pushing uncompleted features to the master branch.
Am I doing something wrong?
Egit will, by default, take the upstream branch for the merge parameter when creating a branch from a remote one.
That means, if you want to enforce the policy which is to push to remote/master only from a local branch master, you can try and enforce it locally.
Check if Egit respects a git config push.default current for pushing only the current branch to an upstream branch with the same name (which might actually become the default policy after git1.7.10).
However, that has the issue of making sure every developer has that policy active in his/her repo.
(I don't think you can enforce it at the "central" repo one, where you could add a server-side hook like an update hook: that script take the name of the branch being updated (ie here 'master', not the name of the branch in the downstream repo, ie here 'feature1')
Note: bug 378960 has been marked as resolved (February 2014) in Egit 3.2:
Push Branch / Initial Push wizard simplifies pushing a branch and also allows upstream configuration for new branches created by the push operation:
Maybe you should advise developers to create feature-branches not from the remote-tracking branch (e.g. origin/master), but from the local one (master). This way, EGit will not set up any remote tracking by default.
If you then decide to publish the branch for the first time, it should be possible to set up the remote tracking (the equivalent of git push --set-upstream) after bug 378960 is implemented.