Github questions!
Monkey Forums/Monkey Programming/Github questions!
| ||
| Hi, A few questions for any github pros out there... * I accidentally merged a 3rd party tweak with the 'master' branch instead of 'develop'. What's the recommended course of action here? Is it possible to apply just that commit to 'develop' too? Are there other ways? * If someone clones blitz-research/monkey and makes some custom tweaks to it along with tweaks to the 'official' code, then tries to merge back, I'll get their custom tweaks too, right? How should people deal with this? Should they make a clone of brl/monkey, then make a 'custom' branch? Or should they clone their clone? Actually, a clone is a lot like a branch I guess...? |
| ||
| 1. you can revert to a previous branch at any time. http://learn.github.com/p/undoing.html 2. Yes. People will send you a pull request when they're ready for you to evaluate the merge. AFAIK, at this point, you manually evaluate the changes with a difftool like kdiff3, test for regressions, and merge the changes which you find acceptable or reject the branch. This is the common way to contribute to projects on github -- if you don't flag someone as a direct contributor, then they manually fork the repository, which creates a serverside copy on their account. They clone this server-side repo to their local computer, then work on it, and contribute it back to their forked repo. Then, when they're ready to give the code back to you for merging, they do a pull request. This may or may not help: http://stackoverflow.com/questions/6286571/git-fork-is-git-clone |
| ||
| > 1. you can revert to a previous branch at any time. http://learn.github.com/p/undoing.html Ok, but I can 'move' the change to another branch? On that page, there's an example of undoing a commit to a master branch, and 'moving' it to a new 'test' branch, but I can't see if there's a way to move a commit from master to an existing branch instead - in this case, develop. Not a big deal, just mainly curious... Also, I'm a bit confused about the whole 'staging' thing, but that may be because I'm mainly using the GUI client though which no doubt does some 'magical' stuff. It just lists the changed files and I select 'commit' and voila it's done. But I'm unsure where/how stuff is 'staged' - it appears to be part of the whole commit process only. I suspect I need to spend a bit more time with git in a 'shell'! > AFAIK, at this point, you manually evaluate the changes with a difftool like kdiff3, test for regressions, and merge the changes which you find acceptable or reject the branch. I'm using the github web interface here (which has a very nice 'diff' preview), which appears to only let me choose between merging ALL changes, or none - I'll have a play around with this though. But I thought in general, it should be possible for people to only send me merges for brl stuff, so I don't have to sort through custom changes? But maybe not... |
| ||
| Hmm..... the "git branch [branchname]" command in the commandline should create a new branch based on the existing one in master. If you've already reverted the changes, I'm not sure what would have to be done. http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging There may be arguments/flags for branch that let you specify a previous commit to branch, but I'm not familiar with the commandline, so I don't know for sure. Staging is basically a way to only commit the changes you're ready to commit before making a push. By only staging certain files, you can commit a push that doesn't include, say, more experimental and/or temporary changes that you haven't made a separate branch for. I'm afraid I've never had to do a merge or a pull request before, so I don't have much experience in being able to explain how it all works, but I do know that just about anything is possible in git, with minimal amount of hassle/frustration compared to other solutions, once it's all set up properly. |
| ||
| Ideally, anyone sending a pull request will have placed their changes in a branch that only includes the changes they want you to take. It certainly shouldn't be a case of you picking through their entire working repo to filter bits you're interested in. This is a fairly readable tutorial on the process: http://gun.io/blog/how-to-github-fork-branch-and-pull-request/ |
| ||
| > If you've already reverted the changes, I'm not sure what would have to be done. I haven't reverted the 'wrong' commit to master (it was supposed to be to develop) - it's still there. Perhaps this would work to move it to develop? * Make a tmp branch of master * Reset master to before the commit * Merge tmp branch with develop * Throw away tmp branch How does that sound? > Staging is basically a way to only commit the changes you're ready to commit before making a push. By only staging certain files, you can commit a push that doesn't include, say, more experimental and/or temporary changes that you haven't made a separate branch for. Ok, I think the Github client does this for you automatically - each time I 'reactivate' it after editing some files, it lists all the changed/deleted/created files ready to be committed (which I love). I assume these are all 'staged' files. You can uncheck some of these if you want, which I guess unstages them. Checking the git docs, it seems like you normally have to 'git add' any changed files if you're using the command line. |
| ||
| Yes, I think those directions are what I would do if I was facing the situation. Once the tmp branch has been merged, it should appear to go away, and will be reflected in the branch visualizer in your commit history as having been fully merged back into 'develop'. As for staging, yes, I'm pretty sure that staging as an intermediary step is enforced by the commandline -- Git Extensions (the GUI I use) also has a similar "Stage all and push" feature, to stage all the changed files, letting me remove the ones I don't want from the stage before pushing. It sounds like the Github client is doing the same essential thing, but hiding the internals of staging for convenience. On the commandline, I think staging might make more sense, since you might want to stage files you know you're going to change ahead of time, work on it a while before deciding to commit, and then make a push with a simple command. It's a pain in the butt to do this all manually, but I think most people would always want to commit their most recent changes, unless they really broke their code up something fierce and don't want to branch because it's "temporary" |
| ||
| So, if I want to suggest some changes, I would rather do a branch for each change and make a pull request containing only a change-set at a time? I'm working on some sugested changes to mserver, so it is better that I do this on a specific branch and make pull requests with only this changes so Mark can see what's been changed and accet/reject suggestions easily? Is this ok? |
| ||
| Your own fork is actually a separated branch respect to the official one. My statement could be clearer if you browse the "network" tab on Monkey's GitHub repository --> https://github.com/blitz-research/monkey/network As you can see, Devolonter made a couple of changes to his fork, that remains separated from the original one. He just made a pull request. Now it's up to Mark, when/if he accepts his pull request, to manage/integrate the added code in the most convenient way. This is when you are an external contributor. As a direct contributor, your commits will automatically join the main repository with no need for a pull request. In any case, each time a team coder is going to focus on specific areas, the best practice is to create a new branch, so to avoid regression collisions on the main branch, until the ongoing development is clean and well tested with the existing code base. When a part of your local sources is ready to join the codebase, you can selectively stage them, choosing what to include in next commit. |
| ||
| Thanks Corum! I've just done it like this for some changes on MServer and they've been added to the development branch |
| ||
| Well, had my first bit of github weirdness yesterday - some stuff I was working on Friday afternoon completely disappeared somehow! Fortunately nothing major, and there's a dropbox backup there for me to double check against, but I don't really have a clue what I did to cause it. The only slightly weird thing I did yesterday that I guess may have been involved was solving the above 'committed to wrong branch' issue by simply merging master->develop, on the theory that the ONLY change made to master since the last develop->master merge was the one I really wanted made to develop, so...? The history of commits looks right anyway - can anyone confirm this was safe-ish? Another weird thing: if I change branches, it changes all my files 'in place' - scary, but kind of useful. Only sometimes it wont, eg: if I edit README.TXT or src/rebuildall.bmx (say, insert a line at the top) but don't stage/commit, github will let me change branches and shows the change as 'commitable' on either branch (once it's actually committed, the change gets swapped in/out along with branches). But if I try the same thing with, say, bouncyaliens.monkey, it wont let me change branches - I get a 'failed to checkout the branch - the changes to the following files will be overwritten by a checkout'. Which I sort of get - but why doesn't the same thing happen with README.TXT or rebuildall.bmx? What's the difference here? |
| ||
| In theory no operation should lose data unless you force it. Are you saying that you lost work that was in the repo or just work that was local? As for the branch switch I'd guess that you've got local changes on top of branch changes in one situation and not in the other. Git can't swap branches without losing your local changes if the branch itself changes the same file. If they're the same in the repo in both branches then your local changes can be left as is. I prefer to commit or stash (shelve in hg speak) changes before switching branches unless I specifically want to assess a local change against the other branch. |
| ||
| > In theory no operation should lose data unless you force it. Are you saying that you lost work that was in the repo or just work that was local? Yes, it was work that was part of the repos. I made some local modifications on Friday afternoon but went home before committing them. And then yesterday, I appear to have done something that caused those changes to 'revert' - ie: the local modifications seem to have disappeared. > If they're the same in the repo in both branches then your local changes can be left as is. Yes, that's it, thanks! |
| ||
| By in the repo, I meant committed. You're saying that you lost local changes? Destructive updates to your local working copy should be flagged. It's always possible to click through confirmation without noticing or have something set up to force by default though. |
| ||
| Mystery solved (I think) - the changes are actually sitting there in my master branch! I must have had the current branch set to master when I was making the changes, switched back to develop at some time and, erm, 'lost' the changes. I also must have committed them at some point...? |
| ||
| @Mark - You might want to take a quick peek at this blog entry about branching models, I found useful bits there to develop a sane branching strategy. http://nvie.com/posts/a-successful-git-branching-model/ Cheers! |
| ||
| In the Github notation, your "local copy" of sources is meant to be your "working copy". When you switch between branches (or tags) you force an update (i.e. total replace) of your working copy. Before making any switch, I always do a commit of the current working copy. I recommend again this great piece of software: http://www.sourcetreeapp.com/ It's free, and works under Mac and Windows. I really understood github mechanics only after using this software, because any operation is visually explained, there are a lot of warnings and tips related to any critical operation, and the big picture becomes much clearer. :) |
   |