10

Sorry, I'm quite a newbie at Git, and it is hard to find answers for such hard-to-phrase questions (at least for me) on Google.

Say my name is Joe, and I'm working on a software program with my colleague Bob.

We have the upstream Repo A and we have clones of Repo A on our local machines, where we code, commit, and push periodically to the same branch, say master. I know this is not technically the best way to do it, but for example's sake.

Now, what happens if we are both working on one file. Bob's local file that he did not yet push has the contents 

// awesome program
[some edits by Bob]

My local file that I did not yet push has the contents

// awesome program
[some edits I made]

Bob pushes, a second later I push. What happens now?

Is the file on remote going to be 

// awesome program
[some edits I made]

or

// awesome program
[some edits Bob made]

or perhaps, if there is a way to do it, I would like it to be

// awesome program
[some edits Bob made]
[some edits I made]

Sorry for the noobishness :(

Joseph
  • 1,003
  • 3
  • 11
  • 25

3 Answers3

9

Git will refuse your push. It will tell you there are new changes on the server, and make you do a pull before you can push. So, you'll end up with 

// awesome program
[some edits Bob made]
[some edits I made]

on your local machine. Then you'll be able to push that out to the remote.

mwarsco
  • 541
  • 4
  • 12
  • 1
    @JosephA., `git pull` is explicitly defined as `git fetch` followed by `git merge`. I very much recommend reading [this post](http://longair.net/blog/2009/04/16/git-fetch-and-merge/) for background. And one more thing: *please* read an introductory book on Git before seriously dabbling with it. Your question demonstrates lack of the most basic version control skills, and VC is a complicated task which requires thorough understanding of what you do. – kostix Jul 08 '16 at 18:33
  • 1
    @JosephA., pulling might also result in "antisocial" behaviour because it breaks "each feature is developed on a separate branch and then merged back into mainline" workflow which is usually *the* standard for serious projects. You can read [this explanation from the Git maintainer](https://git-blame.blogspot.ru/2012/03/fun-with-first-parent.html) for more background. Trigger-happy usage of `git pull` is what breaks the feature/bugfix branch workflow. – kostix Jul 08 '16 at 18:38
5

First: you can't push in a normal manner with a regular git push because when you were on local master your remote master has changed. so git propose you to do a force push with -f option. i.e. git push -f But Its not recommended to do force push on a shared branch unless you have a fair reason like interactive rebasing!

Second: By this message of git you are informed that something is happend to your remote repository so you do a git status and yes it tells that "Your branch and 'origin/master' have diverged, and have 1 and 1 different commit(s) each, respectively.". you should update your local repo; so you are doing a git pull or in this situation a better command, git pull --rebase and Surprisingly! Git also refuse your pull and tells that you have conflicts in example file. that's because both of you and Bob has editing the same file and the same lines!

Finally: See this link and resolve the conflict. you can keep your changes or Bob's or Both. then commit out the changes and git push to also update your remote repo. and that's it !!!

dNitro
  • 5,145
  • 2
  • 20
  • 45
  • You would need `git push -f` in the case of `interactive rebasing` because after you rebase, the commit SHA will also change. So even if the tip commit of your local has the **same name** as the tip commit of the remote branch, their SHA will be different, right? – Andrei Gătej Oct 06 '19 at 19:51
1

I'm not 100% sure that this is what you are looking to do, but when you commit, there should be a new revision created. Each new revision will replace the previous version. See if this info helps: Git Squash Commits

Community
  • 1
  • 1
Matt Jackson
  • 158
  • 9