-
Notifications
You must be signed in to change notification settings - Fork 365
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't work on your master #31
Comments
You can check with gitk or at https://github.com/nest/nest-simulator/network. If the branch that is pull requested has already been merged into master... then reject. |
"Working on your master leads to really nasty merge histories. You'll work, then merge into our master, and then continue working without pulling up to upstream, then remerging. " |
Repositories:
If origin is a fork of upstream, and local is a clone of origin, then we have three masters:
upstream/master should only be changed via pull requests which are handled by the owners team. and if you wish to work you should branch from local/master, push it to origin and then request that it be merged into upstream master via a pull request. At that point you could delete your local branch. When you update local/master from upstream master, it will be updated with what was your local branch, indirectly. Otherwise, your local/master branch will diverge from upstream/master, and then your origin/master will diverge from upstream/master. You will end up really confused, others will end up really confused, the same patches will end up being applied multiple times through the branch history, and even worse things may happen. |
@apeyser: is this picture illustrate your point? I was also not entirely sure to understand! |
Mikael, thanks, very nice. That is what you are supposed to do. If you work directly on your master, then step 7 would be a problem, and step 9. If your commits become interspersed on "ProjectA" with others, then you'd have to realize this and message your master by hand. A number of developers have already had problems because of this, and I can see from the from the branching pattern that some more are also doing this and will eventually have problems, but if you follow the graphic, you have one way information flow which makes life easier. |
Dear Alexander and Michael Best Alexander Peyser [email protected] schrieb am Di., 16. Juni 2015
|
I understand that interspersed commits become a problem when working on In my so far limited understanding of git, git should detect the double Am 16.06.2015 22:18, schrieb Alexander Peyser:
Dr.-Ing. Wolfram Schenck Forschungszentrum Juelich GmbH Prof. Dr. Sebastian M. Schmidt |
Yes, if you were consistent you and understand rebase, you can do exactly what @wschenck suggests. But why? Keeping your work on a separate branch and then rebasing the branch on master would give you the same effect with the additional advantage that git would then do extra bookkeeping for you, leading to a simpler and less error prone process. |
@apeyser, thanks for these explanations. I just have one question now. Assume I made changes in my branch
work without causing problems later? I assume that my PR for |
If I get your question: If you merge fix1 into feature2, then merging feature2 into master will merge fix1, thus you wouldn't make (or you'd cancel) the PR for fix1 when feature2 was merged. But I expect that if you're merging feature2, you'd merge fix1 into master first to minimize the size of each single merge. So yes, history is global and if someone else had merged fix1 into feature3, then merging feature3 into master will not case a new set of fix1 patches to be introduced. Anything with the same hash is globally equal. You could do even nicer things using options like rebasing, but for most people this is sufficient. |
@apeyser and @heplesser, what is required for this issue to be closed? |
@abigailm: I think someone needs to review our documentation of the development workflow and check if the information in this issue is contained there. After that is the case, the issue can be closed. |
I can check the dev workflow if you'd like to assign this to me. :) |
@sanjayankur31 delighted to, thank you! :) |
It looks good! Some minor points/suggestions:
Cheers! |
Dear @sanjayankur31, many thanks for the good work! Regarding the use cases: they were mainly there to get things started for us and we were planning to remove them. Do you think we need them? If yes, we can also polish them instead. Would it be possible to start a pull request containing your suggestions? The developer space pages are contained in the branch |
I think they can be removed then.
Sure. I'll begin working on this now. |
update video name
Removed all traces of buffers in spike_detector.
Renamed files and classes related to random number generation.
Working on your master leads to really nasty merge histories. You'll work, then merge into our master, and then continue working without pulling up to upstream, then remerging. You should keep your master pristine, work on a branch, and then do a pull request on the branch. After that, you should delete the branch and make a new branch from master.
This is something to check for in a code review --- that the history isn't crazy. If so, the author should be requested to rebase, otherwise eventually it'll become very hard to identify were bugs occurred and merges will become increasingly difficult to do correctly.
The text was updated successfully, but these errors were encountered: