将iOS xcode文件提交到Github的一般规则

Question

I recently came across a situation where a colleague basically threw a fit when I committed about 12 *.h and 12 *.m and a bunch of images(assets) to github. The 12 files included a few .xib files. The total changes (including the images and xib xml code) came to around 985 changes. The 985 lines were mostly because the .xib files were getting converted to xml code. The colleague said that the checkin was too huge. I am a little surprised to see this reaction as I didnot think 24 files comprised was a HUGE checkin, or is this truly against the rules for committing to github. I have used SVN most of my life and worked in large teams where I never came across this issue. I am working on a 2 person team and a recent user to git. Am wondering if I indeed need to change the way I commit? Any suggestions?

-Thanks

Answer 1

I also read through the discussion, and what he is asking definitely looks like the exception, not the norm, especially for a small team of only two people. There are indeed some rules to go by, but they are just common sense for good software engineering. I don't want to go outside the scope of your question, because if we start talking about all the various uses for different types of branches, we could talk for days.

I would present an argument to your colleague by first discussing what you want to achieve by the commits, followed by an approach that can enable that to happen. And it should be a dialog--who knows, if your discussing his objectives, you may find that it is beneficial to go his route. Hopefully, you will find a common ground that satisfies all of the most important objectives. When you come to an agreement, you should draw up some guidelines together, and make a copy for both. It might seem easy to remember them at the time because they are logical, but at that same moment, you also might be making compromises that don't seem so logical weeks or months later.

Objectives

1. Developers should be able to go to a commit without the hassle of arriving at a point in the project that contains build errors. This also allows a more efficient, productive, and stress-free development environment.
2. Developers should be able to go to a commit with the confidence that it is without bugs. Any development that is built on buggy code, cannot be stable. It's like building a house--the foundation has to be solid, or everything built on top of it may crumble.
3. Developers should be able to go to any commit, and have a clear understanding of the contents and scope, by reading the commit comment.
4. Developers should be able to easily and quickly select a commit with confidence, without trial and error.

Approach

1. Commits should contain a cohesive set of files and code. This means implementation files should be committed with the header files and assets that go along with them. Otherwise, a commit could have build errors when implementation is calling methods that aren't yet declared, or a developer will be at a loss when looking at a declaration in a header that's not being used anywhere in the project. Your commits should tell a story of how you're progressing towards the end product. Each commit will affect how efficiently and accurately you can roll back to fix any bugs.
2. Do not do commit a project that doesn't successfully build.
3. Test your code, and retest. When introducing new objects in the repository, perform unit testing, starting with the objects that have the least number of dependencies.
4. If you are making a small change that is cohesive, and can tell a part of the development story, then go ahead and commit it. This will also allow you make a fresh start on a larger task, with the ability to reset changes to your working copy if something doesn't pan out, and you need to try something completely different.
5. Use tags if you have a lot of commits. A few tags that are set over hundreds of commits can save a lot of time, as they allow developers to quickly and easily select a commit, to begin to pin point the cause of a bug.
6. Branches can be used also, for features that require a lot of work. This allows multiple teams to work on multiple features simultaneously, without stepping on each others' toes. For a team of two, such as yours, this could also be beneficial, if you want to able to make multiple commits, on separate features. For some logical use cases for branches, take a look at Source Tree, and create some branches with their different options on a local repository. For me it was very instructional and provided a good framework for a lot of branching decisions.