1

I'm messing around with iOS development, and learned that Xcode now integrates with Git, but not SVN. So now I care about learning Git basics.

I don't particularly want distributed version control - perhaps centralization is just easier for me to wrap my limited brain around. But a quick browse later, I've found this: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow This is great! This is the workflow I'm used to!

But, while it shows me the commands, there's still some basics around the distributed nature of Git that I'm missing.

  • In SVN, I would check out N different instances (working copies) of the source, because maybe I'm working on more than one feature branch at a time.

  • In Git... I keep hearing I clone the repository. How do I map that idea to "I've got N working-copy instances going"?

  • In SVN, I commit some changes from my working copy to a feature branch at the central repo, and the commit will fail if I haven't first updated my working copy to head of the feature branch.

  • In Git... I'm guessing I can commit from my working copy to the feature branch in my local repo whether or not the local repo is up to date with the central repo? How do I push my change from the local repo to the central repo, and how do merge conflicts get bounced (especially if a change that's already committed to the local repo conflicts with a different change that's made it into the central repo?)

  • In SVN, I reintegrate a feature branch by:

    1. checking out (from the central repo) the develop branch (in the nomenclature of the Atlassian link) to a working copy
    2. Applying an SVN Merge of the changes in the feature branch (in the central repo) to my working copy of the develop branch
    3. Resolving any merge conflicts in my local working copy
    4. Committing my working copy to the develop branch (again, in the central repo)

  • What's that process look like in Git, especially around the resolving-merge-conflicts bit?

kaltorak
  • 73
  • 6
  • Welcome to Stack Overflow. Please take the [tour] and then read about what's on-topic in the [help/on-topic]. This question is currently _too broad_ (please [just ask one question per question](https://meta.stackexchange.com/a/39224/248627)) and likely _duplicates_ a number of existing questions (please search before asking). In general, though, it looks like you need to go through a few more Git tutorials. There are plenty out there written for people coming from other version control systems. Search the web for "git for svn users" or similar and go from there. – ChrisGPT was on strike Oct 27 '19 at 21:20

2 Answers2

0

. I keep hearing I clone the repository. How do I map that idea to "I've got N working-copy instances going"?

"N working-copy instances" would be using using the git worktree command: one cloned repository, multiple working trees.

How do I push my change from the local repo to the central repo,

By using git push

and how do merge conflicts get bounced

By using git pull, with the right configuration in order to rebase your local commits on top of the updated fetched branch.

(to do only once)

git config --global pull.rebase true
git config --global rebase.autoStash true

You can then resolve any conflicts directly from XCode.

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

In git you do things differently than in SVN and if you trying to mirror your SVN process you may be swimming against the current.

  1. The normal process in git is to have a repository which is a full copy of the remote repository (local and central repos are equals when it comes to what they contain) - this is git clone.

  2. git is very good at switching branches and you have a single checked out working tree.

  3. If you need to have 2 different branches checked out at the same time then:

    1. Change your process/setup so you don't need to, OR
    2. Get a 2nd copy of the central (remote) repo. Then you can check out two different branches since copy1 and copy2 are totally independent.

  4. The standard process for integrating your changes into the main/develop/master branches depends on your git strategy, and in the vast majority of setups it contains committing, pushing, merging steps. There is also a pull request steps.

Here is simple example:

  1. git clone - most of times you do that once. Now you have a repo which is...well...a clone of the central repo. They're equals: if someone looses the central repo your local copy will have all the history and branches that the central repo had (if your local repo has been kept up-to-date obviously).
  2. git checkout -b feature/branch1 - Create a branch where you'll do work
  3. Work work work
  4. git commit
  5. git push - now your changes are in the remote repo and they are safe - if your computer dies, the're not lost.
  6. git checkout develop - switch to target branch so that, in the next steps, we can get changes made by others into our feature branch to see if everything works together and resolve any conflicts.
  7. git pull - get changes made in the remote (central) repo merged into your develop branch (this should have no conflicts, because you did not work on the develop branch, it should be a fast-forward).
  8. git checkout feature/branch1 (no -b) switch to the feature branch to get ready for the merge.
  9. git merge develop - get others' changes into your branch.
  10. git push - make the remote repo contain have your branch with merged changes from develop
  11. Now this is where things differ depending on if you use pull requests or not.
    1. If you use pull requests, which are not a git feature (they're on top of git) then you would create a pull request (via a web tool most likely, or maybe your IDE) and then someone would review your changes and merge them into develop - there should be no conflicts because your integrated develop to your branch recently.
    2. If you're not using pull request then you would checkout develop, merge your branch and push develop to the central repo.

Please note you can tweak some these steps as you get more proficient.

tymtam
  • 31,798
  • 8
  • 86
  • 126