We are 3 developers working in the same feature in GitHub.
There is a master.
Each of the developers has their own fork of the master.
Now each developer added the remote fork of the other 2 developers. And with communication we are pulling the changes of the other 2 developers and then merging and pushing to the developer fork. So the others developers can pull and merge to push again to their fork.
The problem with this approach is that we have more merging to do, that if we were all pushing and pulling to the same branch. And the communication is a must.
We try to make a fork of a fork and we couldn't. Github does not support it.
We try to push to the same branch, we couldn't. It seems that also Github does not support it.
So there is a way in Github we all push and pull to the same branch or repository? And when we finish we do a pull request to a master?
Any recommendation about how to work many developers in the same feature in Github?
Instead of forking and pulling, you can use the other collaboration mode prevalent in GitHub: shared repositories. Shared repositories are useful for small, private development groups.
Give your developers push access to a central repository and they will be able to collaborate without pull requests and excessive merging. (Pull requests are still useful if you decide to use the shared repository model especially for code review and feature discussions.)
In GitHub terminology, a person able to push/pull from a repository is a collaborator. Collaborators are set in the repository settings page.
So there is a way in Github we all push and pull to the same branch or repository? And when we finish we do a pull request to a master?
Start an organization, move your repo there, and give all developers push access.
Related
I have a project on GitHub, and I forked it to a second repository.
There is still work done on the repo that I forked from, but the changes I make to the first repo should also be applied to the forked one.
How can I push a pull request to both of them at the same time? Or is that impossible to do in a simple way?
If it is, is there a simple alternative solution?
No, GitHub pull requests only target a single repository.
Pull requests are only relevant when you are communicating with other people. Since both repositories are yours, you can just execute a git pull or git merge command on your local machine to merge whatever branches you want to merge. Then use git push to push the changes up to GitHub if you want.
Also, I recommend that you simplify this setup and just use a single GitHub repository with multiple branches.
I want to set up a proper workflow on GitHub where junior engineers submit pull request for code review and only the lead engineer can commit to the master branch.
I'm looking for input from professionals that work in a commercial software environment. I've found the page that does the permissions easy enough. There are several options. Restrict who can push to matching branches of course. Should I check others as well?
The other approach, beside the branch permission within one repo, is the gate repo:
you are setting up a public repo where developers can commit (on master or topic branches)
you are using a private, or repo within an organisation, from which you can pull
That way, you or your organisation team control the contribution you chose to include in the master of that main repository.
I want to restrict commits to only few collaborators in few branches. I have personal account in github but donot have any facility to do so as that of organisation. Any suggestion is much appreciated.
You can always use GitHub's standard forking workflow:
Each collaborator will fork your repository and do their work in their own fork.
When something is ready to be contributed back to your repository the developer will create a pull request that you will review.
That code will only be merged into your repository if you approve it and accept the pull request.
In this way you control the code that gets merged into each of your branches.
I am working on a open source project which uses bazaar for versioning and launchpad for repo. The project also has github repo but launchpad repo is primary. I am behind college proxy so i can't access ssh required to connect to launchpad to merge/push changes. Is there a way, that i commit, push all changes on my github account, and they get reflected on my launchpad account too. Can I send merge requests too?
This will give you overall idea , how to do that
create your project test in github and will be owned by organization name Acc.
then just push the master branch to test
Now fork the project and clone
Push all your local branches to your GitHub fork git push -a origin
And checkout that branch using git checkout <branch_name>. And then push to origin of that branch.
Launchpad is a project-centric environment, so you will most likely have a GitHub organization that owns the ‘main’ repository and encourage all members and newcomers to fork from that.
within fork developer can able to work on that, usually when about to issue a pull request – GitHub’s version of a merge proposal, pull down changes from the upstream organization master into their master. Since this will happen relatively often it is easiest to add an additional ‘remote’ target for it:
git remote add acc `http://github.com/acc/test.git`
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