FPC git concepts: what changed
Revision 1 to 2. Removed lines have a minus sign; added lines have a plus sign.
| Old | New | Line | |
|---|---|---|---|
| 1 | 1 | ## Differences between SVN and GIT | |
| 2 | 2 | ||
| 3 | 3 | This page describes some of the GIT concepts and differences to SVN. | |
| 4 | 4 | ||
| 5 | 5 | Subversion vs Git: [YouTube video, a brief overview of how git differs from subversion.](https://m.youtube.com/watch?v=Bb0_lO8N2yU) | |
| 6 | 6 | ||
| 7 | 7 | Information on using git can be found at either: | |
| 8 | 8 | ||
| 9 | 9 | - [[FPC git]] | |
| 10 | 10 | - [[SVN to GIT Cheatsheet]] | |
| 11 | 11 | ||
| 12 | 12 | The latter contains a section on why there are 2 pages, and how they differ. | |
| 13 | 13 | ||
| 14 | 14 | ## Local and Remote Branches | |
| 15 | 15 | ||
| 16 | 16 | Remote Branches | |
| 17 | 17 | reflect the branches on the server(s) at the time of the last synchronization (pull/push). They will only be updated when a synchronization takes place.\ | |
| 18 | 18 | Remote branches have names that contain their server: “remotes/gitlab/master”. | |
| 19 | 19 | ||
| 20 | 20 | Local Branches | |
| 21 | 21 | reflect your current work. They hold all the changes not yet uploaded. When you push, they will be added to the branch on the server, and the remote branch will be updated to reflect that.\ | |
| 22 | 22 | The local branches would just be called “master”. | |
| 23 | 23 | ||
| 24 | 24 | Local Branches can either be: | |
| 25 | 25 | ||
| 26 | 26 | - "tracking" a remote branch. They represent your work on the published branch, and your work will be pushed into the remote branch. | |
| 27 | 27 | - "non tracking", without a remote branch. Either for private work, or to create a new remote branch, or to later assign an existing remote branch. | |
| 28 | 28 | ||
| 29 | 29 | ### Naming of your local branches - Potential pitfalls | |
| 30 | 30 | ||
| 31 | 31 | It is good practice to keep the names of local branches equal to the name of their remote branch. However, **this is not enforced**. | |
| 32 | 32 | ||
| 33 | 33 | Local branches can be created with any name you choose. It is possible to create a local branch "master" to track "remote/fixes_3_2". | |
| 34 | 34 | ||
| 35 | 35 | This can happen by accident. Local branches can also be renamed or “moved”. The branch name is a marker for the content of a given branch. And this marker can be set from one branch to another branch. For example "git reset" can be used to move a branch like that. | |
| 36 | 36 | ||
| 37 | 37 | If in doubt use “git status” or “git branch --all --contain HEAD” to check your current local branch, and the remote branch to which it belongs. | |
| 38 | 38 | ||
| 39 | 39 | > **Note:** A branch is a marker/pointer to a commit.\ | |
| 40 | 40 | > From that commit you can then walk backwards using each commits links to its parent(s).\ | |
| 41 | 41 | > Branches do not need to have diverged from each other. One branch can simply be at an earlier commit of another branch. (Local Branches often build this way on their remote branches) | |
| 42 | 42 | ||
| 43 | 43 | ## The INDEX (and what it means for “git add”) | |
| 44 | 44 | ||
| 45 | 45 | The “index” is a pre-commit area, in which changes for the next commit can be collected. Using the index is optional. Users coming from SVN may prefer not to do so. | |
| 46 | 46 | ||
| 47 | 47 | svn add | |
| 48 | 48 | adds a new file by its name to the repository. When the file is committed, the file will be added as it is at the time of the commit. | |
| 49 | 49 | ||
| 50 | 50 | git add | |
| 51 | 51 | adds a new or existing file to the “index”. That is, it adds the current state (content) to the “index”. A later commit (depending on the command line arguments to "git commit") will add the content as it was at the time of "git add". **Any changes made between "git add" and "git commit" may not get committed**. | |
| 52 | 52 | ||
| 53 | 53 | git add -N | |
| 54 | 54 | can be used to just add the filename as in SVN. | |
| 55 | 55 | ||
| 56 | 56 | ## Conflict resolution when pushing to server | |
| 57 | 57 | ||
| 58 | 58 | SVN | |
| 59 | 59 | allows you to “svn commit” (send changes to server), even if you did not “svn update” to the latest commit.\ | |
| 60 | 60 | If the svn server has commits that you do not have, but none of that commit affects the files, that you are sending, then the server accepts your data, and moves your commit behind the existing other commits.\ | |
| 61 | 61 | This could mean, that you missed changes affecting your commit, and that the overall result is broken (not compile-able). | |
| 62 | 62 | ||
| 63 | 63 | Git | |
| 64 | 64 | expects you do first get all existing commits, and move your commit (see rebase or merge) to the end. Of course git can not force you to check that your commit is still good and compiles (hopefully you do anyway). | |
| 65 | 65 | ||
| 66 | 66 | Mimicking the svn workflow. You can | |
| 67 | 67 | ||
| 68 | - | ||
| 69 | - | ||
| 70 | - | ||
| 68 | + | ```text | |
| 69 | + | git pull --rebase | |
| 70 | + | git commit -m "message" file1 file2 … | |
| 71 | + | git push | |
| 72 | + | ``` | |
| 71 | 73 | ||
| 72 | 74 | In most cases, when you have local uncommitted changes, "git pull" will be able to put them on top of the newly pulled changes from the server. Doing commit directly followed by a push means you are likely to be still up-to-date when you push. In case there was an update between your pull and your push, repeat the "git pull --rebase" and "git push". | |
| 73 | 75 | ||
| 74 | 76 | If there are conflicts between your changes and those from the server, like in SVN you must resolve them. See the [[FPC git]] page. | |
| 75 | 77 | ||
| 76 | 78 | --- | |
| 77 | 79 | *From the Free Pascal wiki, page "FPC git concepts", as it stood on 2022-01-18 after a change by Alextp, out of the wiki's dump of 2024-05-26. Copyright stays with the author who wrote it, according to the old wiki's [[Licensing]] page. If you have concerns about this material, [message the admin](/wiki-contact).* | |
| 78 | 80 | Category: Version Control |