64

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.

rynd
  • 1,865
  • 5
  • 22
  • 24
  • 8
    Another big advantage of a remote repository (or centralized one, if not using Git) is backup - in case the local storage is damaged. From the backup perspective, frequent pushes minimize potential data loss. – David Airapetyan Dec 29 '14 at 15:56

4 Answers4

63

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.

Alexander Derck
  • 13,818
  • 5
  • 54
  • 76
acattle
  • 3,073
  • 1
  • 16
  • 21
  • 31
    I disagree with your statement about the integrity of local commits. Quite often I make work-in-progress commits locally on my branch, or ad-hoc commits, with the intention of rebasing and cleaning up (squashing, reword, reorder, etc etc) my branch prior to pushing. IMHO it's your push to a remote that expresses a commitment to the quality and finalization of your changeset. – void.pointer Apr 29 '15 at 16:30
  • 16
    What if the dev machine that has local repo crashed? – Michael Sync Dec 17 '15 at 23:24
  • In old days before github, I think it was the best practice to commit to the version control often. It also prevent from losing the code if the dev laptop/machine crash. but ya. I don't push that often since I started using git. – Michael Sync Dec 17 '15 at 23:26
  • 3
    I strongly believe source control systems should be considered as such and not as a backup solution. It is a mean, not an end in itself. I've seen people consider their SC as an actual backup solution and do meaningless commits with code that breaks the entire software, stating "I wanted to backup my code before the week end". Also, trying to read through the commit history of such systems is a nightmare. – Jerther Feb 23 '17 at 16:46
  • @Jerther surely this is what a stash is for? – m.edmondson Sep 24 '20 at 16:01
  • 1
    @m.edmondson Indeed. Except AFAIK a stash is stored locally. – Jerther Sep 25 '20 at 18:23
  • For backup purposes i guess you can use a different private remote, commit as you like and push there, when it comes time to push to the real remote do interactive rebase and fix your commits. Now you can push to the real remote and also force push to your private backup remote. I haven't tested this but on theory it should work. Feel free to test. – Lyubomir Sep 24 '21 at 22:24
19

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.

earlonrails
  • 4,966
  • 3
  • 32
  • 47
  • 2
    "you have to play nice with others" - I see, that's the substance of this topic. Few people are interessted in seeing every little change I made. – rynd May 12 '12 at 16:52
  • As far as that goes I recommend a code review tool, git diff, and or gitx and gitk. Here is a post about the code review tools for git. http://stackoverflow.com/questions/3713103/best-code-review-tool-for-git/10434975#10434975 – earlonrails May 12 '12 at 18:00
8

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.

jack.py
  • 362
  • 8
  • 23
Dmitry Pavlenko
  • 8,530
  • 3
  • 30
  • 38
  • Are you *really* always working on the same code as other people such that one or two commits is enough to introduce a conflict that you need to address? – Burhan Ali May 13 '12 at 11:59
  • 1
    Not always, but periodically such situation happens (I can't say that very often), and this is annoying, so I prefer to avoid it. 90% of all conflicts are caused by java imports. – Dmitry Pavlenko May 13 '12 at 12:34
6

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.

Yifan Sun
  • 772
  • 1
  • 10
  • 25