0

We work on our projects locally, and deploy them on remote servers for testing. This is currently done via git commits/push/pulls. But the problem here is that most of the commit contain errors and/or break the code in significant manner due to the lack of testing.

Is there a way we can deploy the code on the remote server without using git commits, or some sort of temporary commits or patch or any other mechanism? And only commit, whenever it is important.

3 Answers 3

1

You should always encourage commiting often, not discouraging it.

You should have several branches in your git server, at least dev/staging/production to handle that situation. Google 'development workflow' and you'll find several examples.

Finally you should look at CI servers, like jenkins

4
  • Thanks @mvillar while I understand this, the only issue i am facing is whether it is fine to have commits where 80% of the commits are fixes like syntax errors or other petty mistakes? May 28, 2014 at 20:59
  • Of course, there will be syntax errors, lots of fixes, etc in dev. If that weren't the case we would only have production branches and have tons of free time ;)
    – mvillar
    May 29, 2014 at 6:05
  • Haha, but is it fine to have 'em on commits? And also have commits which just adds a semi colon for an instance? May 29, 2014 at 13:41
  • 1
    Yes, yes and yes. When you and your team will be accustomed to commit often, you'll have sometimes commits adding comments, commits adding a blank space to correct indentation... etc. and that's perfectly fine.
    – mvillar
    May 30, 2014 at 10:59
1

Make use of branches!

E.g.

Create a develop branch where you and your team usually works in, that can contain bugs, even unfinished code.

Then create a release branch from the develop branch. Now you can commit code into that branch to get the software into a stable state so that testers can work with it. Of course it's not allowed to merge the develop branch into the release branch once again.

As soon as your software in the release branch is stable and thoroughly tested, merge the release branch into the master branch and then back into the develop branch. After that, just delete the release branch.

Following this workflow...

  • the master branch will only contain stable and tested code. Yay :)
  • the release branch won't suffer from breaks the devs introduce in the develop branch during the lifetime of the release branch
  • the develop branch will profit from stabilizing work that was done in the release branch. In fact, you should merge the release branch into the develop branch (not the other way!) as often as possible.
3
  • Thanks Sandro, we are going through the same cycles. My point of concerns is that a commit is unnecessarily broken into 4-5 commits where the tail commits solve useless issues like syntax error, etc. This makes the task of reviewing commits, etc. a bit complicated. If that is the general way though, we are close to what everyone else is doing :) May 28, 2014 at 20:34
  • How do you split a commit in 4-5 commits?
    – Sandro
    May 28, 2014 at 21:18
  • What happens is, you code something locally. You push it, and realize that you did a stupid mistake. You commit and push again. And voila, another mistake. You do this 2-3 times more unless your api end point works properly. May 28, 2014 at 21:38
0

Abhishek this sounds like a human problem, not a git problem. Your coders need to test their work before committing. Shame is a pretty good tool here, used with humor. Loud shouts of "who broke the build?", emails, informal rules that the last one to break the build buys lunch... you figure out what works in your shop to get a habit of testing before committing.

1
  • Haha, +1 for the pinch of humor. The issue is our environment is pretty complex so we didn't set up any local environment to test things. We can write unit tests but it may take some time. May 29, 2014 at 6:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .