github question

[nppangband]

So far I have only used Git in its simplest form, merely to upload code that is ready for others to play. I have two branches for NPP. I upload every commit to a branch called "work in progress". When I am ready to finalize a version, I move everything from "work in progress" into "master", and I tag that commit as the final version.

The good news is, for the first time in about 5 years, RL is finally allowing both Diego and I to actively develop NPP at the same time. What we used to do is just send patches or files back and forth and one of us would manually merge them.

I guess this question is for the Angband dev team, but what do you all think is the best way for us to use github? I still want the work-in-progress branch to be the latest code that is ready for people to play, but what do you all think is the best way for both of us to get it there? Should we each just have separate branches, and just pull/fetch, merge and push each other's code into work_in_progress?

Thanks for any advice you all may have. I figure if the Angband devteam all has 6+ people all pushing things to the same branch at the same time, that you all would probably have some good advice on how Diego and I can best do things.

[debo]

I would probably leave your remote repo set up the way it is currently, with 'master' and 'work_in_progress' as the remote branches.

Locally, you can treat 'work_in_progress' as your "release master". If you need to do something disruptive in 'work_in_progress', you can just create a local branch (it could be remote too, but not necessary) to make multiple commits to, merge that back into 'work_in_progress' when you're done, git pull origin work_in_progress to pick up Diego's changes, and voila, you can push.

Then, when it's release time, you can merge the work_in_progress branch back into master, just as you've been doing now.

git branch -d <branch> will delete the ref for a local branch when you're done with it.

git is awesome -- I hope you enjoy working with it as much as I have A 2-person team isn't really that much different than a 1-person team, tbh. The only weird thing you have to get used to is using 'git add' and 'git rm' to confirm that files really should be added/removed when pulling down someone else's changes.

[fizzix]

Here's the approach that I use. I think other devs use something similar, or at least Magnate does.

It assumes that you have an official branch, something like npp/npp and a personal branch jeff/npp. I'll also assume that your official branch is named something like npp_master

Code adding side.

1. git fetch official {get the latest version}
2. git checkout -b new_stuff official/npp_master {make a new branch named new_stuff that starts on official master}
3. (make changes)
4. git add <changed_files>.c
5. git commit {commit all the changes to your new_stuff branch}
6. git push -f origin new_stuff {push the branch new_stuff to github}
7. {submit pull request into official master from github}

Now let's say that Diego made some changes and submitted a pull request and you want to look at these changes and incorporate them into npp_master if everything looks ok. I assume you have a remote branch set up to track Diego (if you don't it's really easy to set it up.) Here's how I've been instructed to do this.

1. git fetch diego {get the latest changes in Diego's branch}
2. git checkout -b npp_master official/npp_master {make a local copy of the master branch, if you have a local copy that you keep in sync with npp_master you can use that, just don't include the -b}
3. git cherry-pick -x <commit number for Diego's stuff> {add the commit to your local branch, the -x keeps track of where it's from}
4. (compile and test, assuming everything looks fine)
5. git push official npp_master {update the official npp_master branch}

Things get a little tricky if you both are simultaneously pushing stuff that mess around with the same files. But there are ways around that with either fixing the merge conflicts that arise with git cherry-pick or rebasing your changes, and fixing the conflicts, right before you push and submit the pull request.

There is something nice about having someone else test your changes to make sure that everything works fine, especially if you guys compile and run on different operating systems.

[LostTemplar]

Btw is using cherry pick command the best way to pull changes ? I use it, but it seems like a hack to me.

[Magnate]

Originally Posted by LostTemplar

Btw is using cherry pick command the best way to pull changes ? I use it, but it seems like a hack to me.

It's useful for when you want some commits but not others, as "merge" is an all-or-nothing operation: you merge all the unmerged commits at once.

It's also useful for keeping things tidy, as merging will create a separate "merge commit" for each merge. This is fine if I'm pulling in half a dozen commits from Blubaron, but for single-commit fixes from other devs it's unnecessary cruft in the history, so I cherry-pick those instead.

@jeff: what fizzix said. This is written up at http://trac.rephial.org/wiki/GitUsage but pls say if we could make those pages more useful. Your WIP branch is what we used to call "staging" - we've actually done away with that, but it's definitely a valid approach. This means you and Diego should merge pull requests into WIP first, in case you need to change anything. You can stick with your system of pushing to master at intervals for 'official' releases.