Proper way of using git/github/bitbucket as a development team?

Question

Assume there are total of three people working on the project. Person A, B and C. All three of them created an branch from master. What should be the proper work flow using github?

Let's say A merged to master first, what should B do in order to merge B's code into master, same question goes to C.

How often should the team merge to master? Daily? weekly? or whenever a new feature is implemented?

Any other good advice on using git/github/bitbucket as a team?

Thank you very much!

Answer 1

This answer assumes following..

Service
Git Hub

Team Size
2 <= x <= 7

Repository
Private

For a small team of developers working on a small project, you can add all developers as collaborators. This will provide each collaborator with read/write access.

Given the above is done, each developer can make a feature branch where he/she can carry out any type of modification they think is appropriate and when the time comes issue a pull request.

What is a pull request? Pull request is a way to communicate the changes you make with the rest of the team. You can issue a pull request and the team will be able to review your work, make suggestions and when everyone is happy merge the work back into the production.

You can always merge your work back into production yourself, but this is generally NOT recommended. After all, you are a team.

So, how often should you commit? There is no strict guideline on how often you should commit but it's considered a good practice to keep it coarse-grained. Whenever you make a change in your code, it has to be specific - something that you could easily describe in a commit message.

Now, about the project workflow. You have made a repository and set up your collaborators, time to get some work done.

Each collaborator clones the repository and creates a feature branch that they will be working on. They do some work - stage + commit and push their work upstream. To keep yourself up-to-date with all changes they make on their feature branches, just remember to instruct git to do pull from time to time. Alternatively, you can instruct git to fetch upstream and merge it yourself manually.

When one of your team members is ready with his feature branch, they should issue a pull request. At this point you review the work they have done, make any appropriate comments and if everyone is satisfied merge it into production.

The above information is writen to cover the process at an introductionary level and is by all means not the only way how to work with git. It should serve as an introductionary material for git workflow in small project teams. The answer doesn't itend to cover all possible ways of running a project on any of the services (Git Hub, Gitbucket etc.). Hope you found it informative.

Answer 2

For the last 12 months I've been using this Git feature branch model with good results in a team of 4 developers and me for QA.

I promote regular push/pulls within the team - we know quickly if code breaks other code, can resolve merge conflicts before they get out of control, and fix potential problems, etc. It gets the team communicating and collaborating regularly. Vincent says "these actions are extremely cheap and simple, and they are considered one of the core parts of your daily workflow".

Vincent goes on to describe the origin repository as the "central truth repository" from which developers fork their own repository. We use a master branch to reflect always what is on production servers (with tags for version releases), develop to reflect what is on our staging servers, and feature-specific branches with JIRA ticket codes (e.g. PROJ-001-fixes-all-teh-bugs) alongside JIRA integration.

Devs can then work on a feature branch on their own, or collaborate with another team member pushing/pulling between their repositories on the same feature branch. They push up to origin at the end of the day to update "the truth".

Vincent goes on to describe hotfix branches and release branches although we haven't needed to use the latter yet.

As we've tied BitBucket into JIRA, we noticed private fork repositories don't update ticket statuses etc, but a daily push to origin (even on a feature branch) will do the trick.

Once the feature branch is ready our devs put in pull requests, we have meetings to approve/tweak, and it gets merged into develop and then master when it's going live. If the boss decides a feature sucks we can revert the branch merge and go live with other features - a powerful tool.

Some devs found working on a fork too much effort / confusing to begin with. Persevere! It becomes second nature (even to me, and I'm not very good) and it's saved us from sticky situations and terrible code.

If all that sounds good...

Let's say A merged to master first, what should B do in order to merge B's code into master, same question goes to C.

Using Vincent's model, A B and C would be working on private repo forks in a feature branch. They can regularly pull from each other while they work on their own fork. Inevitably one dev is left with the latest code who pushes it up to a feature branch on origin and puts in a PR.

How often should the team merge to master? Daily? weekly? or whenever a new feature is implemented?

A merge to origin/master would only happen when the feature is about to be deployed. We would merge to origin/develop first, test it on our staging environment, then PR the develop branch into master.

We found merging and pushing active feature branches to origin at least daily is good practice and updates JIRA statuses.

Any other good advice on using git/github/bitbucket as a team?

Learn how to deal with merge conflicts, reverting commits and reverting merge commits effortlessly :) Talk regularly within the team. If you like Vincent's model send the article to everyone and have a discussion about how it can work. Maybe even practice Git-fu on a fake project.

Answer 3

If all of you are starting out with distributed code management, it is a good idea to do it right from the get go. Pick one of the established workflows, read up on it, play around a bit, and then get productive.

My personal favourite is "Branch per Feature" by Dymitruk: http://dymitruk.com/blog/2012/02/05/branch-per-feature. It is very powerful, the presentation is very clear and complete, it just plain works and IMO does a few things better than the "usual" workflow (http://nvie.com/posts/a-successful-git-branching-model/ as posted in another answer here) where you have a dedicated "development" branch. Of course, you won't do much wrong with the latter either.

Your questions will be answered on those pages (Dymitruk does the "merge to master" fundamentally different, there is no question/problem about ordering; basically "merge to master" is equivalent to "production release").

Just don't try to wing it and invent your own scheme as long as you are in the state you are now (i.e., new to all of this).

Answer 4

Always do git pull origin master before merging your branch into master.

After that push your changes to particular branch.

• git push origin brnach_name

Now, you can merge with master.

Typically once should merge their branch with master. Whenever there is a new feature.