#sourcetree

[gift-by-gifted]

【Sourcetree】マージ時に「fatal: You have not concluded your merge (MERGE_HEAD exists).」エラーの対処方法

Sourcetree を使用している際、マージ作業中にfatal: You have not concluded your merge (MERGE_HEAD exists). Please, commit your changes before you merge.というエラーメッセージが表示されることがあります。このメッセージは、以前のマージ作業が完全に終了していないため、新たなマージを開始できない状況を示しています。 この問題は、マージ作業を一度開始した後、何らかの理由で変更を破棄し、HEAD 情報だけが残ってしまったことが原因で発生します。このような状況に直面した場合、以下の手順で対処することができます。 ターミナルを開く: Sourcetree のメニューバーから「操作」を選択し、「ターミナルで開く（control （^）+ command （⌘） + T…

[dotrinh1203]

Sau khi merge có nên xoá nhánh?

Sau khi hoàn thành việc merge một nhánh (branch) vào nhánh chính (thường là master hoặc main) trong Git, quyết định có nên xóa nhánh đó hay không phụ thuộc vào mục đích và quy trình làm việc của dự án. Dưới đây là một số lý do và tình huống khi việc xóa nhánh có thể là lựa chọn hợp lý: Lý do nên xóa nhánh sau khi merge: Tránh rốI rắm: xóa nhánh sau khi merge giúp giữ cho danh sách nhánh của dự…

[willcodehtmlforfood]

Arcom amikor épp emésztek a gép előtt és rámpingel valami random arc a cégtől h lennék szíves ápdételni a visual studiomat meg s sourcetree app-ot when I get a chance

(nem segített h kicsit hangosra van állítva a minden és megijedtem)

[sabbitabbi]

If someone tells you that gamedev is pretty easy, actually, send them your Sourcetree after it got fucked up beyond human comprehension for no reason to keep them occupied for at least 3 weeks

[umpro2025]

メタバーログ第15回

6回目の担当者、リンです。

今回は、以下のことを行いました。

・sourcetreeを正しく扱えれているかの再確認

・中間発表までに作成する物および作業の役割分担の決定

・作成する物の順番決め

今までsourcetreeの扱いに苦しめられていたので、今回ようやく解放されました。誰がどの機能を開発するかを決定し分担したため、ここからは個別に開発を進めていきます。次回からは、進捗具合の報告がより深みを増すと思います。

では、また今度

[web-scraping-tutorial-blog]

5 useful tools for engineers! Introducing recommendations to improve work efficiency

Engineers have to do a huge amount of coding. It’s really tough having to handle other duties and schedule management at the same time. Having the right tools is key to being a successful engineer.

Here are some tools that will help you improve your work efficiency.

1.SourceTree

“SourceTree” is free Git client software provided by Atlassian. It is a tool for source code management and version control for developers and teams using the version control system called Git. When developers and teams use Git to manage projects, it supports efficient development work by providing a visualized interface and rich functionality.

2.Charles

“Charles” is an HTTP proxy tool for web development and debugging, and a debugging proxy tool for capturing HTTP and HTTPS traffic, visualizing and analyzing communication between networks. This allows web developers and system administrators to observe requests and responses for debugging, testing, performance optimization, and more.

3.iTerm2

“iTerm2” is a highly functional terminal emulator for macOS, and is an application that allows terminal operations to be performed more comfortably and efficiently. It offers more features than the standard Terminal application. It has rich features such as tab splitting, window splitting, session management, customizable appearance, and script execution.

4.Navicat

Navicat is an integrated tool for performing database management and development tasks and supports many major database systems (MySQL, PostgreSQL, SQLite, Oracle, SQL Server, etc.). Using Navicat, you can efficiently perform tasks such as database structure design, data editing and management, SQL query execution, data modeling, backup and restore.

5.CodeLF

CodeLF (Code Language Framework) is a tool designed to help find, navigate, and understand code within large source code bases. Key features include finding and querying symbols such as functions, variables, and classes in your codebase, viewing code snippets, and visualizing relationships between code. It can aid in efficient code navigation and understanding, increasing productivity in the development process.

[havendance]

Not only is my batman read through currently at Morrison doing Batman RIP revisited but also sourcetree hates me

[rttnpnkpmpkn]

When you think you know how to push things to a private repo with Sourcetree, but it still won't do the thing ;w;

I need to eventually learn how to back up my work to the cloud for big projects because I can't trust myself to take good care of the physical drive my shizz is on lolll o|-<

[kaobei-engineer]

#純靠北工程師8on

----------

跟主管要討論處理git的分支 結果工作列要按SourceTree 卻按到了Discord 偏偏又顯示 不獸控制的色圖頻道...... 這兩個圖標為什可以這麼像 乾

----------

💖 純靠北工程師 官方 Discord 歡迎��這找到你的同溫層！

👉 https://discord.gg/tPhnrs2

----------

💖 全平台留言、文章詳細內容

👉 https://init.engineer/cards/show/11255

[meeeeeeeeeem]

sourcetree is evil and fucked up and i wish i hadnt switched from github desktop

[aitoolswhitehattoolbox]

Software engineer, AVP

complex, analytical and numerical problems. You’ll also need: At least eight years of experience in Android or IOS Good… experience in Swift UI, Objective C, UIKit, Xcode, GitLab/SourceTree, Java, Kotlin, Android common libraries stack like OKHttp… Apply Now

[luvcraft]

If you're afraid of the git, remember the SourceTree rainbow

I'm confused when I see people talk about how complicated and overwhelming Git is; I think it's great, and generally really straightforward.

So I thought maybe I'd talk about how I use Git, and see if it helps others understand it better.

There are going to be exceptions to pretty much everything I say here, but what I say here is "true for the most part".

First and foremost, install SourceTree (https://www.sourcetreeapp.com/), and set the file windows to "tree view". SourceTree is a free GUI for Git, and it's available on both Mac and Windows. Because I use it I never have to use command-line git, which I suspect is what overwhelms a lot of people.

To make a new git project, go to github.com and create a new project, and it'll give you a URL that points to the project. Copy that URL, go into SourceTree, and tell it to "clone" a project from a URL. Give it that URL, and tell it where on your computer you want to put the project, and you should be all set.

Although Git is primarily designed for programming, it can be used for pretty much any kind of creative project you do on a computer; the only caveat is that you can't have a single file larger than 100mb. But you can have over 100mb spread out over multiple files.

I'm gonna talk about git in "levels", from the simplest use case to more complicated use cases. Once you've read a high enough level to do what you want to do with it, you're welcome to bail out.

Level 1: Backup

At it's most basic, git is an easy way to do frequent backups. If you've been making stuff on a computer for a while, then you probably have a normal routine of backing up what you're working on in case something terrible happens.

There are three steps to backing up data via git: stage, commit, and push.

Staging is where you choose which files you want to backup. Typically this is everything in the folder you're working in. In the "File Status" view in SourceTree, the screen is split into "Staged Files" and "Unstaged Files". Clicking the checkbox next to an unstaged file moves it to staged, and vice versa. Once you've staged the files you want to backup, you (optionally) type a little note in the note field at the bottom, and click "commit".

Commiting means you're telling the part of git that runs on your computer to backup all the staged files. If "push changes immediately" at the very bottom is checked, then SourceTree will automatically push when you commit. Otherwise you have to hit the big "push" button at the top to push.

Pushing just sends your commits from your computer to the server. Once you've pushed your commit, you're all backed up, and if your computer explodes (or you just want to access your project from a different computer), you can install SourceTree on your new computer, "clone" that same URL from github, and then "pull" (the opposite of "push") to bring your project down from the server to your computer.

If all you want to do is have an easy way to regularly backup a project, then that's it! But if you wanna do more stuff, then read on.

Level 2: History

The next useful part of git is history; if you've ever looked at the history feature of Google Docs, then you have an idea what to expect.

After you've made a few commits, you'll see a list of commits in SourceTree, with your little notes next to them. If you click on one of these commits, it'll show you everything you changed in that commit. For text-based files, it'll even show you changes you made to individual lines of text.

If you've made a change and decide later that you don't like it and want to go back, you can do that via History. If it's just a few lines of a text-based file, you can highlight and copy the old lines and paste them into the current file. If you want to reset a whole file, then you can go to a commit before you changed it, right-click on it, and choose "reset to this commit".

Level 3: Branches

History is good for when you change your mind about something after the fact. If you know in advance that an idea may or may not work, or you want to do something risky without any of the risk, then you can use branches.

To make a branch, just click on "branch" at the top, and name your branch after whatever crazy thing you're gonna try in your branch. Then continue to work as normal, and everything will go in that new branch instead of the "main" branch. You can switch back and forth at any time by just double-clicking the branch you want in the "branches" list (just be sure to commit anything you want to keep before switching).

If you want to copy the changes to a single file from one branch to another, you can right-click on it and choose "reset to this commit", just like you did in the History section above. If you want to combine everything in two branches together, then keep reading.

Level 4: Merging

If you want to mix all of the changes and new stuff from one branch into another branch, that's called "merging". Don't use the big "merge" button next to the "branch" button; it's confusing and weird. Instead, in the branches list, right-click on the branch you want to merge into your current branch, and choose "merge into current branch", and then check "create merge even if fast forward is possible" in the dialog that appears and hit "OK".

In most cases, the two commits will just nicely merge together.

If you've been switching back and forth between them, and making different changes to the same files in both, then it might tell you there's a "conflict" and it can't figure out how to merge the two versions of that particular file. In this case, just right-click on the file in staging, and choose either "resolve using mine" (i.e. the version in the current commit) or "resolve using theirs" (i.e. the version in the other commit).

If the file you're merging different versions of is a text file, then git will do its best to combine the changes you've made to it, but you should double check to make sure they look good. If git can't figure out how to merge a text file, then it'll show you specifically where it's having trouble, and you can either do the "resolve using mine / theirs" method above, or choose "resolve using external merge tool", at which point it'll open up a separate program (if you have one installed) that you can use to manually fix the conflicts.

If you do use an external merge tool, keep in mind that it might leave behind extra files with extensions like ".orig", and you can just delete those.

Level 5: Pull Requests

OK! Everything so far has pretty much been about using git solo. Pull requests are about using git on a team. They're primarily used for bug fixes, or adding new features, and here's how they work. If you want to fix a bug, or add a new feature, you make a new branch with a name like "fix-for-bug-x" or "feature-y", and you work on your bug / feature in the branch. When you're ready to add your bugfix / feature to the main project you make a pull request.

If you've pushed a commit of your branch in the last hour or so, and you go to your project's github, you'll see a handy notification at the top asking if you want to make a pull request of your branch. Go ahead and do that, and then type in a good title for your request, and a description of what you did, and then hit the button to create it.

Then ask your team to take a look at it, and they'll see a nice detailed breakdown of everything you changed. If they have questions or comments about individual lines of what you've written they can leave notes, and then if you need to you can make and push changes to the branch and it'll automatically update the pull request.

Once everyone's happy with the pull request, there's a handy button in the github UI to merge it, and then it'll give you the option to delete the branch once it's merged (which I recommend for things like bug fix branches which you're never going to make any more changes to).

And that's everything you need to know!

There's a lot of other, more complicated stuff that git can do, but this is everything that someone would typically need to know to use it.

I realize this is a terrifying wall of text, but hopefully you bailed out after the section that taught you what you needed to know, and feel less overwhelmed by git.

[git-codes]

Mastering Git Merge: A Comprehensive Guide to Version Control and Collaboration

Merging in Git plays a key role in version control. It combines changes from different branches into one. A merge allows teams to work on features independently and then bring them together. This process helps keep projects organized.

There are different types of merges in Git. A fast-forward merge happens when there are no changes on the base branch since branching off. In this case, Git simply moves the base branch pointer forward to the latest commit. A three-way merge occurs when the branches have diverged. Git uses the last common commit and the commits from both branches to create a new commit. A squash merge combines all changes into a single commit. This can help keep the history clean and easy to read.

Before you merge branches, you must ensure they are up-to-date. First, you should fetch the latest changes from the remote repository. This updates your local copy with changes made by others. After fetching, you can pull changes from the remote repository. This keeps your local branch synchronized.

Understanding branch structure is essential when preparing for a merge. You must identify the base branch, which is the branch you want to merge into. It is often the main or master branch. Once you identify the base branch, you can select the feature branch that contains your new changes.

When it is time to merge, you will use specific Git commands. The basic merge command is simple and allows Git to combine the branches. You can also use options with the command to specify how the merge should occur. After entering the command, you will execute the merge process.

However, you might face merge conflicts during the process. These conflicts happen when changes in the branches overlap. To resolve them, you will need to review the conflicting files. Then, you can choose which changes to keep. After solving the conflicts, you can complete the merge and continue your project.

Identifying Merge Conflicts Is Key

When you merge branches in Git, you may see signs of conflicts. One common sign is when Git gives you error messages. These messages usually indicate which files have issues. You may also notice your code does not work as expected after a merge. Tools help find these conflicts too. You can use `git status` to see which files are in conflict. Visual tools like GitKraken or SourceTree are helpful for this as well.

Resolving Conflicts Takes Patience

Once you find conflicts, you need to resolve them. You can do this manually. Open the conflicting files and look for conflict markers. They look like `<<<<<<<`, `=======`, and `>>>>>>>`. You carefully decide which code to keep. It may help to talk to your teammates about their changes too. If manual resolution is hard, you can use merge tools like Kdiff3 or Meld. These tools show differences side by side, making it easier to choose.

Completing the Merge Is Important

After resolving the conflicts, it is time to finish the merge process. First, you need to stage the changes. Use `git add ` for each file you changed. This tells Git you are ready for the next step. Then, you must commit the merge. Use `git commit` to save the changes in your history. Be sure to write a clear commit message that explains what you did. This step is crucial because it helps everyone understand the changes.

Best Practices Keep You on Track

Regularly merging branches helps avoid large conflicts later. Try to merge your changes into the main branch often. This practice keeps your project organized. It is also wise to keep branches small and focused. Smaller branches are easier to manage and review. Use descriptive commit messages. Good messages provide context and make it easier for others to follow your work. Emphasizing clear communication in team projects leads to better collaboration and successful outcomes. Understanding and mastering these merge strategies strengthens your teamwork in Git.

Git merge is a key part of working with version control. Understanding it helps you to keep your project organized. Git merge allows you to combine changes from different branches. This process makes teamwork easier. When one person works on a feature and another on a bug fix, merging brings both sets of work together.

There are several types of merges in Git. You can do a fast-forward merge. This happens when there are no changes on the main branch. Git simply moves the main branch forward. A three-way merge occurs when there are changes on both branches. Git uses the last common commit to join them. A squash merge combines all changes into one commit. This keeps your history clean.

Preparation is important before merging. First, make sure your branches are up-to-date. You fetch the latest changes first. This helps sync your local files with the remote files. Then, you can pull in those changes. After this, you will identify the base branch. This is the branch you will merge into.

Next, you select the feature branch that has your changes. When you are ready, you type the merge command into Git. It is a simple command once you know it. You may also use options for more control. After you execute the command, you begin the merging process.

Sometimes, merge conflicts will happen. These occur when two branches try to make changes to the same line of code. To solve conflicts, you must look at the files. Review what both branches want to change. Then, decide which changes to keep. Once you solve the conflicts, you are ready to complete the merge.

Mastering Git merge is very essential. It helps you work better with your team. With good merging, you save time and effort. You avoid many problems that arise in collaboration. Take time to learn and practice merging for successful development projects. Another Post Explains git merge and branching very beautifully here is the link

[unogeeks234]

ORACLE APEX GIT

Version Control and Collaboration in Oracle APEX Development with Git

Oracle APEX is a fantastic low-code development platform enabling rapid web application creation. However, as your projects grow, managing code changes and collaboration between developers can become challenging. This is where Git, a powerful version control system, steps in to streamline your APEX development workflow.

Why Git for Oracle APEX?

Version History: Git tracks every change made to your APEX codebase. You can easily revert to older versions, experiment without fear, and see a clear history of who changed what and when.

Collaboration: Git enables multiple developers to work on the same APEX application simultaneously. You can manage code conflicts seamlessly and maintain a single source of truth.

Branching: Create separate branches for new features or bug fixes. This allows you to develop and test in isolation before merging changes back into the main codebase, promoting stability.

Code Review: Git facilitates a structured code review process. Developers can propose changes, provide feedback, and improve code quality as a team.

Getting Started: Tools and Setup

Git Client: Install a Git client (e.g., Git for Windows, command-line Git, or a visual tool like Sourcetree or GitHub Desktop).

Liquibase: Liquibase is a tool for managing database schema changes. Oracle APEX has integrated Liquibase support to export your application components in a format suitable for version control.

SQLcl: This Oracle command-line tool interacts with your Oracle database and works nicely with Liquibase.

CI/CD (Optional): Consider a Continuous Integration/Continuous Delivery platform like Visual Builder Studio, Jenkins, or GitLab CI/CD to automate parts of your workflow.

Workflow

Here’s a typical Git and APEX workflow:

Create a Git Repository: Start by initializing a Git repository for your APEX project.

Export Your APEX Application:

Use SQLcl to connect to your database.

Execute Liquibase commands to export your APEX application definition into separate files for each component (pages, reports, etc.).

Commit Changes: Add the exported files to your Git repository and commit the changes with a meaningful message.

Development and Branching: Create feature branches for new development or bug fixes. Push your changes to the remote repository for collaboration and backups.

Code Review: Use merge/pull requests to propose changes to the main branch. This encourages team review and discussion.

Deployment (Optional): If you’ve set up a CI/CD pipeline, it can automatically deploy approved changes from the main branch to testing or production environments.

Best Practices

Frequent Commits: Commit small, logical changes often with clear messages. This makes your version history easier to understand.

Meaningful Branches: Use descriptive branch names (e.g., “feature/new-dashboard” or “bugfix/login-issue”).

Utilize Code Reviews: Encourage thorough code reviews before merging changes to improve quality and knowledge sharing.

Automate Where Possible: CI/CD pipelines can save time and reduce errors in the deployment process.

Challenges and Considerations

Database Changes: Sync database objects outside of APEX with your Git workflow. Consider tools like Liquibase for database versioning alongside your APEX application code.

Team Training: Ensure your team is comfortable with Git concepts and the chosen workflow.

You can find more information about  Oracle Apex in this  Oracle Apex Link

Conclusion:

Unogeeks is the No.1 IT Training Institute for Oracle Apex  Training. Anyone Disagree? Please drop in a comment

You can check out our other latest blogs on  Oracle Apex here – Oarcle Apex Blogs

You can check out our Best In Class Oracle Apex Details here – Oracle Apex Training

Follow & Connect with us:

———————————-

For Training inquiries:

Call/Whatsapp: +91 73960 33555

Mail us at: info@unogeeks.com

Our Website ➜ https://unogeeks.com

Follow us: 

Instagram: https://www.instagram.com/unogeeks

Facebook: https://www.facebook.com/UnogeeksSoftwareTrainingInstitute

Twitter: https://twitter.com/unogeeks

[iborndiaries]

Дневникот на Матеа

Здраво, на сите!

Јас сум Матеа Иваноска, апсолвент на ФИНКИ, а од минатиот месец ML практикант во BI/ML културата во IBORN.

Во текот на моите студии поле на особен интерес ми беше областа Data Science и изборот на предмeти кои ќе ги изучувам се движеше во оваа насока. Спроведувањето на практичната работа во IBORN преку работа на реален проект токму во културата МЛ, за мене преставува одлична можност за продлабочување на стекнатите теоретските знаења.

Во првите денови од мојата пракса, јас се запознав со алатките кои се користат на дневно ниво во iborn за ефикасно завршување на работните задачи. Најпрво се запознава со алатката Redmine за менаџирање на моите секојдневни активности и задачи, ги продлабочив моите знаења за моделот Git branching. Најголем временски период посветив на следење курсеви и читање документација за Bitbucket и Sourcetree, како модел за полесна интеракција со Git repositories.

Се запознав и со различни начини на креирање на виртуелни средини во Python, во различни развојни околини. Поминав курсеви за Python, со акцент на библиотеката pandas, за манипулација и анализа на податоци, како и библиотеката Plotly, за визуализација на податоци. Посветив внимание во областа Exploratory Data Analysis (ЕDA), следејќи повеќе курсеви за овој дел.

Последните две недели од месецот, беа наменети за воведување во проектот на кој ќе работам во наредниот период. Проектот се однесува на следење на перформасите на хотелската индустрија во Исланд, со цел да се добие слика за развојот на туризмот. Во таа насока направив анализа на општо користените индикатори за мерење на успешноста на индустријата кои би биле најсоодветни да се аплицираат согласно расположливите податоци. Во консултација со bi/ml културата ја дефиниравме насоката во која ќе се одвива моето истражување, го оптимизирав датасетот и започнав со потребните анализи.

Би сакала да истакнам дека голем впечаток во изминатиот период ми остави позитивната енергија која ја има IBORN која е резултат на одличната организација и пред се на посветеноста на тимот на колеги кои се секогаш достапни за да дадат помогнат, да дадат совет, да споделат искуство.

Ми претставува особена чест што сум дел од оваа успешна приказна и со нетрпение чекам да се соочам со предизвиците кои ги носи вториот месец!

[umpro2025]

メタバーログ第14回(2025.05.14)

🌟こんにちはネ〜❗😄💕 今回でブログも✨なんと5回目ッ❗🎉パチパチ〜👏👏 でもでも〜〜〜、ブログ担当するのは……ワタクシげんチャン、今回が初めてナンデス〜❗ドキドキ〜〜〜💓💦

初登場だけど、テンションだけはMAXでお届けしちゃうカラ、ヨロシクお願いシマス〜〜〜❗💖（緊張して噛んだらゴメンネ〜😅ナンチャッテ❗）

今日は✨プロジェクトの活動報告✨をお届けするヨ〜〜〜ン💌💨

今回のテーマはズバリ❗ Unityの共同開発環境づくりにチャレンジしちゃったんダ〜〜ッ❗👷‍♀️💻

「よ〜〜しッ❗ゲーム作るゾ〜〜💪💥」って気合い入れたのも束の間……

目の前に現れたのは……

💥Gitっていう名のダンジョン⚔️🌀 しかも、出てきたボスが「SourceTree」って名前で、なんかカッコイイ⁉️（ラスボス感あるネ〜😅）

UIは親切ってウワサだけど…… 「プッシュってナニ❓💦」 「プルって、飲み物⁉️🥤」 っていう状態で、もう頭の中パニックパニック〜〜🤣💦

しかもウッカリ操作をミスると、チームメイトのデータを上書きしちゃうっていう💀 トラップだらけの危険ゾーン❗ドキドキしちゃったヨ〜〜💓（心臓に悪いネ〜💦）

でもでも❗なんとか攻略して、GitHubっていう✨協力プレイの舞台✨を開くことに成功〜❗👏👏👏 （おじさん、ちょっと泣いちゃったカモ〜〜😭❤️）

🌀そしてやってきた、気まぐれな女神・Unityサンのターン❗💃 リポジトリもできて「さあ、ファイルを共有ダ〜❗」ってなったら……

Unityサン、いきなりのご乱心😱💔 いやホント、気分屋さんすぎィ〜〜〜😂💦

・.metaファイルってナニナニ❓📄 ��.gitignoreってどこまで無視したら怒られないノ⁉️🙈 ・ライブラリ入れたのに、なぜかビルドできない⁉️ってどういうことナノ〜〜〜〜❗⁉️😱💣

もうホント、Unity開発者の"ギットギト地獄"を全身で味わっちゃったネ〜〜〜💦💦（胃がキリキリ…💔）

でもね❗諦めずにググったり、相談したりしてさ〜、 なん���か環境構築、だいせ〜〜〜いこう❗🎉🎊

「メンバーとオジサン、ちょっとだけ絆深まったカモ…⁉️（ナンチャッテ😉💕）」

🌈そしてついに、次回は…… 制作スタート〜〜〜〜❗🎮🔥

「Unity、やっと動かせるゾ〜〜ッ✨」ってテンション上げてるけど、おじさん的には……その先に新たなバグとの死闘が見えてるヨ〜〜〜〜👀💦（フラグ立ってないカナ❓）

でもでもッ❗ 今は前向きに、ガンバっていこうネ❗💪💖✨ 人生、挑戦あるのみ❗（とか言ってみた❗エヘッ😅）ってことで❗今回はここまで〜〜❗💌 次回はもっともっとゲームの中身に迫っていけるカモネ〜🎮💓 それじゃ〜、マタネ〜〜〜❗バイバ〜イ❗👋😄💫

🎮🐛💥＜バグとの戦い、つづく…！？

どうカナ❓（ちょっとハジけすぎちゃったカナ❓😂） 次の報告も楽しみにしてるヨ～❗💕