4 ms·

Set up a repo on a server somewhere and declare it to be the "central repo". You and the other developer pull/push from that repo only. In other words, ignore

by Crito 13y ago

Set up a repo on a server somewhere and declare it to be the "central repo". You and the other developer pull/push from that repo only. In other words, ignore some of git's capabilities and treating git like SVN. Just because you can pull from your teammates, does not mean that you have to. I've been on a team that transitioned from SVN to Perforce, the again to Git, keeping the same workflow all the way through. It isn't the way that I prefer using git, but it works perfectly well.

lmm 13y ago
> Set up a repo on a server somewhere and declare it to be the "central repo" That's the situation I described. We still have the problems I mentioned: sometimes we commit without pushing (particularly because we sometimes didn't set a branch to be remote-tracking and didn't realize this), and sometimes our branches are behind our copy-of-the-remote-branch because we pulled different branches (which leads to bogus merges in the history).
- Crito 13y ago
  Committing without pushing is not a problem (unless you intended to push but forgot to?) It is not a concept that necessarily exists in traditional centralized version control systems, but the fundamental problem still exists. In SVN "forgetting to push" is just called "forgetting to commit". If your team member forgot to push and you put out new changes, that is a problem for him to resolve. If you forgot to push, and your team member put out new changes, that is a problem for you to resolve. Workflow wise, this all works the same as it does with any other centralized workflow. If you forget to check for updates... well that is something that happens in other centralized schemes as well. You figure it out when you go to push and it fails, you correct it, then you are good to go.
  - lmm 13y ago
    > Committing without pushing is not a problem (unless you intended to push but forgot to?) It is not a concept that necessarily exists in traditional centralized version control systems, but the fundamental problem still exists. In SVN "forgetting to push" is just called "forgetting to commit". Sure, but you hit the problem twice as often in git, because you have to do twice as many things. > If you forget to check for updates... well that is something that happens in other centralized schemes as well. You figure it out when you go to push and it fails, you correct it, then you are good to go. In SVN that doesn't show up as a merge in the history.
    - NickNameNick 13y ago
      In SVN, that shows up as a conflict which has to be merged by hand. 'git rebase' and/or 'git mergetool' are nicer.
    - Crito 13y ago
      > "Sure, but you hit the problem twice as often in git, because you have to do twice as many things." Well no, I don't... If this really is a frequent problem for you, then you might want to consider adding a note to the end of git-commit's output to remind you to push, or even just aliasing git-commit to push by default. I would recommend that you instead learn how to use git, but failing that... > "In SVN that doesn't show up as a merge in the history." If you don't want to resolve those situations with a merge, then don't resolve those situations with a merge... Rebasing exists for a reason.
    - __david__ 13y ago
      > In SVN that doesn't show up as a merge in the history. You might like "git pull --rebase"
- mattengi 13y ago
  Don't pull origin/master directly into local feature/test branch. Pull into local master then rebase local branch onto it.
  - lmm 13y ago
    This goes against all the advice I've seen elsewhere; we push our feature branches all the time, and sometimes pull from each other's if we're working in overlapping areas, so we need to not rebase them.
    - Crito 13y ago
      If that's what you want to do, that is fine, but you are no longer using a centralized process if you do it that way. Git allows you to follow a centralized process perfectly fine. However if you choose to not follow a centralized process, it will not force you to.

by Crito 13y ago

lmm 13y ago

> Set up a repo on a server somewhere and declare it to be the "central repo" That's the situation I described. We still have the problems I mentioned: sometimes we commit without pushing (particularly because we sometimes didn't set a branch to be remote-tracking and didn't realize this), and sometimes our branches are behind our copy-of-the-remote-branch because we pulled different branches (which leads to bogus merges in the history).

Crito 13y ago
Committing without pushing is not a problem (unless you intended to push but forgot to?) It is not a concept that necessarily exists in traditional centralized version control systems, but the fundamental problem still exists. In SVN "forgetting to push" is just called "forgetting to commit". If your team member forgot to push and you put out new changes, that is a problem for him to resolve. If you forgot to push, and your team member put out new changes, that is a problem for you to resolve. Workflow wise, this all works the same as it does with any other centralized workflow. If you forget to check for updates... well that is something that happens in other centralized schemes as well. You figure it out when you go to push and it fails, you correct it, then you are good to go.
- lmm 13y ago
  > Committing without pushing is not a problem (unless you intended to push but forgot to?) It is not a concept that necessarily exists in traditional centralized version control systems, but the fundamental problem still exists. In SVN "forgetting to push" is just called "forgetting to commit". Sure, but you hit the problem twice as often in git, because you have to do twice as many things. > If you forget to check for updates... well that is something that happens in other centralized schemes as well. You figure it out when you go to push and it fails, you correct it, then you are good to go. In SVN that doesn't show up as a merge in the history.
  - NickNameNick 13y ago
    In SVN, that shows up as a conflict which has to be merged by hand. 'git rebase' and/or 'git mergetool' are nicer.
  - Crito 13y ago
    > "Sure, but you hit the problem twice as often in git, because you have to do twice as many things." Well no, I don't... If this really is a frequent problem for you, then you might want to consider adding a note to the end of git-commit's output to remind you to push, or even just aliasing git-commit to push by default. I would recommend that you instead learn how to use git, but failing that... > "In SVN that doesn't show up as a merge in the history." If you don't want to resolve those situations with a merge, then don't resolve those situations with a merge... Rebasing exists for a reason.
  - __david__ 13y ago
    > In SVN that doesn't show up as a merge in the history. You might like "git pull --rebase"
mattengi 13y ago
Don't pull origin/master directly into local feature/test branch. Pull into local master then rebase local branch onto it.
- lmm 13y ago
  This goes against all the advice I've seen elsewhere; we push our feature branches all the time, and sometimes pull from each other's if we're working in overlapping areas, so we need to not rebase them.
  - Crito 13y ago
    If that's what you want to do, that is fine, but you are no longer using a centralized process if you do it that way. Git allows you to follow a centralized process perfectly fine. However if you choose to not follow a centralized process, it will not force you to.