title: Git track external/public/remote branch while merging into local server
body: <p>I have a team with several members, and our work is based on another GIT repo, which we are not allowed to push. Let's call it repoA.</p>
  
  <p>We set up our own GIT server and the repo was initially cloned from repoA. Let's call the cloned repo repoB.</p>
  
  <p>Our team works on repoB but repoA keeps evolving. Team which maintains repoA don't care our work and don't want our code to 'pollute' their's, but we want to get their changes and merge them into our repoB.</p>
  
  <p>The so called 'merge' might be a little bit odd: we merge most of the changes in repoA into our repoB, but keeps some code unchanged, such as the methods we changed for our own requirement.</p>
  
  <p>And I also want the merge visible in the 'history tree', such as Git GUI's [Repository] --> [Visualize All Branch History], or Tortoise Git's [Show Log], so I can clearly know, at which day, from which commit, I made a 'synchronization' from repoA into my repoB. It would be better if I can have a 'merge line' shown in Git GUI and TortoiseGit's history map.</p>
  
  <p>I know some 'ugly' approach of doing it, for example:</p>
  
  <ul>
  <li>Pull repoA's master as my own master, but all my team commit and push
  to a branch called 'local_main'. Always pull repoA's master to my
  local master and then create a temporary branch 'pick_change', then
  switch to 'local_main' and merge 'pick_change', then remove branch
  'pick_change' locally, and push 'local_main' to my GIT server.</li>
  </ul>
  
  <p>With this way, I can:</p>
  
  <ul>
  <li>Pick useful code to my branch.</li>
  <li>Keep code I don't want there, without changing origin/master</li>
  <li>Clearly see a 'branch merge' curved line from master branch to my
  'local_main' branch in Git GUI or TortoiseGit's commit history graph,
  letting me know that there was a merge from that commit of
  origin/master to this commit of my 'local_main'.</li>
  </ul>
  
  <p>But is their any 'elegant' way of doing it?</p>
  
  <p>I think it should be a very common requirement, such as creating a private Linux core based on the public Linux project, change some code but still want to keep other portion up-to-date with the public Linux project, and clearly show the history that at this, this, this days, our project has aligned with that, that, that Linux core versions.</p>
  
  <p>The book 'ProGit' just provides some concept but seem no detail solution. Or anybody can let me know to which chapter of section shall I refer?</p>