1

We have colleagueA and colleagueB. Both download code from a GitHub repository and start to modify it, lets say app.py. Each one modifies different parts of the code in his own computer.

What is good git practice when merging both app.py into the final one to push it to the original repository?

I'm new to GitHub, I'd like simple answers if possible.

mike
  • 1,233
  • 1
  • 15
  • 36
user8920367
  • 95
  • 1
  • 5
  • 1
    Both have to work on a dedicated branch, because not recommended to work on master branch. Once colleageA and ColleagueB have finish to modify files. One of them can merge his modification to master. Then, the other must rebase his branch with master, using 'git rebase', solve conflicts and push the branch (using -f) before merging it to master too. – ogs May 20 '20 at 12:20
  • hi @user8920367, this user friendly article about how to use git merge may help - https://dev.to/neshaz/how-to-use-git-merge-the-correctway-25pd – mike May 25 '20 at 10:27

1 Answers1

1

If you are both pushing to the same branch (for example master), then the second one to push (say developerB) will fail, as in here, with:

hint: Updates were rejected because a pushed branch tip is behind its remote
hint: counterpart. Check out this branch and merge the remote changes
hint: (e.g. 'git pull') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

In that case, I recommend a git stash + git pull --rebase which will:

  • stash any current modification (not yet committed)
  • fetch the updated origin/master branch (with developerA app.py modifications
  • replay developerB local commits (which are not pushed, since the push just failed) on top of origin/master

(you can automate that git stash + git rebase process with a bit of configuration: see "Can “git pull” automatically stash and pop pending changes?")

If there are any merge conflicts, they will be resolved locally, on developerB's workstation, with local compilation and tests to validate that developerB's changes are working with what developerA has pushed.

Once the rebase is completed, a simple git push form developerB will work (assuming that developerA has not pushed again on the common branch)

You can avoid that of course by pushing to a dedicated branch for each developer, but you will need to reconcile those parallel development at some point.
At least, with the workflow I describe above, if both developers are participating to the same development effort, that reconciliation will be sooner rathen than later.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250