git workflow, create a local branch delete and recreate again

Question

I am using git. As of now we are two team members working on a project. Both work is slightly independent as of now, one focusing on UI while the other is focussing on apis. I like to checkin multiple times a day. My typical workflow is:

http://amiridis.net/posts/13

So I create a feature branch and then work on it, merge it to the main and then push it. Delete the branch and the recreate the same branch.

The product is still the 1st version and we have a continuous integration build server setup. The main purpose of pushing is to get incremental updates to supervisors.

My question is,

• if I have not finished a feature fully, is it a good practice to push small units of compilable changes to the main server on the main branch if it is still version 1?
• Is it a good practice to create the branch, merge to main, push it, delete the local branch and then recreate it?

Answer 1

Question #1

If I have not finished a feature fully, is it a good practice to push small units of compilable changes to the main server on the main branch if it is still version 1?

No. It is generally not good practice to introduce unfinished code into the main branch. You should always have a branch that mimics the state of production code. For most people that branch is called master.

One example of why this is important is in the case of bugs in production. If you already introduced a bunch of half-done work into your main branch, then any fixes you release will also include that unfinished work. Also if other developers are pulling from that branch, and you've added untested code, you may complicate their development.

Even if your code has not been released yet - you'll want to have a branch that contains only working and fully tested code. Generally speaking, you should try to break functionality down as much as possible and test small changes. Those can be merged into the main branch if they dont negatively effect anything else that is already working.

However you work, you should try to keep a branch that has some level of "authority" - a branch that is only merged into after meeting some criteria. What that criteria is, is up to you.

You may decide you keep a master branch that the only time its modified is when a new version is being released. You decide instead that you can merge into your main branch as soon as your work as been tested. How you decide to do this is often dependent on the release strategy and the broader workflow.

Question #2

Is it a good practice to create the branch, merge to main, push it, delete the local branch and then recreate it?

Can't answer with a yes/no. There are many strategies for how teams might handle versioning of their code, collaboration between members, and release cycle.

Generally speaking it is good practice to delete branches shortly after they have been merged into the main branch. Its usually better to get rid of and avoid continued use of the same branches (commonly referred to as branches that have a "long life"). Short-lived branches are preferred in most circumstances for individual development tasks - however that may change depending on your teams preferences and choices.

Workflow concerns

You have a small team and your code isnt out in the wild yet - so pressure will be lower and solutions will be easier because its just you two. However, once your product goes into the world pressure will be higher to solve bugs - the the need to release hotfixes/patches will probably arrise. Release cycle will be complicated by more and more simultaneous development. Collaboration will be more confusing and error-prone as you add more and more developers to your team with varying levels of understanding of version control.

So here are a few things I recommend you keep in mind when deciding your workflow.

• Hotfixes/Patches - If your already half way done with version 2, but now you find a critical bug in 1.0, how easy is it for you to release a v1.1 without it including the incomplete work of 2.0
• Rolling back - If a bug is introduced along the way, can you easily back out of the buggy version?
• Compartmentalization - Try not to share broken or untested code with team members who aren't specifically working on the same thing. If I always pull in your untested code while im developing, it will be hard for me to know if errors are caused by me or by changes elsewhere in the code caused by another team member. I should only pull in other peoples code once its been tested and verified. By keeping branches short-lived, and making small, easily testable changes - those tested updates will reach your team mates faster and bugs will be caught sooner.
• Collaboration - Sometimes people actually need each others code in order to continue their own work. Thats why short-lived, small changes are important. However sometimes two people are literally working on the exact same thing - they work together on the same functionality. In this case it is reasonable for them to work off the same remote branch. However be aware that git-reset, git-rebase, performing a force-push, or doing anything that modifies commits on the remote will cause your team mate a load of hurt. When sharing a branch, be mindful of that branches history.
• Complexity - Team members will have varying levels of understanding of version control in general and git specifically. Even if they are all git experts, simpler is usually best. The number of steps any one person has to perform to get something tested, have something merged into an authoritative branch, or share code with other developers should remain a low as possible. Its something everyone will be doing many times a day. Not only does a complex process eat up developer time, it will be more prone to errors by everyone but more often by those with less experience. Those errors might cause even further delay as others work to unravel the problem. This consideration usually works in opposition to the others, as the others tend to imply adding more layers of complexity. Just remember to keep that compelxity in check.

A popular workflow is known as "git flow", and there is even a command line tool to help automate the steps involved. As a small team you might find it over-complicated - but I would suggest that this is the least you should doing if you have an iteration based release cycle.

I actually am not a huge fan of git-flow, but only because i feel like its actually too simplistic and two-dimensional. (Im not a fan of "decentralized but centralized", I prefer a workflow that is actually distributed).

However if you have a very fast paced release cycle - in which case you might want to adopt the model that github itself uses. Their model is similar to yours, in that they simply merge into master - however they only do so after code as passed some automated tests. The key point to what github does is also the fact that they deploy many times a day - not on a release cycle like most teams do. This makes it so that bugs that make it out to production will almost always be recently introduced. Its a simpler strategy but its not for everyone, keep in mind the bullet points above, especially if you have a more typical release cycle.