59

I am learning git and I have a scenario:

  1. My coworker makes changes and pushes the changes to the master.
  2. I make changes locally to my master.

So far from my understanding, at this point I can either:

  1. Pull the master that my coworker worked on and fix the merge conflicts that I will end up having.
  2. Create a back up of my local, clone a new copy of the master, and then merge my changes to the master.

I want to know if there is any better way of doing this.

k0pernikus
  • 60,309
  • 67
  • 216
  • 347
Asim Mahar
  • 1,320
  • 1
  • 10
  • 13
  • 9
    certainly the first scenario is the preferred one. I'd say the only one. – user3159253 Jan 26 '16 at 22:55
  • do you have any specific problem with it? – user3159253 Jan 26 '16 at 22:55
  • 1
    I would recommend creating a new branch every time you want to add a feature. Then when your branch is ready to merge into master, start by pulling the latest version from origin. That way it's cleaner, you don't have to deal with the merge conflicts while doing the pull. – Biniou Jan 26 '16 at 22:57
  • Better how? What is your current problem and what do you expect for it to be different? Just asking for `better way to do x` is opinion-based and slightly off-topic. – k0pernikus Jan 26 '16 at 23:42
  • @user3159253, not any specific problem. Something I came across at work and just wanted to learn if there was any other way to merge changes when two people have worked on it. – Asim Mahar Jan 27 '16 at 02:52
  • @k0pernikus, you are right. I guess it could be opinion-based. But I mainly for sake of learning wanted to know if there were any other methods or the ones I had put down were industry accepted. – Asim Mahar Jan 27 '16 at 02:56

5 Answers5

54

If there are different changes on both the remote and the local branch, instead of just pulling the master by git pull, I rather would do:

git pull --rebase

I even have it in my default config so that it will always will do a rebase if required on git pull:

git config --global pull.rebase true

A rebase avoids a merge commit and keeps your changes on top of the current remote branch.

Yet you still have to resolve any occurring merge conflicts when different people are working on the same branch, which is a bad practice especially because it leads to conflicts.

(Also be aware that in the scope of a rebase, the meaning of theirs and ours is switched.)

In cases with minor changes, yours are just applied on the top.

You are changing the history, yet only your local one, not the remote's.

You won't need to git push --force. You just git push it as you are used to it.

In general, you should be working on feature branches and merge those back to the master branch.

When working on feature branches one can also keep the feature branch close to the master by:

git checkout feature-branch
git fetch && git rebase origin/master

Yet here one would need to git push --force the feature-branch, so one should be careful not to use this strategy if more than one person is working on the same feature-branch.

If one wants to use rebase and push forcing, consider using git push --force-with-lease over git push --force as it prevents accidentally deleting other's commits on the remote.

k0pernikus
  • 60,309
  • 67
  • 216
  • 347
  • I am going to do a test with 'git pull --rebase' as the `rebase` is a new concept to me. Thanks. – Asim Mahar Jan 27 '16 at 03:11
  • @AsimMahar Rebase is one of the most powerful features of git and I use it often, yet also a great way to shoot yourself in the foot. So be sure to understand the implication of using it. – k0pernikus Jan 27 '16 at 22:02
  • @k0pernikus, i just got in the same situation as OP, found your answer, tried to "git pull --rebase" and it says "error: cannot pull with rebase: You have unstaged changes. Please commit or stash them". What did i do wrong? Thx in advance – lucifer63 Jul 13 '18 at 10:25
  • @lucifer63 Please ask follow up question on their own and not in comments. You could link this answer there and also leave a comment here linking to your question. That being said: The help text basically already provides your soluition: Either commit your current unadded and uncomitted (aka unstaged) changes or run stash `git stash && git pull --rebase && git stash apply`. – k0pernikus Jul 13 '18 at 10:30
  • @k0pernikus, i'm just new to stash/rebase features. Thanks for the help and especially for the "unadded and uncomitted (aka unstaged)", it explained a lot! – lucifer63 Jul 13 '18 at 10:42
  • @k0pernikus: what does --rebase do ? – Nike Nov 02 '18 at 08:34
  • @user1271772 Or more generic: https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase – k0pernikus Nov 02 '18 at 16:14
8

One (simple*) way to handle this without branching or stashing:

  1. stage/commit your changes locally
  2. pull remote
  3. at this point you'll be notified of any merge conflicts. If git cannot automatically resolve merge conflicts, it will open the two versions in whatever editor you have set up as your default merge editor. I recommend BeyondCompare.
  4. commit your merge, push your merge and commits remote master
Patrick Motard
  • 2,650
  • 2
  • 14
  • 23
  • how to add customized commit messages when commiting after the conflicts resolving in Github Desktop? – Charles Jan 25 '22 at 03:50
5

Best way from my experience is:

  1. When working on a new feature, make a new branch cloned from the master. Always keep the branches up to date with the master.
  2. After writing and committing your new features to the created branch, you test your app.
  3. Then merge master into the working branch, if there are new commits in the master, you may have merge-conflict. After resolving it - test again.
  4. If everything is working as supposed to merge your branch to the master.

That's how you can develop many new features and merge only the working ones when you need to deploy. Good luck and check this -> https://www.codeschool.com/courses/try-git

melatron
  • 51
  • 2
2

I believe git sync would be good. Git sync commits your changes, pulls any changes existing in master, then pushes all the changes together to master.

HappyCoding
  • 641
  • 16
  • 36
0

If you're both working on the same file(s), you'll inevitably run into conflicts. You'll just have to learn how to resolve conflicts.

If you want to avoid having to resolve conflicts, then maybe you guys should delegate tasks to each other that involve working on a different files.

Jared Price
  • 5,217
  • 7
  • 44
  • 74