2

[EDIT: Question modified based on initial feedback]

I have a local git repo on my pc, to which I've been committing my own changes, I've been working on a single master branch.

Now, I need to let in another dev and I'm going to use the "bundle" method to collaborate in an "offline" fashion (see: Workflow and setup of a bare git repository for transferring project/changes/commits to offline repository on a seperate machine?).

So, I created a bundle like this:

cd myrepo
git bundle create repo.bundle HEAD master

and gave it to the developer. He, in turn, created the repo with and created his own branch master-other:

git clone repo.bundle newrepo
git branch master-other
git checkout master-other

He did some modifications and committed them. Now, say I want to import his mods back to me. The following command works fine:

git bundle create new_commits.bundle master-other ^ffffff

Now I am unsure what I want on the first machine which created the original bundle.

Do I want to import his changes with:

git pull new_commits.bundle master-other

This command creates a situation like this:

*   aaaaaaa (HEAD -> master) Merge branch 'master-other' of new_commits.bundle
|\  
| * bbbbbbb commit by other person 2
| * ccccccc commit by other person 1
* | ddddddd a commit I made after doing the bundle
|/  
* ffffff my last commit

Or do I want to create another branch called master-other and import his commits there and then merge back to my master branch?

Or something else?

The objective is to keep a working repo on my side, as well as giving back to the other developer my changes too.

Thanks a lot!

JoeSlav
  • 4,479
  • 4
  • 31
  • 50
  • I think this is what you're looking for: https://stackoverflow.com/questions/2888029/how-to-push-a-local-git-repository-to-another-computer – Héctor Aug 30 '18 at 09:55
  • but as far as I understand the methods listed in the question you link assume there is a shared folder / network access between the two pc. In my case I was trying to avoid that (devs in different locations, no common network). – JoeSlav Aug 30 '18 at 10:04
  • not answering the question -- but instead of sharing patches produced by `git diff`, try to use [`git format-patch`](https://git-scm.com/docs/git-format-patch) and [`git am`](https://git-scm.com/docs/git-am). The former will create a set of patch files and use the latter to apply/include them. Check this for more info http://alblue.bandlem.com/2011/12/git-tip-of-week-patches-by-email.html – fajran Aug 30 '18 at 10:57
  • Possible duplicate of [Workflow and setup of a bare git repository for transferring project/changes/commits to offline repository on a seperate machine?](https://stackoverflow.com/questions/49988724/workflow-and-setup-of-a-bare-git-repository-for-transferring-project-changes-com) – phd Aug 30 '18 at 12:14
  • https://stackoverflow.com/search?q=%5Bgit%5D+offline+workflow – phd Aug 30 '18 at 12:14
  • Thanks all for the feedback. I was able to implement part of this strategy but still have doubts. I've updated the original question. Thanks! – JoeSlav Aug 31 '18 at 16:56

2 Answers2

0

Or do I want to create another branch called master-other and import his commits there and then merge back to my master branch?

Actually, the git pull you just did already created a branch (albeit unnamed), and merged it to master, as your diagram illustrates.

If you want to import those commits directly on top of your current branch, do:

git pull --rebase new_commits.bundle master

The objective is to keep a working repo on my side

  • that will keep a working repo on your side

, as well as giving back to the other developer my changes too.

Simply make a new incremental bundle and repeat the process.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thanks VonC. If you want could you also provide some insights as to "what do I want to do?" I.e. what would be the best approach? Thanks. – JoeSlav Sep 01 '18 at 13:44
  • @JoeSlav I just did: the pull --rebase will keep everything on the same branch. You can then do a new incremental bundle (https://stackoverflow.com/a/12216898/6309) and repeat the process. – VonC Sep 01 '18 at 13:46
  • Is there any consideration you could share as to indicate why the git pull with --rebase is better for source control management than the git pull without the --rabase? Thanks – JoeSlav Sep 01 '18 at 14:14
  • @JoeSlav if you want to keep only one branch and avoid merge commits, that is the right option. If you want to integrate your colleague's work as one commit, then a regular pull is enough (as shown in your question). See https://www.atlassian.com/git/articles/git-team-workflows-merge-or-rebase and https://www.atlassian.com/git/tutorials/merging-vs-rebasing – VonC Sep 01 '18 at 14:44
  • Thanks. One last followup. How about me creating another branch and keeping the stuff from the other developer there? i.e. my repo and his repo would be equal? And also, if I rebase, will the colleague have issues when importing the new bundle from me, will he need to pull to the master or his master-other? – JoeSlav Sep 01 '18 at 18:11
  • @JoeSlav including your colleague work as a merge commit is a good practice if you don't want to see every intermediate commits he/she did. If you rebase, then your colleague will have to reset his/her master branch to the one you have rebased when pullling from the new bundle. – VonC Sep 01 '18 at 18:12
0

Is there a reason why you wouldn't use a privately published repository for this? Just curious. Seems like since you have been working alone and you want to bring in another collaborator, using a published repo would serve many purposes. I'm not flat-out advocating Github since there are other services like BitBucket and GitLab.

You each could have a fork of the project and submit pull requests for changes. Also, you'd beef up your redundancy by having 4 copies of the code (individual copies and 2 forks) instead of 2.

You both could largely work in isolation but come together with PRs as needed.

sublimegeek
  • 110
  • 1
  • 8