If you want to keep the git repository of your project clean and predictive (which is highly recommendable), here is a simple workflow to follow.
\nFor the sake of this article, we are going to join the MongoDB project.<\/p>\n
When joining the project, the first step to get a local copy in your laptop:<\/p>\n
Once you do that, you have a copy of the source code locally. This is called the master:<\/p>\n Now, in a big project like this, you shouldn’t work directly to the master. It is often not permitted to push your change in the master. There should be a convention for the branch naming depending on the project. But as a rule of thumb, the branch name should be short, and self-describing. For our example, I’m going to change the MongoDB project documentation, so I call my branch “remove_obsolete_doc_part”.<\/p>\n You can see my local branches with that command:<\/p>\n And You can see all local branches (local in your laptop and remote from the project) with the next command. As you can above, there are many remote branches from the repository origin. But only two locals on your laptop.<\/p>\n Then, we need to switch the local files to our branch “remove_obsolete_doc_part”:<\/p>\n Now I made my changes on the code and I can see the state of my change:<\/p>\n I want to commit those changes:<\/p>\n We can see the current state of our local Git repo with that command:<\/p>\n And we can review the previous commits wiht that one:<\/p>\n Then we are ready to push our branch to the remote repository:<\/p>\n Once you like what you did, you can merge your code into the master branch. Prior to merging your changes from the branch “remove_obsolete_doc_part” to the master branch, you need to $ git pull #-------------------------> merge the remote code into your local code.<\/p>\n $ git fetch -p #-------------------------> optional but handy: it fetches remote branch other than the master and remove the local one that has been removed remotely. Then, you can merge your local branch “remove_obsolete_doc_part” into the local master branch:<\/p>\n At this stage, you may have conflicts because some parts of the code have been changed in the remote master copy while you were working locally. That’s perfectly fine and Git will show you the conflicting file in the staging area: `git status`. Just review the files and decide which part of the code you want to keep and commit.<\/p>\n The last operation conists in pushing your local copy of the master branch into the remote master so that everyone can enjoy Those are the minimum good practices you should follow if you plan to work on a project involving a few persons. For more significant projects, you’ll see other concepts like the “pull request” or “merge request”. Keep as much as possible your working branch in sync with the remote master. Ideally, execute full sync of your local copy before working on it every day:<\/p>\n Git collaboration: quick start If you want to keep the git repository of your project clean and predictive (which is highly recommendable), here is a simple workflow to follow. For the sake of this article, we are going to join the MongoDB project. First step: work safely on your branch When joining the project, the […]<\/p>\n","protected":false},"author":27,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[368],"tags":[2010],"type_dbi":[],"class_list":["post-14368","post","type-post","status-publish","format-standard","hentry","category-development-performance","tag-git"],"acf":[],"yoast_head":"\n
\n$ cd my_working_directory
\n$ git clone git@github.com:nico\/mongo.git
\n<\/code><\/p>\n
\n$ cd .\/mongo
\n$ ll
\ntotal 340
\ndrwxrwxr-x 13 nico nico 4096 Jun 25 08:59 .\/
\ndrwxrwxr-x 3 nico nico 4096 Jun 25 08:56 ..\/
\n-rw-rw-r-- 1 nico nico 6709 Jun 25 08:59 .clang-format
\n-rw-rw-r-- 1 nico nico 29 Jun 25 08:59 .eslintignore
\n-rw-rw-r-- 1 nico nico 795 Jun 25 08:59 .eslintrc.yml
\n-rw-rw-r-- 1 nico nico 308 Jun 25 08:59 .gdbinit
\ndrwxrwxr-x 8 nico nico 4096 Jun 25 08:59 .git\/
\n-rw-rw-r-- 1 nico nico 74 Jun 25 08:59 .gitattributes
\n-rw-rw-r-- 1 nico nico 2145 Jun 25 08:59 .gitignore
\n-rw-rw-r-- 1 nico nico 337 Jun 25 08:59 .lldbinit
\n-rw-rw-r-- 1 nico nico 588 Jun 25 08:59 .pydocstyle
\n-rw-rw-r-- 1 nico nico 1703 Jun 25 08:59 .pylintrc
\n-rw-rw-r-- 1 nico nico 193 Jun 25 08:59 .style.yapf
\n-rw-rw-r-- 1 nico nico 366 Jun 25 08:59 CONTRIBUTING.rst
\n-rw-rw-r-- 1 nico nico 13460 Jun 25 08:59 CreativeCommons.txt
\n-rw-rw-r-- 1 nico nico 30608 Jun 25 08:59 LICENSE-Community.txt
\n-rw-rw-r-- 1 nico nico 1987 Jun 25 08:59 README
\n-rw-rw-r-- 1 nico nico 9933 Jun 25 08:59 README.third_party.md
\n-rw-rw-r-- 1 nico nico 173224 Jun 25 08:59 SConstruct
\ndrwxrwxr-x 17 nico nico 4096 Jun 25 08:59 buildscripts\/
\ndrwxrwxr-x 2 nico nico 4096 Jun 25 08:59 debian\/
\ndrwxrwxr-x 2 nico nico 4096 Jun 25 08:59 distsrc\/
\ndrwxrwxr-x 2 nico nico 4096 Jun 25 08:59 docs\/
\ndrwxrwxr-x 4 nico nico 4096 Jun 25 08:59 etc\/
\ndrwxrwxr-x 33 nico nico 4096 Jun 25 08:59 jstests\/
\n-rw-rw-r-- 1 nico nico 570 Jun 25 08:59 mypy.ini
\ndrwxrwxr-x 2 nico nico 4096 Jun 25 08:59 pytests\/
\ndrwxrwxr-x 2 nico nico 4096 Jun 25 08:59 rpm\/
\ndrwxrwxr-x 5 nico nico 4096 Jun 25 08:59 site_scons\/
\ndrwxrwxr-x 4 nico nico 4096 Jun 25 08:59 src\/
\n<\/code><\/p>\n
\nWhat we should do instead is to work on a separate copy that is commonly called a branch.<\/p>\n
\nPreferably, it will refer to a task (Jira task, GitLab issue, GitHub issue, etc.).<\/p>\n
\n$ git branch remove_obsolete_doc_part
\n<\/code><\/p>\n
\n$ git branch
\n* master ------------------------> The star here tells you that you are currently in that branch
\n remove_obsolete_doc_part
\n<\/code><\/p>\n
\nYou’ll see two master branch, one called “remotes\/origin\/master” and one “master”. “master” is your local copy of
\nthe master, while “remotes\/origin\/master” is the remote copy. “Origin” refers to the repository you cloned the code from (“git clone “). <\/p>\n
\n$ git branch -a
\n* master
\n remove_obsolete_doc_part
\n remotes\/origin\/HEAD -> origin\/master
\n remotes\/origin\/count-trace-events
\n remotes\/origin\/f1b99df5
\n remotes\/origin\/master
\n remotes\/origin\/r3.4.14
\n ...
\n remotes\/origin\/v3.4
\n remotes\/origin\/v3.6
\n remotes\/origin\/v3.6.9-dbaas-testing
\n remotes\/origin\/v4.0
\n remotes\/origin\/v4.2
\n remotes\/origin\/v4.2.1-dbaas-testing
\n remotes\/origin\/v4.4
\n<\/code><\/p>\n
\n$ git checkout remove_obsolete_doc_part
\n$ git branch
\n master
\n* remove_obsolete_doc_part
\n<\/code><\/p>\n
\n$ git status
\nOn branch remove_obsolete_doc_part
\nChanges not staged for commit:
\n (use \"git add\/rm ...\" to update what will be committed)
\n (use \"git restore ...\" to discard changes in working directory)
\n modified: README
\n deleted: docs\/vpat.md
\n<\/code><\/p>\n
\n$ git add -A # ----------------> I add all my changes (-A) to the Git staging area (which means that will be committed at next commit time).
\n$ git commit -m \"Remove obsolete documentation\" # ---------------> I commit with a clear and short message of what I did.
\n[remove_obsolete_doc_part 1445bc4c6a] Remove obsolete documentation
\n 2 files changed, 141 deletions(-)
\n delete mode 100644 docs\/vpat.md
\n<\/code><\/p>\n
\n$ git status
\nOn branch remove_obsolete_doc_part
\nnothing to commit, working tree clean
\n<\/code><\/p>\n
\n$ git log
\ncommit 1445bc4c6a80a6dad5b285da4d5a81e9fa3a98cc (HEAD -> remove_obsolete_doc_part)
\nAuthor: nico
\nDate: Thu Jun 25 09:11:51 2020 +0000
\n Remove obsolete documentation
\n<\/code><\/p>\n
\n$ git push origin remove_obsolete_doc_part
\nEnumerating objects: 7, done.
\nCounting objects: 100% (7\/7), done.
\nDelta compression using up to 2 threads
\nCompressing objects: 100% (4\/4), done.
\nWriting objects: 100% (4\/4), 356 bytes | 178.00 KiB\/s, done.
\nTotal 4 (delta 3), reused 0 (delta 0)
\nremote: Resolving deltas: 100% (3\/3), completed with 3 local objects.
\nremote:
\nremote: Create a pull request for 'remove_obsolete_doc_part' on GitHub by visiting:
\nremote: https:\/\/github.com\/nico\/mongo\/pull\/new\/remove_obsolete_doc_part
\nremote:
\nTo github.com:nico\/mongo.git
\n * [new branch] remove_obsolete_doc_part -> remove_obsolete_doc_part
\n<\/code><\/p>\nSecond step: publish your contribution<\/h2>\n
\nThis can be done in different ways, and depending on the Git service provider, the philosophy can change.
\nFor this article, I’m going to merge with the Git command-line tool.<\/p>\n
\nsynchronize (pull) the remove master branch with your local one:<\/p>\n
\n$ git checkout master
\nSwitched to branch 'master'
\nYour branch is up to date with 'origin\/master'.<\/p>\n
\n<\/code><\/p>\n
\n$ git merge remove_obsolete_doc_part
\nUpdating 8b0f5d5e1d..1445bc4c6a
\nFast-forward
\n README | 5 -----
\n docs\/vpat.md | 136 ---------------------------------------------------------------------------------------------------------------------------------------
\n 2 files changed, 141 deletions(-)
\n delete mode 100644 docs\/vpat.md
\n<\/code><\/p>\n
\nyour changes:<\/p>\n
\n$ git push
\nTotal 0 (delta 0), reused 0 (delta 0)
\nTo github.com:nico\/mongo.git
\n 8b0f5d5e1d..1445bc4c6a master -> master
\n<\/code><\/p>\nConclusion<\/h2>\n
\nThat guarantee that you can backup regularly your code without impacting the main project.<\/p>\n
\nUsually, you won’t be able to merge your changes directly into the remote master. Instead, you’ll have to create a request to push your changes into the remote master, and someone else will decide to approve the merging of your code, reject it or comment it if it requires more changes before merging.<\/p>\nNotes<\/h2>\n
\ngit checkout master # Go the master branch
\ngit pull # Get remote master changes into the local master branch
\ngit checkout remove_obsolete_doc_part # Go back to your working branch
\ngit merge master # Synchronize your working branch
\n<\/code><\/p>\n","protected":false},"excerpt":{"rendered":"