I want to know whether it is a good practice to push build/*.classes to git. My senior colleagues told me, they usually wont do it as their seniors instructed them, not to do so. If its not a good practice, some one please give me a reason why we should not do it?
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
--- Martin Fowler
I used to do it, but that was back when builds were "iffy" and the time it took to build something was slow. It was useful to have as many pre-built products available as possible in case something went sour in the middle of the night and your IDE was no longer compatible.
These days we have civilized build environments such as Maven which can reconstruct all the products (even old ones) automatically with a single command. And clean the out with a "mvn clean". So there's no benefit to keeping the intermediate products and it wastes storage and other resources to do so.
Being persecuted doesn't in any way prove your righteousness or your beliefs. Many people get persecuted because they are repugnant or annoying. Or just because they can be.
Never ever ever check in class files into version control. There's a whole lot of engineering reasons behind this, and to get a proper understanding of this you need to understand the history. It seems like a lot of young people keep making mistakes that we know as an industry that we shouldn't be doing because no one really covers principles of build management in coding school. I'm going to lay some history here, so if you don;t want to read everything that follows the tl;dr; version is Never ever ever check in class files into version contro
The biggest reason for not checking in your class files is this: The reason why you have any kind of version control is that any given time you should be able to go back and look at a version and see what exactly was changed. No one remembers what they did 6 months ago. Heck, I don't remember what I ate last week! So, if you see a line of code that looks weird, you should be able to go back and see who changed it, why they changed it, when they changed it, and what were the other changes done at the same time. Hopefully the check-in comments will also point to something that allows you to look at the exact requirement that drove this change. This prevents you from inadvertently undoing something that someone else did
So, you are going to ask me: what does it have to do with class files? Everything!. One of the important things about anything you check in to GIT is that it should be diffable Basically, you should be able to do a diff and see exactly what has changed. You cannot merge a class file. Git's own merge capability is built on the ability to do 3 way merges. If you try to merge a class file, Git is going to say, nope can't do it.. pick one.
So, why not check in the source and the class file? You can always rebuild the class file from the source, right? Just check in both, and when you have a merge conflict, rebuild the class. Problem solved! No! Problem made worse. Another basic principal of change management is that you do not let the developers build class files that go into production. You might have heard of the phrase it works on my machine. Long time back, probably when you were an twinkle in your papa's eye, developers used to build the class files on the local machine and use that to deploy to QA/prod everywhere. There were no version controls back then. Just chaos. What would happen is that the same class file would work on the developer's machine, but no where else. They report this back to the developer, the developer says It works on my machine!. The bigger problem was that ultimately, it became so bad that unless you didn;t build the class file on this 7 year old machine it wouldn;t work. Because there was no control. If you are checking in class files, you are doing the same thing. You are building class files on the developer's machine. Developer's machines have whole lot of crap in it.
And I have seen this happen many times: First developer fixes a bug and builds the jar/war/ear gives it to testing and forgets to check in the source. Then next developers makes another change, builds the jar/war/ear. Of course since second developer doesn't have the source that the first developer didn't check in, his jar/war/ear doesn't have the fix, so it looks like the second developer broke the first developer's fix. Everyone blames the second developer. Finally they figure out that the first developer didn't check in source. Then the second developer murders the first developer.
So, the answer to this "problem" was to create a Change Manager. The Change Manager is a person whose job is to build class files. S/he checks out code, builds it and deploys it. This person also maintains the build environment. Of course, this is not very agile. The Change Manager is not part of the team, and one of the agile principles is that everyone should be part of the team. The agile way of doing change management is instead of having a Change Manager, you have a Continuous Integration. Instead of a person building the class files, you have a server doing it. It checks out the source, builds the classes, builds the jars/wars/ears, and puts them in a artifact repository. When you are ready to deploy, you pull the jars/wars/ears from the artifact repository and deploy. You can even have the CI server deploy the artifacts to a test server and run some tests. This prevents other people from getting completely broken builds.
So, yeah Never ever ever check in class files into source control. Check in source. Setup a CI server that checks out the source, builds the jar/war/ear and deploys it to the environments.