Do you push every single commit?

Question

I would like, if someone could give me more detail in working with git and remote repositories. I haven't worked with remote repositories, yet.

To the local repository you commit smaller changes that may not be too world-shattering. What is pushed to the remote repository? Every local commit? Or the overall-work that was done, which is then merged with overall-works of others? I think the log of the remote repository must be confusing, if everyone pushes every commit.

Solution 1

Pushing and Pulling from the remote repository isn't quite as important as your local commits. Typically pushing and pulling a few times a day is sufficient. Like @earlonrails said, more frequent pushes means less likelihood of conflicting changes but typically it isn't that big a deal.

Think of it this way, by committing to your local repository you are basically saying "I trust this code. It is complete. It runs. I have tested it. I am ready for other people to see it." If you want to push to the remote repository after every commit, that's fine but as long as you do it on a regular basis it doesn't really matter.

Local repositories are about tracking your changes to protect the work you do. Remote repositories are for distributing the work to all your teammates and tracking everyone's changes. Your teammates need access to your code, but usually it isn't urgent and can wait until the end of the day or whenever you feel like pushing.

Solution 2

You can push to remote at your convenience. The only problem with pushing a bunch of commits at one time is that you may need to merge more conflicts with more affected files. If you are new to git I recommend git ready.

Remotes work just like the local repo, but you have to play nice with others. If other people push to remote before you push. Then their changes will have to be pulled by you before you can push. If you both touch the same file, since their change was in first you will need to merge the two changes together.

Solution 3

I try to push every local commit as it is possible (I use Git). Rarely I have 2 or more commits locally. Otherwise, there's a risk of conflict that are not so pleasant to solve.

I prefer to use rebase rather than merge, to keep the history more linear. If I have 2 commits A and B (B is older) locally, and B conflicts with upcoming changes, after resolving conflicts on rebase I have to checkout B, check compilation, maybe run tests, and only then switch to A and push that all.

That's why I prefer to push everything I have as soon as possible. Note that these problems arise mostly while dealing with large codebases with several other people.

Solution 4

I generally disagree with the best answer and some comments. Neither commits nor push has to be responsible for the quality of the code.

In the svn age, everyone works in the same branch. Failure in your code soon propagates to others. In this case, you definitely have to guarantee your quality of code, and that is the reason why svn is being replaced by git in many companies and organizations.

We need to make clear what is a typical Git workflow. Suppose your master branch has a somehow workable version of the software. Some people prefer to use the master branch as release branch, while others use it as the development branch. It does not matter. Whenever you need to add a feature or fix a bug, you create a branch from the master (or another) branch. The feature should be small enough to be handled without involving extensive modification to the codebase. In case of large modification, layers of branches should be created, so that the last layer of the branch is small enough.

If each branch is to add a small feature, it is not very likely to have many people working in the same branch. If more than one people working on one feature, that group should be very small and communicate very often, and hence, conflict should be easily fixed. If one commit or a push has a problem, only you or your small team will have a problem.

Then where we should guarantee the quality of the code. My answer is the pull requests. In Github, you modify the code and submit a pull request. By the time you submit the pull request, you need to guarantee that your code can compile and pass the tests. In Gitlab, you create a merge request before you modify the code, but mark with WIP (work in progress). Then you modify the code. Before you remove the WIP mark, you need to guarantee that your code is of good quality. Also, the code reviewer will be another layer of protection.

Conflicts should rarely happen in your branch, but it can happen when you merge your branch to the base branch. You should fix it right before that merge happens.

The only thing is related to rebase. Many developers like to rebase their branch before submitting a merge conflict to make the git commit history looks better. If you pushed to the remote and others used your code, rebase causes nasty problems to fix. However, if you always work on a branch that only fixes a small feature, no one should want to use your branch anyway. Also, I personally do not really like rebasing as it modifies the history.

So my conclusion is similar to others, commit often and push often, but for a different reason.

View more solutions