Proper workflow using git and github

Question

So currently I've been coding rails apps using git and github. I usually work alone, but in my latest project I'm working with a second developer. I'm trying to figure out the standard methods for working with another user.

Currently, I had him fork my gitrepo, and then just submit pull requests when he has changes ready. That hasn't been so bad, except I code a lot more - and when there are changes in the fork queue for him to push, many of them fail (even if he hasn't made any changes from the last time he pushed mine).

The whole process just seems more efficient for him to re-fork everytime, which makes me think we're going about something incorrectly. Should we be using branches instead of forks? Or maybe forks and branches?

Thanks!

Answer 1

The second developer should pull first the GitHub repo into his local repo, solving any conflict there.

And then he can make pull requests.

• no need to re-fork (which doesn't make sense anyway: a "fork" is a clone on the GitHub side)
• no need for an extra-branch (if you both are working for the same set of feature, you can both work on ' master ' for example)

The idea of a pull request remains to submit patches that will be fast-forward ones (easy to apply to your GitHub repo).
And that is achieved by solving any conflicts locally first, before making pull request.

---

The other options would be to declare said second developer as a "collaborator" on your GitHub project (he would be able to push directly), but that wouldn't change the fact that a "pull first" is necessary to ensure the push will be straightforward.

Answer 2

There are a number of git workflows open to you because it's a flexible tool, but a simple workflow is to have a 'master' branch and a 'develop' branch. You can both push and pull directly to your repo without forking on github and without your collaborator having to constantly submit Github pull requests.

You can both make the majority of your local commits on the develop branch but frequently pull down from the remote develop branch in order to merge each other's code - it's at this stage that you can deal with merge conflicts, before pushing to remote.

Less frequently, you can pull down master and merge that with develop. The idea is that the master branch is more stable and can be prepped for release at any time, so active development does not occur on it. That's all there is to it.

If you want to go further you can both make "feature branches" from your develop branch, but the principle is the same - merge back 'up' to develop, and from there 'up' to master.

The important thing is to synchronise (merge) your work often, otherwise the differences in your separate copies of the codebase are likely to be greater, which means a greater chance of conflicts. If you continue to have conflicts, push and pull more frequently so the differences are smaller and easier to handle.

Conflicts are especially likely to occur if you are both working heavily on the same files. In such cases, it sometimes pays to be organised and divide up the work into features that change different parts (files) of the codebase, so you are less likely to step on each other's toes.

Remember to commit your local changes before pulling, otherwise the changes will be considered to be in "staging" and will not be merged automatically during the pull. Fortunately, git is fairly forgiving and very good at dealing with merge conflicts.